WilliamLam.com

Search Results for: guest operations

Automating the New Integrated VIX/Guest Operations API in vSphere 5

by // 27 Comments

VMware hinted earlier this year that the future of the VIX API would eventually be integrated into the core vSphere API, it looks like the wait is finally over. With the latest release of vSphere 5, the VIX API is no longer a separate API but consolidated into the core vSphere API which allows users to perform guest level operations directly to a virtual machine that is running VMware Tools.

There is now a new managed object called GuestOperationsManager which provides functionality for Authentication (authManager), File management (fileManager) and process management (processManager). The API is actually quite easy to use as you need to first acquire a guest auth credential within the guest and then you can perform any of the various guest operations using this credential cache.

I wanted to show the power of the VIX API by creating a vSphere SDK for Perl script called guestOpsManagement.pl that implements majority of the VIX/Guest Operations for users to manage from a centralized script. You will need to have a system that has the vCLI installed or use VMware vMA and to utilize the new VIX operations, your virtual machines must have the latest VMware Tools installed.

You can download guestOpsManagement.pl script here. 

The script supports 12 different VIX Operations which are described below:

Operation Description
validate Allows a user to validate guest credentials without performing any VIX Operation
ps Performs a process listing within the guestOS
startprog Starts a program within the guestOS
kill Kills a particular process within the guestOS
ls Perorms a listing of a particular directory within the guesOS
mkdir Creates a directory within the guestOS
rmdir Removes a directory within the guestOS
rm Removes a file within the guestOS
mv Move/Rename a file within the guestOS
mvdir Move a directory within the guestOS
copyfromguest Download a file from within the guestOS to local system
copytoguest Upload a file to the guestOS from a local system
Here is an example of performing the "validate" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation validate --guestusername root

Here is an example of performing the "ps" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation ps --guestusername root

In the next example, we will kill off the "tail" process as listed above.

Here is an example of performing the "kill" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation kill --guestusername root --pid 13198

Here is an example of performing the "startprog" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation startprog --guestusername root --working_dir /root --program_path /usr/bin/touch --program_args /root/virtuallyghetto

Note: There is known vSphere SDK for Perl bug for the return value of a "long" which will be resolved in GA release of vSphere SDK for Perl 5.0. You should not see the "error" message when running this operation

Here is an example of performing the "ls" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation ls --guestusername root --filepath_src /var/log

Here is an example of performing the "mkdir" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation mkdir --guestusername root --filepath_src /tmp/virtuallyghetto

Here is an example of performing the "rmdir" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation rmdir --guestusername root --filepath_src /tmp/virtuallyghetto

Note: If you would like to perform a recursive directory delete, you will need to specify the --recursive, please use with caution

Here is an example of performing the "rm" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation rm --guestusername root --filepath_src /root/virtuallyghetto

Here is an example of performing the "mv" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation mv --guestusername root --filepath_src /root/steve_jablonsky --filepath_dst /root/hans_zimmer

Here is an example of performing the "mvdir" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation mvdir --guestusername root --filepath_src /tmp/foo --filepath_dst /tmp/bar

Here is an example of performing the "copyfromguest" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation copyfromguest --guestusername root --filepath_src /var/log/messages

Here is an example of performing the "copytoguest" operation:

./guestOpsManagement.pl --server vcenter50-1 --username root --vm vMA5 --operation copytoguest --guestusername root --filepath_src /home/vi-admin/test.pl --filepath_dst /root/test.pl

There is also complete perl docs for this script which can be called using the following command:

perldoc guestOpsManagement.pl

Power off VM from Guest OS Reboot capability in vSphere 8

by // 3 Comments

In 2019, a new VM advanced setting called vmx.reboot.PowerCycle was introduced and greatly simplified the remediation of CPU vulnerabilities for our customers. The operational challenge that came with applying CPU microcode updates was that all running VMs on an ESXi host would need to go through a complete power cycle (power off and power back on) before the guest operating system(s) would be fully protected.

The new VM setting would notify ESXi to convert a guest operating system reboot into a VM power cycle operation, which aligns nicely when an organization applies a guest OS update or patch and the guest OS is then rebooted afterwards. The benefit to our customers is that the remediation of CPU vulnerabilities can co-exists with an organizations existing maintenance window and the OS is remediated through a regular guest OS reboot. From the guest OS point of view, nothing has changed, it still sees a reboot but from the VM virtual hardware point of view, a complete power cycle has occurred. A very cool and innovative solution if you ask me!?

The reason for this background, there is another use case that has also been operationally challenging which is upgrading the VM Compatibility, also known as VM Virtual Hardware. A VM must be powered off before you can change the VM Compatibility and a simliar challenge arises with coordinating the downtime of a VM with application owners/teams. What if we had a simliar capability like the guest OS reboot triggering a power cycle, but instead of power cycling the VM, it would simply power it off?

[Read more...]

How to immediately refresh the network GuestInfo using VMware Tools?

by // 1 Comment

We all know the benefits of installing VMware Tools into your guest operating system which also includes additional functionality such as the Guest Operations APIs, allowing administrators to perform operations directly within the guest (credentials required), even if networking is not available. In addition to all these benefits, customers also get better visibility into the guest such as the underlying OS that is actually installed, disk volumes and networking information such as hostname and IP Addresses for the different network interfaces.

I am assuming most of you have seen the VM Summary page in the vSphere UI and if VMware Tools is installed and running, some of the GuestInfo data will be displayed such as networking.


An interesting tidbit that I had learned recently about VMware Tools while working on Instant Cloning Apple MacOS (yup, this works!) is that there is a default polling interval of 30 seconds in which this GuestInfo data is updated. In general, this is not a problem as this type of information does not change frequently and the default should be more than sufficient for most customers.

However, if you are performing an Instant Clone and you are relying on the vSphere API and the GuestInfo data to determine the IP Address of the guest, having to wait up to 30seconds is not ideal, especially since the actual Instant Clone operation completes in just a few seconds. One option is to change the default polling interval, which I have outlined the details in the MacOS Instant Clone article, but rather than changing the default which can add some additional load, there is actually a much simpler solution.

With VMware Tools 10.1 or newer, customers now have a way to immediate initiate a refresh of the networking info, directly from within the guest. This is perfect for the Instant Clone use case where network configuration is applied through a customization script and you can then run the update command afterwards to ensure the GuestInfo data is immediately reflected. Below are the respective commands for each OS type and you will need to have administrator privileges to perform this operation.

Windows:

C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network

Linux:

/usr/bin/vmware-toolbox-cmd info update network

MacOS:

/Library/Application\ Support/VMware\ Tools/vmware-tools-cli info update network