vmkfstools
Used to manipulate virtual disks at the service console command line. It is used most often for import and export operations, where a virtual disk is converted from monolithic format to sparse format (previously called COW format).
There is a great switch with the command -X which can be used to extend the size of your virtual disk; e.g. if you had a 10GB virtual disk and wanted to expand it to 20GB, you could use this command. The VM would need to be powered off for this to work.
vmkfstools -X 20GB /vmfs/volumes/storage1/vm.vmdk
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
vmware-cmd
This command has been in ESX for a number of versions and it's functionality has been extended with each major release.
esxupdate
This utility is what we use to patch our ESX hosts with updates from VMware. You can use this tool interactively to install individual patches, or use it to scan your ESX host to see which patches are required as well as to do a "what-if" install of a host patch to identify if there will be any problems.
The power of the esxupdate command is realised when you use it with a patch repository. A patch repository can be exposed to a host via HTTP, FTP or NFS.
esxupdate -d [url]ftp://taupopatchserver/esx35/0710-03[/url] scan
- 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 Update Manager, 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.
contents.xml
Every ESX patch contains a file called contents.xml. This file describes the directory structure of the patch bundle contents.
contents.xml.sig
This is a detached PGP signature of the contents.xml file in a ESX patch.
vimsh
This is a superb utility that we use on occasion, particularly when we are creating scripted builds for ESX. The industry-recognised experts in the functions of this tool are the folks over at [url]www.xtravirt.com[/url]. Where we have found this tool of unique use is in the enabling of a VMkernel port for VMotion.
If you are using ESX versions prior to 3.5 then use
vimsh -n -e "hostsvc/vmotion/vnic_set portgroupname
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 for documenting the changes in vimsh in version 3.5.
What can you do with the new Windows Live? Find out
ليست هناك تعليقات:
إرسال تعليق