WilliamLam.com

How to run Nested RHEV Hypervisor on ESXi?

by // 6 Comments

I have written a number of articles about VMware Nested Virtualization and even today, I am still surprised at how easy it is to virtualize not only our own hypervisor but other vendor's hypervisors as well. This week I received an interesting question from my old Technical Marketing colleague Rawlinson Rivera who wanted to run a nested RHEV (Red Hat Enterprise Virtualization) Hypervisor on ESXi. This was not something I had done before nor had any interest in doing and I told Rawlinson that it should technically work as long as the guestOS is enabled with VHV.

Rawlinson's attempt at installing RHEV resulted in the VM hanging after boot up. After a bit of research, it turns out some additional tweaks are required to get RHEV running on ESXi. I would like to give a huge thanks to Jim Mattson, one of the VMware developers who help made Nested Virtualization possible, for his assistance.

Disclaimer: This is not officially supported by VMware. Please use at your own risk.

Here are the instructions on creating a virtual machine that can be used to install RHEV (make sure you follow these exact steps, the VM must be created with these settings or it will not work):

Step 1 - Download RHEV 6.3 or 6.4 from Red Hat's website

Step 2 - Create a new Virtual Machine (vHW9) and when you get to the OS selection, you will need to select the following:

Guest Family - Other
Guest Version - Other (64-bit)

Step 3 - When you get to the virtual hardware customization, make sure you select LSI Logic SAS for the SCSI controller and also enable VHV under the CPU option.

Step 4 - Finally, you will need to add the following two advanced virtual machine settings:
vcpu.hotadd = false
apic.xapic.enable = false

Step 5 - Mount the RHEV ISO and once the VM starts to boot up, when you are presented with install/upgrade options, hit the TAB key. This will allow you to change the boot parameters and you will need to move your cursor to the left and remove "quiet" from the command-line which is right after the install keyword and then hit enter.

Note: This is required due to a known issue from Red Hat.

Step 6 - If everything was successful, you should be prompted with RHEV installer:

Step 7 - Once the installer has completed and you reboot, you now have nested RHEV running on ESXi!

Now it is time to delete the VM 😉

Quick Tip - Correlating VMFS Datastore to Storage Device Using ESXCLI

by // 1 Comment

There was a question on Twitter this morning from AJ Kuftic on whether it is possible to display the mapping of a VMFS Datastore to its respective storage device using ESXCLI. Josh Coen beat me to the answer this morning, but yes it is possible using ESXCLI. I thought I still share this quick tip as it may not be obvious, especially when you need this information while performing a storage maintenance or troubleshooting with your storage administrator.

For those of you who are familiar with the legacy esxcfg-* commands, this information can be retrieved using the following command:

esxcfg-scsidevs -m

You can also retrieve this same information by using the following ESXCLI command (can be executed remotely as well):

esxcli storage vmfs extent list

As you can see from both screenshots, we can easily identify the name of the VMFS datastore and the specific storage device it is mapped along with other pieces of information. I prefer the ESXCLI method as it is nicely formatted along with the title header for each property.

Whitepaper: Migrating From VIX API to the vSphere Guest Operations API

by // 7 Comments

The VMware VIX API in my opinion is still one of the most powerful and undervalued API's that is available to customers and partners for Virtual Machine guest operating system Automation. The VIX API allows you to perform guest operations such as starting/stopping an application, file/directory manipulation, uploading/downloading files all within the guest operating system without requiring any network connectivity to the Virtual Machine. This is all made possible through the use of VMware Tools that is running inside of the Virtual Machine and operations are only performed after a user of the guestOS is properly authenticated.

Guest Operations using vSphere API

The use cases for such an API are endless:

  • Network reconfiguration (Re-IP for DR or miss-configuration)
  • Operating System configurations
  • Application configurations or deployments (example of this)
  • Backup/Restore for individual files
  • Downloading log files for troubleshooting
  • The list goes on ....

The VIX API was first introduced as a separate client API supporting VMware's hosted products such as VMware Fusion, Workstation and Player and later supported VMware vSphere. The API was quite popular for the hosted products and with the release of vSphere 5.0, the VIX API was finally integrated into the vSphere API to provide a single API that could manage all aspects of vSphere as well as these new guest operations APIs for your Virtual Machines. With this integration, these new APIs are now known as the vSphere Guest Operations API.

If you are familiar with the VIX API and would like to move or migrate to using the new Guest Operations API within vSphere, there is a really useful whitepaper that I recently came across called Transporting VIX Guest Operations to the vSphere API that provides a nice mapping of the API methods between the VIX and new vSphere Guest Operations API. The whitepaper also includes various code samples using Java, PowerCLI cmdlets and vSphere SDK for Perl to demonstrate the new Guest Operations APIs.

I think every vSphere administrator or developer should be familiar with the capabilities of the VIX and Guest Operations API and how it can help them further automate and manage your guestOSes and the applications that run inside of them.

Additional Resources: