WilliamLam.com

Nested Virtualization Resources

by // 7 Comments

Here is a consolidated page on all the articles that I have written about the Nested Virtualizatoin (nested ESXi, Hyper-V, etc) and all the goodies that are "Not Supported".

vSphere / vCloud 5.1

vSphere / vCloud 5.0

Additional Info/Tips/Tricks/

Ghetto webAccess for ESXi

by // 14 Comments

I got the idea for this post a few months back after noticing several questions on the VMTN forums on how to enable webAccess for ESXi. With ESXi, the webAccess interface is no longer available as it was with classic ESX. After seeing the question and randomly browsing through the various flings on VMware Labs, I noticed an interesting fling called Ops Panel for ESX. Ops Panel provides a simple javascript that leverages the vSphere MOB to perform basic power operations for virtual machines and it is loaded onto the homepage of a classic ESX host remotely using Greasemonkey.

I immediately wondered if I could run the javascript directly on an ESX or ESXi host without the use of Greasemonkey. With a quick tweak of the default index.html homepage, I was able to get a simple "ghetto" webAccess running on both an ESX and ESXi host. I also ran into several bugs, one that dealt with how the power state of a virtual machines was being captured by the differences in the ESX(i) 4.0, 4.1 and 5.0 APIs and a recent fix to a CSRF (Cross-Site Request Forgery) vulnerability in ESX(i) 4.1 Update 1 that made it difficult to get Ops Panel running on more than just ESX(i) 4.0.

I reached out to the fling creator Ivan Donchev and he was kind enough to help assist me in the issues I ran into and also provided an updated version of his script to properly handle both the power state and the CSRF workaround. He recently published an update to his script a few weeks back supporting both ESX 4 and ESXi 5 but missed ESX(i) 4.1 support due to limited amount of testing. This was an easy fix and I modified the script to include support for ESX(i) 4.1 and also changed the default power off operation to a guestOS shutdown. The modified version of the script can be downloaded here.

When you browse to the homepage of your ESX(i) host using the browser, you will be prompted to login which require the same credentials as if you were to login to the host directly using the vSphere Client or vSphere MOB.

Once you have logged in, it will search for all virtual machines running on the host and generate the list of virtual machines and their respective power states.

You can then perform the appropriate power operation such as a power on, shutdown or suspend using the icons on the right. This can be really useful if you don't have access to vCenter Server, vSphere Client or SSH access to the host but just have a web browser.

To load the Ops Panel script on an ESX(i) host, you will need to do the following:

Note: These instructions are applicable for both ESX and ESXi, but with ESXi, it is important that the commands to copy both the modified index.html and Ops Panel script to docroot are executed as changes are not persisted after a reboot for ESXi hosts.

You can also add this to your kickstart file by appending the lines above in your %firstboot stanza so you automatically get Ops Panel after install. Though this will not give you a full webAccess that classic ESX did but it definitely is a useful way to quickly get to your virtual machines and perform simple power operations using a web browser.

How to Disable a vmnic in ESX(i)

by // 8 Comments

There was another interesting thread today on the VMTN community forums about disabling an unused vmnic from an ESXi host due to false alarms being generated from HP SIM. Due to the specific hardware version, disabling the vmnic through the BIOS was not an option and there were no alternatives from the discussion.

I decided to dig a bit to see what I could find and stumbled upon a neat little utility called vmkchdev (VMkernel Change Device?) and from what I can tell provides a method passing a particular device to be controlled by either the VMkernel or as a passthrough device to a virtual machine (think VMDirect Path).

Disclaimer: Please note, this is using an undocumented utility. You should test this out in a development/lab environment before using and you may want to also contact VMware support to get their blessings***

~ # vmkchdev
Usage:
-s (scan device)
-v (give device to vmkernel)
-p (give device to passthru/VM)
-l (list device state)
-L (list device state with details)
[0x][seg:[bus[:slot[.func]]]]

What I found while testing the utility is by passing it over as a passthrough device, the vmnic is actually unrepresented to the VMkernel and does not show up under network adapters or even the unused/unlinked adapter list in the vSwitch configurations. It seems that it is just masks the device away from the VMkernel as you can still see the active configuration in esx.conf and you can see the device listed using vmkchdev.

Here is an example of an unused physical nic vmnic1 that we would like to disable and unpresent to an ESXi host.

Here is the output from esxcfg-nics:

First we need to identify the vmnic's PCI slot, we do by running the "-l" or list operation and searching for the particular vmnice device.

~ # vmkchdev -l | grep vmnic1
000:002:01.0 8086:100f 15ad:0750 vmkernel vmnic1

Next we will pass the device from the VMkernel to passthrough/VM using the "-p" flag and specifying the PCI slot, which in this case it is 000:002:01.0. We will also need to refresh the network section so the changes are reflected in the vSphere Client by using vim-cmd.

~ # vmkchdev -p 000:002:01.0
~ # vim-cmd hostsvc/net/refresh

If we list our vmnic again using vmkchdev, you will notice the device is now owned by passthru versus the VMkernel.

~ # vmkchdev -l | grep vmnic1
000:002:01.0 8086:100f 15ad:0750 passthru vmnic1

Now if we check the output of esxcfg-nics and the vSphere Client, you will notice that vmnic1 is no where to be found

If you would like to enable or re-present the disabled vmnic, you just need to pass the device back over to VMkernel by using the "-v" flag.

~ # vmkchdev -v 000:002:01.0
~ # vim-cmd hostsvc/net/refresh

Your vmnic should now re-appear on all your screens and any existing NIC teams that may have exists is automatically restored. This trick actually works on both a used and unused vmnic

If you are trying to do this on ESX, vmkchdev actually has an additional option called "console" for the Service Console.

[[email protected] ~]# vmkchdev
Usage:
-s (scan device)
-c (give device to console)
-v (give device to vmkernel)
-p (give device to passthru/VM)
-l (list device state)
-L (list device state with details)
[0x][seg:[bus[:slot[.func]]]]

I found that you need to pass the vmnic from VMkernel to Console, passing it to passthru/VM will not work and an error is thrown if you do. Again, you can easily re-enable by passing it back to the VMkernel

vmkchdev -c 000:002:01.0

If you would like to automatically persist this change across reboots, specifically for ESXi as changes are not saved. You will need to add the following lines to /etc/rc.local which will execute the disabling of the vmnic's after bootup.

/sbin/vmkchdev -p 000:002:01.0
vim-cmd hostsvc/net/refresh

You will also need to run /sbin/auto-backup.sh to ensure the changes to /etc/rc.local are saved and reloaded upon the next reboot. For ESX, you can place it in /etc/rc.local without having to do anything extra as the changes persists across reboots for classic ESX

Now you can play hide and seek with your vmnic's without resorting to a system reboot or touching the BIOS. Though ideally, if you do have unused devices, you should definitely disable them in the BIOS if you have the option. On a side note, this might be a fun trick to play on one of your co-workers by hiding all vmnics 😉