Note that the -X switch specifies the NEW SIZE of the virtual disk and NOT how much you are extending it by.

If you have used the -X switch before in an older version of ESX server (earlier than 3.0) it was possible to specify a small disk size; thereby making the virtual disk smaller. This was dangerous but useful if your partition within the disk did not consume 100% of the disk size. However, this is not possible with vmkfstools command found in ESX Server version 3.x.

From ESX 3.5, the size of a virtual disk can now be increased in the VI Client! VMware are implementing more and more in the user interface, less time needed in the service console command line…

Previously, the main use of vmkfstools command was to import or export virtual disks. This would be required if you were deploying templates by hand instead of using VirtualCenter. It was also the primary method for moving VMs between the ESX server product and the hosted VMware products such as VMware Workstation or Server. The reason we say “previously” is that moving VMs between servers or between VMware products has become much simpler and cleaner by using the VMware Converter utility. This tool is task oriented and treats the VM as a whole object, not just the virtual disk files as vmkfstools.

If you do want to import virtual hard disks in 2GB sparse format into monolithic format by hand, then we can use vmkfstools command with the -i switch.

vmkfstools -i /importfiles/vm.vmdk /vmfs/volumes/storage1/vm/vm.vmdk

Notice that the import option requires two parameters, source and destination. This would not create a VM, but would create the monolithic virtual disk for a VM. You could then create a custom VM in the VI Client and select the option to “use an existing disk”.

If you want to export a virtual disk you no longer use the -d switch, but just use -i and specify the virtual disk type at the destination of the import. So if you were exporting a virtual disk from VMFS to

vmkfstools -i /vmfs/volumes/storage1/vm/vm.vmdk -d 2gbsparse /exportvm/vm.vmdk

If you have a VM that you can’t tell if it is powered on or off, you can use the getstate option

# vmware-cmd /vmfs/volumes/SharedVMs/vm1/vm1.vmx getstate

vm1 is powered on

If you need to force the VM to power off, the stop hard function will normally do the trick. This is not very graceful, but can save you time if things are not responding.

# vmware-cmd /vmfs/volumes/SharedVMs/vm1/vm1.vmx stop hard

If there is limited space in your VMFS volumes, then you will likely want to know if any of your VMs are running in snapshot (where the disk writes are going into a disk delta and not the regular parent virtual disk). It is a nice idea to have a short script to enumerate the VMs on your host and loop through them to check each of them to see if they have a snapshot. The vmware-cmd command again helps us out with this.

<output>

[root@esx1 root]#

Watch out for the creation of empty subdirectories of the name “vm-support.<pid-of-process>” in the directory where you run this tool with the -x switch. It is safe to delete these directories. You can’t run this command if your current directory is /proc.

A less well-known option of vm-support is the ability to capture host performance data which can be replayed later using esxtop. To invoke the performance capture, we need to specify how frequently a performance “snapshot” is taken and over what period of time. For example, if we wished to capture host performance every 30 seconds for 10 minutes, then we would invoke vm-support with the following options

[root@esx1 root]# vm-support -S -i 30 -d 600

The performance snapshots are archived automatically into a tgz file (a tgz file just like a WinZIP (R) archive). The tgz archive file name produced is unique to each time it’s run, as the name includes date, time and process id of vm-support. Before we can actually replay the snapshot performance data in esxtop, we need to extract the tgz archive. The tar command is used to “unzip” tgz archive files.

[root@esx1 root]# tar -zxvf archive.tgz

To replay the data in esxtop, use the “-R” switch to specify replay mode and supply the path to the performance capture file produced by vm-support.

- Bundle Name – AppFlags — Summary — iFlags
ESX350-200710049-BG ——-v Bugs fixed in some vmkernel. rm-
ESX350-200710050-SG i——v Security bugs fixed in vmkernel module.. rm-
ESX350-200710052-BG i——v Several bugs fixed in vmx module… -m-
ESX350-200710053-BG ——– Provided new PBM for SUSE 11 U2. —
ESX350-200710054-BG ——-v COS fix for Ooops. rm-
ESX350-200710055-BG ——– More fixes in scsi drivers. r–
ESX350-200710058-RG ——-v This is a roll-up bundle. rm-
ESX350-200710059-RG ——-v This is a roll-up security bundle. rm-

If you choose to use the new VirtualCenter Server 2.5 feature called VMware Update Manager (VUM), then when you perform host scans and remediation, you are in fact just remotely invoking this utility, it’s just you don’t see it!

You can use the –explain switch when scanning to provide a greater level of detail to your host patch scan operation. If for example, the AppFlags for a patch indicated “c” for conflict, you would probably want to know what exactly the patch was in conflict with.

However, if you are using ESX version 3.5 then we need to use a slightly different syntax for specifying the portgroup to enable. We now need to specify using a vmkx notation. Trouble is, we don’t know which portgroup corresponds to which vmkx number. So to first identify the mapping of portgroup name to vmk number, we enter the command

vimsh

and then enter hostsvc/vmotion/netconfig_get and we’ll get a whole pile of output, but buried in there will be the device names in vmkx format that we can then use to enable VMotion on that portgroup with the following:

vimsh -n -e “hostsvc/vmotion/vnic_set vmk0

Using the vimsh command for enabling VMotion is just 1% of the functionality of this tool. It’s not for the faint hearted and there really is no better source of information about it than the PDF documents that the xtravirt guys have written. Thanks also to Mike Laverick of RTFM Education (www.rtfm-ed.co.uk) for documenting the changes in vimsh in version 3.5.