Uncategorized

Customizing Guest Cmdlets

PowerCLI has several cmdlets that work inside the guest of a VM:

These cmdlets are script-based and this makes them user-customizable. By default, they are supported on Windows (XP, 2003) and RedHat 5 guest operating systems. But if you want to execute the cmdlets on a different guest OS, you can extend their guest OS support either by modifying the existing scripts, or by adding your own ones. The scripts are located in the PowerCLI installation folder: “<Install_Folder>\Scripts”.

Naming the Scripts

The script names follow this convention: <operation_identifier>_<guest_OS_identifier>[.bat]. The operation identifier is “GuestDiskExpansion” for Set-HardDisk and the cmdlet name (without dash between verb and noun) for the VMGuestNetworkInterface and VMGuestRoute cmdlets (e.g. “GetVmGuestNetworkInterface”). The OS identifier should be either an OS family (e.g. “WindowsGuest” or “LinuxGuest”) or a specific OS version – guest id (e.g. “winXPProGuest”). You can see the guest id using Get-VMGuest cmdlet. The script extension must be “.bat” for Windows scripts and must be omitted for Linux scripts.

Executing the Scripts

When you pass a collection of VMs to one of these cmdlets, the cmdlet checks the guest OS and chooses the most appropriate script for each VM. In short, this is how it works: PowerCLI searches for a script for the specific guest id (specific OS version) of the VM and if there is such a script – it uses it; if no such script is found – PowerCLI checks for a script that matches the guest OS family and uses it. In this way, you can have a specific script for a specific OS (e.g. Windows 7) and use the common OS family script (e.g. Windows) for all other OS versions (e.g. XP, 2003).

Modifying the Scripts

Each script receives its parameters in a specific order and must also print its output in a specific format. Each predefined script contains a comment at the beginning which describes the expected parameters and output. You can either modify the existing scripts or write new ones (e.g. for a specific OS version). Either way you need to ensure that the script handles the expected parameters and prints the expected output – only then the cmdlet will be able to use the script.