virtuallyGhetto

guestinfo

VCSA 6.5 CLI Installer now supports new ovftool argument pass-through feature

by 2 Comments

I had recently discovered a really cool new feature that has been added into the vCenter Server Appliance (VCSA) 6.5 CLI Installer while helping out a fellow colleague. For those of you who have not worked with the VCSA before, you can deploy it using one of two methods: 1) Guided UI Installer 2) Scripted CLI installer. The latter approach is great for Automation purposes as well as being able to quickly spin up a new VCSA as the UI wizard can get tedious once you have done it a few times. The VCSA CLI Installer reads in a JSON configuration file which defines what you will be deploying whether that is an Embedded, PSC or VC node and its respective configuration (networking, password, etc).

In VCSA 6.5, the CLI Installer introduces a new option in the JSON schema called ovftool.arguments. Here is the description of what this new option provides:

Use this subsection to add arbitrary arguments to the OVF Tool
command that the script generates. You do not need to fill it out in
most circumstances.

First of all, I just want to mention that this option should not be required for general deployments but it may come in handy for more advanced use cases. Behind the scenes, the CLI Installer takes the human readable JSON and translates that to a set of OVF properties that are then sent down to ovftool for deployment. Not every single option is implemented in the JSON and for good reason as those level of details should be abstracted away from the end users. However, there may be cases where you may need to invoke a specific configuration or trigger a specific ovftool option and this would allow you to provide what I am calling a "pass-through" to ovftool.

Let me give you one concrete example on how this could be useful and how we can take advantage of this new capability. Since the release of VCSA 6.0, when you enable SSH and you login, you will notice that you are not placed in a regular bash shell but rather a restricted appliancesh interface. From an Automation standpoint, it was some what painful if you wanted to change the default as this feature is not implemented within the JSON configuration file. This meant that if you wanted the bash shell to be the default, you had to either change it manually as part of a post-deployment or you would have to by-pass the native CLI Installer and manually reverse engineer the required set of OVF properties needed for the deployment which is also not ideal.

[Read more...] about VCSA 6.5 CLI Installer now supports new ovftool argument pass-through feature

How to change/deploy VCSA 6.0 with default bash shell vs appliancesh?

by 10 Comments

When logging into the new VCSA 6.0 via SSH, you will notice that you are no longer dropped into a normal bash shell but into a new appliancesh (pronounced appliance shell) environment. This new interface provides basic set of virtual appliance management capabilities including Ruby vSphere Console (RVC) access which makes the majority of operations convenient to a vSphere Administrator but it also helps restrict unnecessary access to the underlying filesystem which can be helpful from a security standpoint.

If you need to access the underlying filesystem, you can temporarily enable it by running the following two commands:

shell.set --enabled True
shell

applianceshell-default-bash
If you need to transfer files to/from the VCSA via SCP/WinSCP, you will need to change the default shell from /bin/appliancesh to /bin/bash else the operation will fail. You can easily do this by using the chsh command:

chsh -s "/bin/bash" root

If you rather have the BASH shell configured as the default after deployment and not have to go through this manual process each time, you can actually configured using the following hidden option called guestinfo.cis.appliance.root.shell

This property allows you to specify the default shell for the "root" account and you can only modify this if you deploy the VCSA using ovftool. Here is the parameter you would append to the ovftool argument list:

--prop:guestinfo.cis.appliance.root.shell="/bin/bash"

You can leverage this new property and automate the deployment of the new VCSA 6.0 and for more details be sure to check out my VCSA 6.0 Automation Series.

How to evaluate the vSphere VCSA Beta running on VMware Fusion & Workstation?

by 17 Comments

If you are taking part in the vSphere Beta (available to public to sign up but still under NDA), you may have recently noticed a new milestone release (RC) that has been made available for download. Having been a long time Beta participant when I was customer and still continuing to do so in my current role, the best way to evaluate and test new VMware software is to of course run them on top of vSphere! I know this may not be an option for everyone and the next best thing would be to use VMware Fusion or Workstation.

For those of you who have tried to run the vSphere Beta of VCSA on VMware Fusion or Workstation, you may have found that it does not work as there are some input parameters that are required as part of the new VCSA deployment. These parameters leverages OVF properties which are currently not supported in VMware Fusion and Workstation and therefore the new injectOvfEnv option in ovftool can not be used.

Having said that, VMware Engineering is quite aware that this can be challenging for many customers as well as VMware Employees who make use of Fusion and Workstation on a daily basis. That is why they have built the VCSA to be quite flexible to support both vSphere as well as Fusion and Workstation, however the process may not be completely obvious for the latter. If you inspect the latest VCSA Beta OVA, which you will need to extract from the ISO, you will notice a series of "keys" that begin with guestinfo which is just leveraging custom key/value pairs for the OVF environment.

evaulate-vsphere-beta-vcsa-on-fusion-and-workstation-0
Ideally, these are passed in from the OVF Properties using either the vSphere Web Client or the new VCSA deployment tool. However, due to the lack of OVF Property support, it can also be passed in through the VMX file of the Virtual Machine.

Here are the steps to deploy the VCSA Beta using either VMware Fusion or Workstation:

Step 1 - Download the VCSA Beta which is available as an ISO

Step 2 - Extract the contents of the ISO and add the .ova extension to following file located in vcsa/vmware-vcsa (this is the VCSA OVA)

Step 3 - Upload the OVA using either VMare Fusion or Workstation (you can either double click or just go to File->Open) but make sure you do not power it on after deployment. (this is very important)

Step 4 - Locate the directory in which the VCSA was deployed to and open up the VMX file and append the following (make sure to change the IP information and passwords based on your environment):

Note: The example above is a very basic VCSA deployment which should suffice for the majority of you. If you wish to deploy a more complex scenario, you can inspect the VCSA OVA for additional parameters and see their expected values.

Step 5 - Once you have saved your changes, go ahead and power on the VCSA. At this point, the guestinfo properties that you just added will be read in by VMware Tools as the VCSA is booting up and the configuration will begin. Depending on the speed of your hardware, hopefully in a very short amount of time you will have a fully configured VCSA that is ready for your evaluation and testing.

Here is a screenshot of running the VCSA Beta on both VMware Fusion and Workstation:

evaulate-vsphere-beta-vcsa-on-fusion-and-workstation-1
evaulate-vsphere-beta-vcsa-on-fusion-and-workstation-2
If you wanted to take this one step further and automate the entire deployment, you can leverage the ovftool to deploy the OVA as shown with the Fusion example below:

'/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool/ovftool' --name=vmware-vcsa --acceptAllEulas --allowExtraConfig /PATH/TO/VCSA/OVA '/Users/lamw/Documents/Virtual Machines.localized'

and then append the specific configuration using either an echo or here-statement. You can also do the same on Windows leveraging either plain Windows Bat script or PowerShell.

Hopefully for those of you who only have access to Fusion or Workstation, you can now also take part in the vSphere Beta if you do not have a vSphere lab that can be used. I would also recommend checking out the vSphere Beta Community as there is a new contest that launched today for finding bugs in the latest RC release. Not only can you help improve the product through your feedback, you can also win some some $$$ in doing so!

OVF Runtime Environment

by 27 Comments

I recently noticed a trend of questions from various users about extracting specific bits of information such as the version of ESXi that's running or the MoRef ID of the VM, all while within the guestOS. I had already written an article about this topic awhile back called How to extract host information from within a VM? but it seems like there is still a continued interest to easily obtain this information about the underlying vSphere infrastructure from within the guestOS.

I came across another method while researching a different topic which is to use the vApp property of a VM called the OVF runtime environment. This is a feature that has been around since the early days of vSphere 4.x, if not earlier which provides a mechanism to retrieve some of this information as well as custom properties. The OVF feature provides users with the capability to pass in any type of metadata information such as application start up parameters, network configuration, password management, etc. directly into the guestOS for flexible guest customization.

The OVF runtime environment is only available while the VM is powered and it can be accessed from either VMware Tools or from a special ISO that is mounted to the guestOS CD-ROM device. To enable the OVF runtime environment, you just need to perform these two simple steps:

1. Edit your VM and select the Options tab and enable the vApp Options:

2. Under the OVF Settings, specify the how you want to access the OVF environment by either VMware Tools or ISO Image transport:

If you are interested in enabling this using the vSphere API, take a look at the vAppConfig property. You can enable OVF runtime environment on a running VM, but the changes will not go into effect until the VM has been completely powered off and then powered back on, a guestOS reboot will not suffice.

After the settings have been applied, go back into the OVF Settings for a powered on VM and you now should be able to click on the "View" button which will show you the OVF runtime environment for that particular VM.

For a vanilla VM, you should see three basic things:

  • The vCenter MoRef of the VM (vApp property is only available with vCenter and not on a standalone ESXi host)
  • The hypervisor name and version
  • The network (Portgroup/Distributed Portgroup) the VM is connected to

To retrieve this same information from within the guestOS you have two options:

VMware Tools

Run the following command:

vmtoolsd --cmd "info-get guestinfo.ovfenv"

Below are two examples for both a Linux and Windows VM:

ISO Image

Mount the CD-ROM in the guestOS and inside you will find the ovf-env.xml file which contains the OVF runtime environment information.

As I mentioned earlier, you can also create custom key/value properties which can then be accessed by the guestOS VM. If you go to Advanced section and click on the Properties button, you will be able to add your own custom properties. Below is a screenshot of adding three customer properties called: application_owner, startup_option and system_owner just to give you an idea of the possibilities.

The OVF runtime environment does not just stop with vSphere, but it is also available to VMs running in vCloud Director. The only requirement is that vCloud Director VMs has the vApp options enabled at the vSphere layer as noted earlier. Below is a screenshot for a VM that has been imported into vCloud Director from vSphere and you will notice some additional "vCloud Director" specific properties.

Even though the OVF runtime environment makes it easier to retrieve some of these "underlying" infrastructure details, I am still interested in some of the use cases where you would need to know the hypervisor version or MoRef ID from within the guestOS. If you are currently requiring this or other bits of information, please leave a comment about your particular use case.

How to extract host information from within a VM?

by 28 Comments

From time to time, I see this question come up asking how one might be able to extract a certain piece of information from either ESX(i) or the management APIs (vSphere API) from within a virtual machine. The simple answer is you can not, by default the guest operating system has no idea of the underlying hypervisor nor does it have the access to the management APIs. This of course, assumes you are following VMware's best practices in isolated and segregating off your management network from your virtual machine network.

Having said that, there are certain bits of information that you can extract about your ESX(i) host from within the guestOS using some of the utilities that is installed with VMware Tools. The first utility is called VMware Toolbox command which can be found on both UNIX/Linux and Windows systems that have tools installed.

UNIX/Linux - /usr/bin/vmware-toolbox-cmd

Windows - C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe

This utility provide some information about ESX(i) and guestOS configuration including basic resource statistics.

One interesting sub-command is the resource statistics about both ESX(i) and guestOS such as speed of the hypervisor's CPUs or the current balloon, swap, memory limit, memory reservations, cpu limit or cpu reservations.

Here is an example of retrieving ESX(i) CPU speed.

As I mentioned before, you do not have access to the management network that your ESX(i) are on and that also means you do not have access to the vSphere APIs. What if you wanted to to associate a specific piece of information from ESX(i) and be able to access that piece of information from the guestOS? You can do so with the vmtoolsd (VMware Tools Daemon) utility.

UNIX/Linux - /usr/bin/vmtoolsd

Windows - C:\Program Files\VMware\VMware Tools\vmtoolsd.exe

This utility has an option called --cmd that allows you to run various commands including one that allows you to extract guest information using the "info-get" parameter. This guestinfo can be set using two methods:

1) Hard-coded within the virtual machine's .vmx configuration file
2) In VMX memory while a virtual machine is running within ESX(i)

Option 1 is pretty straight forward, you can add a custom attribute that has the following format:

guestinfo.[variable] = [value]

e.g.
guestinfo.provision.date = "01/11/2011"

You can use the vSphere Client to add this custom attribute while the virtual machine is powered off or you can manually edit the .vmx configuration file. If you use the latter, you will need to reload the VM's configuration, you can use vim-cmd vmsvc/reload.[vmid] to do so. One the VM is powered on, you can extract this piece of information, here is an example:

Option 2 is actually pretty interesting as the configuration of the custom guestinfo variable is not permanently stored. What I mean by this is the configuration is only persisted while the VM is running. This is interesting because if you have runtime information that potentially could change, this allows you to dynamically present this information to the guestOS. One use case could be set for management VMs such vCenter running in a VM and you wanted to know at any given time which ESX(i) host is currently managing it. This can be trivial with vCenter access, but what if the service is offline but the virtual machine is still running? Using the classic ESX Service Console command vmware-cmd you can loop through all powered on VMs and set some custom variables for example the current hostname of the ESX host managing the VM and version it is currently on.

The syntax for the command would be the following:

vmware-cmd [VM_VMX_PATH] setguestinfo [VARIABLE_NAME] [VARIABLE_VALUE]

e.g
vmware-cmd /vmfs/volumes/4a48004d-f9af7fa0-5bbf-003048d9586b/scofield/scofield.vmx setguestinfo hypervisor.hostname $(hostname)

Note: Notice, you do not need to append the keyword guestinfo, you just need to specify the variable name. Once you are in the guestOS, to access the custom variable, you will need to specify the full name which should be "guestinfo.[VARIABLE]"

As you can see this can be tedious to set for each and every VM, so let's automate this using a script that will go through all powered on VMs and set two custom variables called "hypervisor.hostname" which will set the current hostname of the ESX host and "hypervisor.build" which will retrieve the build of your ESX. To further automate this since you might have multiple ESX hosts running in a DRS cluster, you would store this script in a shared storage (VMFS and/or NFS) and setting up a cronjob that would run at some interval to always provide the latest information to the guestOS.

Here is an example of a shell scrip that does exactly that:

You will want to save this script to your ESX host and make sure the script has executable permissions for it to execute. You will also create a cronjob based on how often you want the script to run and this needs to be configured for every ESX host that you would like to take part in this update.

Here is an example of running the script every hour:

0 * * * * /vmfs/volume/shared-storage/setGuestInfo.sh > /tmp/out

Note: I redirect the output to /tmp/out to ensure that script is in fact working and once you have, you can remove that all together.

Here is an example of extracting these two custom variables on both a Linux and Windows VM:

As I mentioned earlier, option 2 does not persist these custom variables with respect to the VM's configuration file. The variable configuration only takes affect when the VM is powered on and once it is powered off, the information is discarded. To support ESXi, you can use the various vSphere SDKs (vSphere SDK for Perl, PowerCLI, etc) but what you will find is that the behavior of setting this attribute is similar to that of the local vmware-cmd on classic ESX, it does not append the entry into the .vmx configuration file.

Here is a vSphere SDK for Perl script called addVMAdvParamOption.pl that can be used to guestinfo parameter for a given VM. Here is an example of this script:

If you are using vMA, you can also use the vCLI's vmware-cmd utility to set this variable. The format is slightly different than that of the classic ESX's vmware-cmd. Here is an example of this:

Notice, the variable name must include "guestinfo." keyword before specifying the variable name.

If you wanted to persist these configurations, you will need to adjust your provision workflow to append the variables into the VM's .vmx configuration file.