Friday, June 29, 2012

How to Change the Splash Screen In vMA

To customize the default splash screen on vMA 5.x, you just need to edit /opt/vmware/etc/isv/welcometext which contains the version of vMA and the management URL as the default.
In addition to adding your own custom text, there are a few special variables that can use within the file and they should all be pretty self-explanatory:

${app.name}
${app.version}
${app.ip}
${app.url}
${vami.port}
${vami.url}

Here is an example of custom welcometext file:
This is a message on the vMA Splash Screen!

visit www.virtuallyghetto.com

Here are some default variables you can use:

app.name = ${app.name}
app.version = ${app.version}
app.ip = ${app.ip}
app.url = ${app.url}
vami.port = ${vami.port}
vami.url = ${vami.url}
The vami_login script is what controls the splash screen display and for the changes to take effect, you will need to restart the process. To do so, you just need to kill the current vami_login process and it will automatically respawn.

sudo kill $(ps -ef | grep vami_login | grep -v grep | awk '{print $2}')

Here is a screenshot of what the splash screen looks like after modifying the welcomtext file:
If you are interested in customizing other parts of vMA such as the MOTD (message of the day) which is the text that would be dispalyed upon a successful login, you can edit /etc/motd file. If you are interested in customizing the banner during an SSH connection, you can edit /etc/ssh/banner.

Thursday, June 21, 2012

How to Copy VMs Directly Between ESXi Hosts Without Shared Storage

There were some discussions earlier this week about copying Virtual Machines from one ESXi host to another ESXi host that reminded me of a very cool feature in the ovftool that could help with this task(which I thought I had written about already). As you probably have guessed by now, I am a big fan of the ovftool and have written several articles here, here and here. It still surprises me with the amount of features this little utility contains and this particular one is definitely a cool one!

If you have ever needed to copy a Virtual Machine from one host to another, it can be a challenge sometimes, especially if you do not have shared storage. You can of course leverage tools like VMware Converter or exporting the VM to a "middle man" system and then re-importing that VM into the destination host but it could take awhile or you have to run a Windows system. Well, if you are looking for a quick and easy way to copy a VM from one host to another, try using the ovftool.

In this example, I have two ESXi hosts called vESXi-03 and vESXi-04 and they both contain a single local datastore (no shared storage). I have a VM called vMA5 that is located on vESXi-03 and I would like to copy that directly to vESXi-04 without needing any additional storage.

Here is an example of using ovftool to probe the ESXi host to see the list of available VMs:
Note: A VM must be powered off for ovftool to transfered or exported.

Now that we have identified our VM, we just need to specify the source ESXi host and the destination ESXi host as well as the datastore using the -ds option. Here is an example of using ovftool to export the VM from one ESXi host to another ESXi host:
There are also other options that you can specify such as the network configuration and power options, please refer to the ovftool documentation for more details.

If you open up a vSphere Client connection to each of your ESXi hosts, you will see that the source host will have an export task and the destination host will have an import task as shown in the screenshot below:
Pretty nifty huh? :)

If anyone is interested in how this works, the export/import process of a VM to an ESXi host is using the NFC (Network File Copy) protocol and as long as two hosts can communicate with each other, then you can leverage ovftool to copy your VMs.

Wednesday, June 20, 2012

Thunderbolt Ethernet Adapter in Apple Mac Mini on ESXi 5

If you followed Apple's recent announcement at their WWDC conference then you would know that they just released a Thunderbolt to Gigabit Ethernet adapter. So, why am I talking about this? Well if you are running ESXi 5 on an Apple Mac Mini like me, then you are probably wondering if you can get another network interface on the Mini as it only has a single network adapter. The answer is YES!
To get ESXi 5 to recognize the Thunderbolt adapter, you will need to download and install an additional Broadcom driver (tg3 3.123b.v50.1) or you can create a customized ISO with the driver built in using the steps outlined here for a new installation.

UPDATE (12/21): A custom ESXi ISO is no longer needed, you can use ESXi 5.0 Update 2 which includes the necessary driver to support Thunderbolt Ethernet adapter. Please take a look at this article here for the details.  

If you are just installing the driver on an existing ESXi 5 installation, extract the offline bundle and upload to your ESXi host and run the following command:
esxcli software vib install -d /vmfs/volumes/mini-local-datastore-1/tg3-3.123b.v50.1-offline_bundle-682322.zip

Here is the output from ESXCLI on how ESXi sees the Thunderbolt adapter:
As you can see, it shows up with no description for the device and this is the same when running lspci, it just shows up as a network controller from Broadcom. This is not a big deal, but I assume this has something to do with the high numbering of the vmnic instead of being vmnic1 it's vmnic32.

I also performed some basic network testing by yanking the ethernet cable on the onboard network adapter and ensured traffic continued to flow and vice versa with the other Thunderbolt adapter. Everything works beautifully and now you can have some network redundancy built into your Mac Mini or if you need the throughput for all those VMs you plan on running ;)
Big thanks to Randy K. for hooking me up with a Thunderbolt adapter!


Monday, June 11, 2012

OVF Runtime Environment

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.