Nutanix AHV: Archived Single-Host Shutdown and Maintenance Sequence
This is an archived single-host AHV maintenance example, such as for memory or failed-hardware replacement. Its output is dated June 5, 2017. Match the AOS/AHV release and supported node-maintenance workflow before use; do not combine an old CLI sequence with a newer Prism workflow without checking the vendor procedure.
Overview
Shutdown sequence: migrate guest VMs, enter host maintenance mode, shut down the CVM, then shut down AHV. Return sequence: power on AHV, confirm the CVM is running, exit maintenance, verify cluster health, wait for data resiliency, then consider VM placement.
The official English AHV Administration Guide, Node Management recommends the Prism node-maintenance workflow and distinguishes it from CLI maintenance. Confirm resiliency before taking a node down; for an RF2 cluster, do not take a second node down. Single-node clusters require a different procedure. Pinned/passthrough or otherwise non-migratable VMs need explicit handling, and entry/exit methods must match. These checks are prerequisites, not outcomes established by the archived output below.
1. Migrate guest VMs
GUI option in the source: Prism → VM → Table; group/list VMs by host, select a VM, choose Migrate, and select the destination. Repeat as needed and verify completion.
CLI option: SSH to the source CVM, start aCLI and list host UUIDs:
nutanix@NTNX-J32X62B-A-CVM:15.2.21.244:~$ acli<acropolis> host.list
Hypervisor address Host UUID Schedulable
15.2.21.2 7b52e2bc-f558-4253-a00e-ba4f05cde70e True
15.2.21.241 838eb59b-d48e-4f58-8029-c7dba2307f6d False
15.2.21.242 6230329d-33b6-4944-a902-249fe3f11a2c True
15.2.21.3 eba68807-d550-41ae-9c0f-9b52508014fc True
15.2.21.4 3a69e714-5e37-49a3-9fa2-6aba379e12f9 True
15.2.21.5 d24b96c4-6f81-485c-b205-947f37f96870 TrueThe source then attempts a host VM-list command, followed by an invalid-command message. The Chinese note speculates that running VMs would be listed:
<acropolis> host.list_vms 6230329d-33b6-4944-a902-249fe3f11a2c
Not a valid command: host.lis_vmsThat response reports host.lis_vms, whereas the typed line says host.list_vms. It proves neither an empty host nor successful evacuation. Use the actual release’s supported VM inventory/migration commands or Prism to identify remaining guest VMs.
The source’s multiple-VM migration example is retained with ASCII quotes:
<acropolis> vm.migrate vm01,vm02 host="15.2.21.2" live=yesVM names are comma-separated in that example. Validate the command syntax on the installed release and verify each VM’s final host; this is not evidence that these example VMs migrated.
2. Enter host maintenance mode
SSH to the associated CVM and enter aCLI:
nutanix@NTNX-J32X62B-A-CVM:15.2.21.244:~$ acli<acropolis> host.enter_maintenance_mode 15.2.21.242
EnterMaintenanceMode: completeConfirm the correct AHV/CVM pairing and completed maintenance state before proceeding. The example targets AHV 15.2.21.242 from CVM 15.2.21.244; never infer that association only from similar IP addresses.
3. Shut down the target CVM
Exit aCLI, then run the source shutdown on the CVM belonging to the maintained host:
<acropolis> exitnutanix@NTNX-J32X62B-A-CVM:15.2.21.244:~$ cvm_shutdown -P now
2017-06-05 21:37:20 INFO cvm_shutdown:72 Setting up storage traffic forwarding
2017-06-05 21:37:20 INFO cvm_shutdown:75 Establishing Zookeeper connection...
2017-06-05 21:37:20 INFO zookeeper_session.py:76 Using host_port_list: zk1:9876,zk2:9876,zk3:9876
2017-06-05 21:37:20 INFO ipv4config.py:800 Discovered network information: hwaddr 52:54:00:18:84:93, address 15.2.21.244, netmask 255.255.255.0, gateway 15.2.21.254
2017-06-05 21:37:20 INFO cvm_shutdown:94 Executing cmd: sudo shutdown -P now
Broadcast message from nutanix@NTNX-J32X62B-A-CVM
(/dev/pts/0) at 21:37 ...
The system is going down for power off NOW!
-P here requests power-off; it is not a password argument. The complete original timestamps, network fields and shutdown output are retained.
4. Shut down the AHV host
SSH to AHV and confirm the CVM is shut off:
[root@NTNX-J32X62B-A ~]# virsh list --all | grep CVM
- NTNX-J32X62B-A-CVM shut offThen the source powers down AHV:
[root@NTNX-J32X62B-A ~]# shutdown -h now
Broadcast message from root@NTNX-J32X62B-A
(/dev/pts/0) at 6:34 ...
The system is going down for halt NOW!5. Power on AHV and check the CVM
After the physical maintenance, power on the host. The source expects automatic CVM startup. SSH to AHV and verify:
[root@NTNX-J32X62B-A ~]# virsh list --all | grep CVM
2 NTNX-J32X62B-A-CVM runningIf it remains shut off, the source starts its named CVM explicitly:
[root@NTNX-J32X62B-A ~]# virsh start NTNX-J32X62B-A-CVM6. Exit maintenance mode
SSH to the associated CVM and enter aCLI. The original before/after host lists are retained:
nutanix@NTNX-J32X62B-A-CVM:15.2.21.244:~$ acli<acropolis> host.list
Hypervisor address Host UUID Schedulable
15.2.21.2 7b52e2bc-f558-4253-a00e-ba4f05cde70e True
15.2.21.241 838eb59b-d48e-4f58-8029-c7dba2307f6d True
15.2.21.242 6230329d-33b6-4944-a902-249fe3f11a2c False
15.2.21.3 eba68807-d550-41ae-9c0f-9b52508014fc True
15.2.21.4 3a69e714-5e37-49a3-9fa2-6aba379e12f9 True
15.2.21.5 d24b96c4-6f81-485c-b205-947f37f96870 True<acropolis> host.exit_maintenance_mode 15.2.21.242
<acropolis> host.list
Hypervisor address Host UUID Schedulable
15.2.21.2 7b52e2bc-f558-4253-a00e-ba4f05cde70e True
15.2.21.241 838eb59b-d48e-4f58-8029-c7dba2307f6d True
15.2.21.242 6230329d-33b6-4944-a902-249fe3f11a2c True
15.2.21.3 eba68807-d550-41ae-9c0f-9b52508014fc True
15.2.21.4 3a69e714-5e37-49a3-9fa2-6aba379e12f9 True
15.2.21.5 d24b96c4-6f81-485c-b205-947f37f96870 TrueThe target AHV changes from Schedulable=False to True. A different host, 15.2.21.241, also differs between the initial and later lists; the source does not explain that transition, so it must not be treated as an intended extra maintenance action.
7. Check cluster health and resiliency
Exit aCLI and check the cluster from the CVM shell:
cluster statusWait for Prism’s Data Resiliency status to show green/OK and confirm the applicable service/health checks. The source says synchronization may take a few minutes, but that is not a guaranteed duration. Only after recovery is confirmed should workload placement be restored as required; use the migration method above if the applicable release/workflow does not restore it automatically.