Monday, January 16, 2012

Something I encounter frequently in the field is the use of Resource Pools as nothing more than organizational containers. This is not a good idea as this can have many implications on your VM utilization and performance. As a best practice, you should use the folders feature in the "VMs and Templates" inventory view for organizing your VMs into logical groups. Administrators typically do this because they default to the "Hosts and Clusters" inventory view.

Frank Dennemen, among others, has a really good explanation on the impact of using Resource Pools as organizational containers. Frank goes on to explain that simultaneous vMotions are restricted under certain Resource Pool configurations, which is also documented in KB 1026102 but I noted that the KB is related to vSphere 4.x only.

Indeed, testing this out in a vSphere 4 lab I find that if I have a VM migrating from one server to another AND changing Resource Pools in the same cluster my vMotion migrations are serial (note one active and the other waiting).

However, if I perform another vMotion without changing Resource Pools, they are allowed to progress simultaneously.

So, does this limitation still apply with vSphere 5? It would appear not, but I haven't found any official statement to that effect. I did conduct an experiment with vSphere 5 in the lab and found that I was able to vMotion two VMs simultaneously under the conditions stated in the links above.

I created a three node cluster and three Resource Pools. I then placed one VM each in two of the resource pools and on two of the ESXi hosts.

From there, I kicked off a vMotion of both VMs, selecting the third host AND designating the third Resource Pool as the target. As you can see, the vMotion requests are both actively running and they eventually completed.

Other iterations mixing moves between two different Resource Pools as well as to a host external to the cluster all allowed simultaneous vMotions.

I still do not recommend using Resource Pools as folders in vSphere 5. But at least you can now employ Resource Pools without concern over this particular limitation.

Friday, January 13, 2012

I had been running my home lab's vCSA under Workstation while I played around with vShield 5 on my small, two server, ESXi cluster. Mainly because I needed the resources free for all the vShield appliances and also because I didn't want to take the chance of isolating my vCenter while I was testing vShield out.

Anyway, when I got done with vShield and cleaned up the environment I decided to go ahead and move the vCSA back to the vSphere cluster. I did this using a capability of Workstation 8 that allows you to upload a copy of a Workstation VM to a remote ESXi host. All fun and games until I powered on my vCSA.

Ruh-Roh Raggy! NO NETWORKING DETECTED!? IP address is 0.0.0.0?!

What I didn't realize is that the MAC address would change as a result of the copy. I should have known - you know that little message that pops up when you manually copy or move VM files around and then power on said guests?

Well, what's happening is vSphere trying to prevent you from shooting yourself in the foot by having duplicate MAC addresses on your network.

In the case of my uploaded vCSA, I got no such message. The MAC address of the vNIC was changed. As a result, the vCSA registered the new MAC address as a new ethernet interface - eth1. The problem is, vCSA expects to use eth0.

To fix this, I had two choices - I'll explain both, but start with the one I did first which is much easier but less "clean" and I'll tell you why I think so in my summary.

Fix "A" involves recording the MAC address associated with eth0 and then selecting manual addressing that to the vNIC of your vCSA. Note the VM has to be powered off to make this change (the image below shows a powered on VM, thus the selection is unavailable but you get the point).

The VM will now boot up and the OS of the vCSA will be happy to see eth0 again and you're in business. Oh, by the way I knew what MAC address I needed by looking at the properties of the vNIC on the source VM.

For fix "B" you'll need to login to the vCSA OS (which is SLES 11 for those interested) from the VM console and delete the /etc/udev/rules.d/70-persistent-net.rules file.

Now, this sounds pretty drastic but the file is actually auto generated by the Linux kernel device manager (udev). What's happened to my vCSA upon changing vNIC MAC addresses is that the udev added another entry to the rules file as eth1. As you can see from the output of the rules file below, eth0 is still there with the old MAC address.

So, I'll make a copy of the rules file (because I'm anal that way) and then delete it...

As I mentioned, fix "B" is the better way to go in my opinion. Simply because you don't want to run the risk of having two nodes on your network with the same layer 2 address. Plus, I just don't like manually setting things like MAC addresses unless there's a really good reason.

This fix would actually apply to any SLES virtual appliance that you may happen to copy. Frankly, this is probably a rare problem but you never know - if it happened to me, it could happen to someone else!

Tuesday, January 10, 2012

Since the announcement at VMworld 2011, I have had some interest from my customer base around Horizon Mobile and set up a couple of calls with one of the Product Marketing Managers for Horizon Mobile. She shared some great publicly available information as well as some feeds you may want to follow to stay up to date.

Increasingly enterprises want to enable a highly mobile workforce and at the same time offer a solution that is cost effective and combines the best of user choice and IT controls. Horizon Mobile will help businesses create a BYOD/BYOM (Bring Your Own Device/Mobile) program that works for everyone.