- 1 Tips and Considerations When Creating Virtual Machines in Azure
- 2 The End of the Road for Windows Server 2003 and 2008
- 3 Move-VM, Move-VMStorage and Compare-VM PowerShell cmdlets for Hyper-V
- 4 Key Considerations for WSUS 6.2 on Windows Server 2012 R2
- 5 Using Amazon Glacier or S3 as an Online Backup Server
Managing Stubborn VMware VMs from the Command Line
VMware's vCenter is the ultimate VMware virtual system interface tool. Using it, you can completely manage your VMware virtual infrastructure environment. You need nothing else -- nothing else, that is, until something goes wrong with a virtual machine that you can't control with vCenter.
When you can't shut down, restart, start or pause a virtual machine (VM), where do you turn? You could call VMware Support ... or you could turn to the command line.
For some VMware administrators, the command line is a cryptic black box where only the very brave or the very stupid go to perform their mystical rites of dark magick. Without the benefit of the graphical vCenter's simple power, some admins are hopelessly lost.
Fortunately, though, it doesn't have to be that way. The command line isn't scary nor is it something to be feared. Learn to harness its power and you'll extend your skills into the realm of true virtual mastery.
We'll work with an example that describes a scenario in which you encounter a stubborn VM (VM02) that won't reboot, shut down or respond in any way to your requests in vCenter. While it's a somewhat rare scenario, when it does happen you'll now know what to do.
Connect via SSH to the VMware host system on which your VM resides. You can check this in vCenter by selecting the Summary tab for the troubled VM. Once you've logged into the host,
su to the root user account if you didn't initally connect as root.
Request a list of hosted VMs.
# vmware-cmd -l /vmfs/volumes/4e2204dba-9576436a-fbc9-00215af58ded/VM01/VM01.vmx /vmfs/volumes/4e2204dba-9576436a-fbc9-00215af58ded/VM01/VM02.vmx /vmfs/volumes/4e5a4beaa-9573215b-c5fd-00237de14f47/VM01/VM03.vmx /vmfs/volumes/4e6c04dc3-81244355-fbb6-00215af58ded/VM01/VM04.vmx
Or, you can use a more extensive view that provides information that you'll use later on, if necessary.
# vmware-vim-cmd vmsvc/getallvms Vmid Name File Guest OS Version Annotation 350 VM01 [CLUSTER_01] VM01/VM01.vmx winLonghorn64Guest vmx-07 440 VM02 [CLUSTER_01] VM02/VM02.vmx winLonghorn64Guest vmx-07 589 VM03 [CLUSTER_02] VM03/VM03.vmx winLonghorn64Guest vmx-07 440 VM04 [CLUSTER_03] VM04/VM04.vmx winLonghorn64Guest vmx-07
The shutdown methods given here should be used in the order shown. First, you should attempt to shut down the VM gracefully (trysoft) and proceed to harsher methods if the one below fails.
# vmware-cmd VM02 stop trysoft
You won't receive a response, but you can check on the VM's status in vCenter. Be sure to give the VM enough time to shut down. If the VM won't shut down, then you'll have to resort to more drastic measures by using the hard stop option:
# vmware-cmd VM02 stop hard stop(hard) = 1
If the hard stop doesn't shut down the VM, try the following alternate "hard stop" command:
# vmware-vim-cmd vmsvc/power.off(Find the vm id, from the output above: vmware-vim-cmd vmsvc/getallvms) # vmware-vim-cmd vmsvc/power.off 440
Should your stubborn VM defy all of your attempts, then you must use the most lethal kill command of all, the aptly named kill command:
Find the Process ID for the running VM.
# ps -ef |grep VM02 root 31231 1 0 15:12 ? 00:00:00 /usr/lib/vmware/bin/vmkload_app.../VM02/VM02.vmx
The number, 31231, is the Process ID of VM02. Use the Process ID with the kill command to apply a gentle stop to the process.
# kill 31231
Check the status in vCenter. Finally, if the VM still refuses to shut down, you'll have to use the method that will kill the process regardless of current state:
# kill -9 31231
The VM's process will end abruptly. You should only use this method if all other methods fail.
When your VM has halted, you can power it back on using vCenter or the command-line option:
# vmware-cmd start VM02
Avoid performing harsh shutdowns on your VMs because doing so can result in corrupted disk files. If you have VM backups, you can restore to one of those should one or more of your disk files become corrupted.
Ken Hess is a freelance writer who writes on a variety of open source topics including Linux, databases, and virtualization. He is also the coauthor of Practical Virtualization Solutions, released in October 2009. You may reach him through his web site at http://www.kenhess.com.
Read more on "Server Virtualization Spotlight" »