Lenovo HX Maintenance: Migrate VMs and Prepare for CVM Shutdown

This archived vSphere Client walkthrough illustrates application-VM evacuation before maintenance on a Lenovo HX/Nutanix node running ESXi. Its CVM section stops before a shutdown procedure; the missing source detail and official English continuation references are identified below. This is a host-to-host vSphere example, not an AHV or Nutanix Move migration guide.

The English figures are simplified instructional reconstructions of photographed screens. HOST-A/HOST-B and APP-VM-A/APP-VM-B are examples, not the customer inventory; any displayed capacities, usage figures or version details are illustrative and must not be used for sizing or compatibility decisions. The two host labels are an excerpt, not a claim that the cluster has only two nodes. The CVM is kept separate from the application-VM selection.

1. Identify the maintenance host and application VMs

Sign in to the intended vCenter using customer-provided, authorized connection details. Identify the actual server requiring maintenance, its local CVM and the application VMs it hosts. Verify the applicable cluster-health/resiliency checks and maintenance plan before beginning.

English host-selection illustration: HOST-A identified as the maintenance target; application VMs and its local CVM are listed separately.

Select the application VMs to evacuate. Confirm the selection against the actual workloads; do not treat the local Controller VM as an ordinary application VM to migrate.

English selection illustration: two example application VMs highlighted; CVM-A remains unselected. Inventory quantities are illustrative.

English selection-review illustration: check the intended application-VM set before opening the migration action.

2. Select the migration action and destination

Right-click the intended application-VM selection and choose Migrate. The source asks to confirm that the destination has sufficient resources. Also review the real compatibility checks, required vMotion/network/storage access and workload constraints for this environment; the diagram’s Normal icons do not establish those conditions.

English context-menu illustration: Migrate selected for application VMs; the local CVM is not included.

Select the intended destination host or cluster. In these examples HOST-B is the destination. Resolve actual compatibility errors before proceeding; the English illustration does not fabricate a successful validation result.

English Select Destination illustration: HOST-B selected; review the actual compatibility result rather than assuming a pass.

3. Review priority and start the intended migration

The archived source chooses High priority. Review whether that is appropriate for current resource availability and workload policy, then continue to the final review. A priority choice is not proof that resources are available or that vMotion succeeded.

English priority-dialog reconstruction: High priority selected; three stages are Select Destination, vMotion Priority and Ready to Complete.

Review the actual VM list, destination and migration settings. Choose Finish only for the intended operation.

English Ready to Complete reconstruction: the two illustrative application VMs, HOST-B and High priority reviewed; migration is not yet shown as completed.

4. Verify tasks and resulting placement

Inspect the real Recent Tasks entries and their results. Verify each required workload’s destination placement and service state before continuing with node maintenance. The low-resolution source task strip does not support a reliable success state or progress percentage, so the English figure contains a verification reminder instead of invented completion data.

English Recent Tasks illustration: check the actual task result for each VM; no completion percentage or success state is asserted.

5. CVM shutdown: source boundary and official continuation

The original next heading is Shut down the CVM and its only readable instruction is Select the maintenance target host. The final source PNG is truncated, including when downloaded again from its original server; it renders only a narrow header. It cannot establish the intended next click or shutdown sequence. The replacement below explains that boundary rather than reconstructing unseen controls.

Replacement scope illustration for the truncated source: identify the intended ESXi host and its local CVM, then use the matching vendor node-shutdown procedure.

Use the Lenovo service guide for the actual HX model and the matching Nutanix hardware-replacement/AOS/ESXi instructions. The official Lenovo HX3510-G/HX5510/HX5510-C/HX7510 guide explicitly directs technicians to the hypervisor-specific Nutanix Node Shutdown procedure before relevant hardware replacement; it is a reference for those models, not proof that every HX platform has identical physical steps.

Nutanix’s employee-authored English Host Maintenance with DRS Enabled article gives a historical outline for fully automated DRS: confirm management access; request ESXi maintenance/VM evacuation; put the local CVM into its required maintenance state and shut it down; verify host maintenance completes before the host action. It then covers rejoining, exiting the appropriate maintenance states and checking cluster health. That is a DRS-enabled outline, not the missing original screenshot, a release-independent command sequence or a full-cluster power-off procedure. Its linked KB-4639 and AOS 5.16/5.17 topics identify the detailed procedures; their contents were not readable here and are not represented as revalidated instructions.

Complete and verify the approved node-shutdown procedure for the deployed versions before removing power or performing hardware work. No VM, CVM, host, DRS or power-state action was performed while preparing this English edition.

English references and figure scope

No corresponding English version or complete same-version screenshot set was found in the protected BookStack source. The source gap is retained explicitly; English vendor materials above address the continuation without claiming that unreadable original steps were recovered. Peripheral customer inventory and ambiguous photographed values are not reproduced as verified facts.