ZSvirt's VMware-exit PoC guide tells you to break the VM build on purpose

The most instructive step in the list is the one that asks you to break something. According to the guide, creating a VM decomposes underneath into scheduling a compute node, preparing an image, creating disks, configuring networking and generating the VM config, and a failure at any of those steps can leave behind resources that were created and are no longer needed ^[13]. The stated answer is async tasks, stateless services and a workflow engine that splits long-running operations into executable, rollback-able steps ^[12][14]. That makes the induced-failure exercise ^[15] a reconciliation test rather than an error-message test: after a failed create, the platform's inventory either matches what is actually on the disks and the switch, or it does not. Orphaned volumes are easy to ignore in a lab and expensive to find in production.

Then the arithmetic. The minimal build puts the management node and the compute node on a single server ^[7]. The exercise list asks you to migrate a VM to another host ^[11]. One host cannot receive a migration from itself, so the floor for running the whole checklist is two hosts, not the one the deployment section describes ^[17]. The wording matters a second time: the list says migrate a VM to another host, and does not say whether the VM stays running while it moves ^[20]. That distinction decides whether anything without a maintenance window can move at all, and the same guide asks you to sort workloads by tolerance for downtime versus a short cutover window in the inventory step ^[5].

Two items in the scope statement never reach the exercises. Access control and high availability both appear in the list of what a larger infrastructure team has to evaluate ^[6], and neither gets a step in the day-two list or in the post-boot checks ^[18]. The text available breaks off mid-sentence while introducing the controlled-failure example ^[19], so a later section may close that gap. Up to that point, a PoC run to the letter proves the storage, network, image, console and task-record paths ^[9] and says nothing about who is permitted to invoke them.

No figures accompany any of it ^[21]. The guide points back to an earlier post on the architecture of what it calls a production-proven engine ^[16], which is a claim about someone else's environment until you produce numbers from yours. For the checklist to transfer, the inventory has to be finished before you install anything: CPU generations and the hardware retention plan, VLANs and address allocation and security policy, and how backup, monitoring, audit and automation attach ^[5]. Those set the scope, and the platform's feature list does not. The sequencing rule is the part I would copy verbatim: confirm the compute, storage, network, image and VM paths before touching cluster and migration tests, so a later failure can be attributed to platform configuration, infrastructure conditions or the migration process itself ^[10]. What you get, as published, is a competent day-two operations drill on one host with no permissions step, which leaves the two questions that usually block a VMware exit for you to add.