先确认资源归属与可用目录
申请人需要所属 System 和 Service 的资源访问权、创建虚拟机的能力以及相应环境范围。表单里的命名空间、模板和规格取决于当前账号。如果没有可选项，应请资源负责人核对成员关系和目录配置。
填写需求，不填写集群标识
当前创建契约要求服务、模板、实例规格、命名空间和业务理由；可选资源目标仍需校验。申请内容不包含 cluster_id，虚拟机名称由平台生成。提交前尤其要核对命名空间，它在提交后不可修改。
把交付作为独立检查
审批侧确认符合条件的集群和存储配置。作出决定后，还要检查执行结果与虚拟机状态。审批通过并不代表存储、准入校验或客户机启动已经成功。
操作与检查步骤
确认 System 与 Service
找到应当拥有这台虚拟机的业务服务。访问不到时先核对成员关系，避免为绕过权限重复创建服务。
查看两层访问模型选择申请上下文
选择可用模板、实例规格和已登记的命名空间；阅读可用性提示，填写能说明工作负载的理由。
核对 VMCreateRequest 与申请上下文提交并保留申请单
仔细确认命名空间后提交一次，跟踪申请单等待审核。可用性提示不等于预留了集群资源。
查看申请与审批职责核对虚拟机交付结果
查看申请单结果及虚拟机状态。执行失败时保留原始错误供平台运维排查；浏览器演示中的状态转换使用模拟数据。
前提条件与边界
- 公开演示不会创建真实虚拟机，也不会预留集群 CPU、内存或存储。
- 真实安装需要可用的 Kubernetes/KubeVirt 连接、目录配置和适当的命名空间权限。
- 审批结果与运行健康是不同检查，已批准的申请仍可能执行失败。
文档与实现依据
- 申请与部署位置的职责
已接受的申请人与审核人边界。
- 当前创建 API
查看 /vms/request-context、/vms/request 和 VMCreateRequest。
- 成员关系与访问模型
全局能力、继承的资源访问与环境范围。
- 部署要求
表单背后的基础设施及配置要求。
常见问题
申请表为什么没有集群选择？
创建契约有意省略 cluster_id。申请人提交命名空间里的工作负载需求，审批侧选择符合条件的部署集群。
审批人能改正我填错的命名空间吗？
已提交命名空间不可变。应与审核人处理错误申请，再提交正确上下文，不能把部署位置调整当成跨命名空间变更。