Skip navigation
2012

I'm a big fan of the VMware Labs flings. Flings are described by VMware Labs as "...a short-term thing, not a serious relationship..." and the Thinapped vSphere Client is one of the best flings available. If you have never used the Thinapped vSphere Client, then all you need to know is that it is a fully functioning vSphere Client delivered in a single executable file. And now version 5.0 U1 is out, which means I can start enjoying this fling in my vSphere 5 environments.

 

The Thinapped vSphere Client proves extremely useful for many of the users I work with who don't (or can't) install software on their machines. At 92MB in size, it can also be a much faster download than accessing the 350MB installer from vCenter Server. I also find it very useful on servers (think Windows backup servers) where I don't necessarily want to install any more software than I absolutely have to.

 

If you haven't checked out the Thinapped vSphere Client, then now might be a good time!

 

Thanks for reading,

Brian

I recently needed to create a Windows 2008 R2 template on a remote vCenter Server. Rather than start from scratch and create a new "golden image," I converted an existing Windows 2008 R2 template to a virtual machine and used VMware Converter to move it to the remote site. Both sites are using vCenter Server 5.0.0 build 623373 and ESXi 5.0.0 build 702118. After Converter had completed, I converted the VM to a template on the remote side and imported the exported Windows 2008 R2 guest customization specification. I then tried to deploy a virtual machine from this template. I chose the newly imported guest customization specification and was presented with the following error, after completing the deploy template wizard.

 

Customization  of the guest operating system 'windows7Server64Guest' is not supported  in this configuration. Microsoft Vista (TM) and Linux guest with Logical  Volume Manager are supported only for recent ESX host and VMware Tools  versions. Refer to vCenter documentation for supported configurations.

 

Since both vCenter Servers and all ESXi hosts were running the same versions, this error was confusing. The latest version of VMware Tools was also already installed in the template, which made this error message even more confusing. To troubleshoot, I converted the template back to a virtual machine and powered it on. After logging in, it was pretty obvious that something was wrong with the VMware Tools since the mouse behavior was very erratic. I uninstalled the VMware Tools, reboot the VM, and installed the VMware Tools again. After another reboot and power down, I converted the virtual machine back to a template. This time the deploy template wizard worked as expected and a new VM was deployed from the template.

 

This is another one of those weird events that I figured I would post in hopes of maybe helping others that run across it.

 

Brian

A large part of writing the VCP5 Study Guide was creating many exercises around the exam objectives. One of the items covered in exam objective 2.1 is to Add/Configure/Remove vmnics on a vNetwork Standard Switch. I thought it would be interesting to detail the steps I used to test this exercise.

 

This entire lab setup was running in VMware Workstation. For this exercise, there is a single ESXi 5 host and the vMA 5 is also used. The ESXi host has vSwitch0 for management traffic only and the VM Network port group has been removed from it. A vSwitch1 was built with a single NIC (vmnic1) and a single port group for virtual machine traffic. On this ESXi host are two VMs each with 256MB, 1 vCPU, and an e1000 NIC that boot to a Ubuntu 9.04 LiveCD and connect to the virtual machine port group on vSwitch1.

 

I first started by powering up each VM and waiting for Ubuntu to boot. I then set up continuous pings to the ESXi host's management address from the VMs running Ubuntu. I issued the resxtop command on the vMA and pressed the N key to view the network information. Here is what I saw.

blog-num1.png

As expected, both VMs (VM2 and VM3) are using vmnic1.

 

The next step was to add a second NIC (vmnic2) to vSwitch1. I did this using the vSphere Client. Here is what I saw in the vMA.

blog-num2.png

Notice that VM2 is now using vmnic2. The Linux continuous ping ran uninterrupted throughout this process.

 

The final step was to remove a NIC (vmnic1) from vSwitch1. I did this using the vSphere Client. Here is what I saw in the vMA.

blog-num3.png

Notice that both VMs are now using vmnic2. And again, the continuous ping did not stop running!

 

Adding and removing vmnics from a vSwitch is a nondisruptive process, and the testing detailed above proves this.

 

As always, thanks for reading!

Brian

I recently set up an environment with two vCenter Servers using linked mode. The first vCenter Server 5 had been an existing vSphere install that had been upgraded several times and the second vCenter Server was a fresh install of vSphere 5 at a second site. Some time after this was completed, while connected to the first vCenter Server via the vSphere Client, I noticed that several of the larger datstores on hosts managed by the new vCenter Server at the secondary site had alarms triggered for datastore usage on disk. I eventually realized that the default values were still in use on the new vCenter Server, and this second environment regularly exceeds these defaults. I went to edit the alarm settings of the "Datastore usage on disk" alarm definition and clicked the Triggers tab. I was presented with the following message: The triggers for this alarm cannot be displayed or changed through the vSphere Client. Use the vSphere API to modify these alarm triggers.

 

My first thought was that this must be due to the clean install of vCenter Server 5 at the second site and that there was no way I was going to have to resort to using APIs to make this change. A quick Google search didn't turn up much in the way of results, and then I had a thought. What if linked mode was somehow behind this? I started up another instance of the vSphere Client and connected directly to the vCenter Server at the secondary site. Just as expected, everything works normally with this approach and the trigger values can be adjusted as expected. I made the changes and the warnings cleared on these datastores!

 

I tried several other alarm definitions and this behavior is not consistent. Some can be modified across vCenter Servers and others present the same message documented above. Hopefully this information will help anyone else that stumbles upon this condition.

 

Thanks for reading,

Brian