For some strange reason, sometimes we cannot do a VMotion. While trying to resolve this strange issue, we did found a workaround: disable and enable the VMotion port. Once that's done, manual VMotion and VMotion triggered by DRS is working again. So I made a Powershell script to find the interface where VMotion is enabled, disable it and enable it again. Pretty straightforward, but I wanted to share it anyway.

 $vc = Connect-VIServer "<your vCenter here>"
$esxhosts = Get-VMHost
foreach ($esxhost in $esxhosts) {
 $vmHostNetwork = Get-VMHostNetwork -VMHost $esxhost
 $vmHostNetwork.VirtualNic | foreach {
 if ( $_.VMotionEnabled -eq "True" ) {
 Set-VMHostNetworkAdapter -VirtualNic $_ -VMotionEnabled $false -IP $_.IP -SubnetMask $_.SubnetMask
 Set-VMHostNetworkAdapter -VirtualNic $_ -VMotionEnabled $true -IP $_.IP -SubnetMask $_.SubnetMask
 } 
 }
}

Since everybody else is giving great info about limits, reservations, shares, etc. (check out some excellent articles from duncans Yellow-Bricks and Frank Denneman their blogs), I have something to add also: the impact of using "low-normal-high" shares.

I've been at a customer once which had big performance issues. VMs were slow and they tried to solve that with shares, limits, reservations, making a big pile of unmanageable virtualization mess.

One example: they had 1 VM which they felt was not very important, so they gave it 1 vCPU and the 'low' shares setting. An other VM, a SQL database server was given 4 CPUs with the 'high' shares setting. Now in a worst case scenario (when both VMs are active and need the same resources) the ratio is: 1:16!

Now how do I get this figure? Well, we (should) all know the shares values:
low : normal : high = 1 : 2 : 4

CPU default share value is 1000 shares/vCPU. So the less important VM gets 500 shares, the 4 core database server gets 8000 shares. So once in the 17 times the less important VM was able to do CPU, and sixteen in the 17 times the database server was given access to the CPU.

On top of that, the physical server only had 4 cores, this wasn't the only servers running on the system AND they were running performance management tools which sampled every know counter in Windows and streamed that to the above mentioned database server ON THE SAME TIME.

My point is this: the low - normal - high ratio in somewhat extreme in my point of view and is misused quite often.

So what's my view on this???
Well, try to stay away from multi core VMs. If you are running multicore VMs, don't overcommit (at least not too much) and put them on a dedicated cluster. Why not overcommitting? Well, duh, you gave it multiple CPUs, so apparently those VMs need to do some processing which is very important. And since it's that important, don't overcommit. Should make sense. Else give it one vCPU.

Also, try not to use the somewhat extreme 'low-normal-high' share setting. I would say: "If a VM is more important, use a custom setting of 1200 shares/vCPU. If a VM is less important, use a custom setting of 800 shares/vCPU". That way the ratio between them isn't that extreme and nature is more balanced.

By the way, it's a relative figure, so if you leave nothing at normal (so 1000 shares) and you change all your VMs to 800 and 1200 shares (which I would not recommend anyway), you could have also done this:

Leave the less important VMs on normal and put the more important to: 1500
Leave the more important VMs on normal and put the less important to: 666

In the end the ratio is still the same, get it?

May I add vSphere has an excellent overview of all your shares, limits, reservations AND the % shares in a 'worst case allocation'? Check out the 'Resource Allocation' tab on cluster level and/or resource pool level.

Hi all. Last weekend I've received a nice mail from the VMworld Content Team with the title: "Your VMworld 2010 Session Proposal".

It appears my session is made available through public voting. So this is great news my fellow virtualization enthusiasts - you can vote for my submission.

So what submission did I send in? Well, it's all about memory counters:
"Session ID: TA6600, Session Title: Memory counters deepdive , Track: Technology and Architecture"

I quote: "During this session we will look into the available vCenter memory counters. Check out which are most important and understand what it does. Tools will be shown to test memory behavior so the best memory configuration can be found for your VMs with their OS. We will also look at the TPS, VMMemCtl and swapping operation - proving how important those processes are."

I know there is a lot of publicly information available on this topic, yet still, I think I Have Some Tricks Up My Sleeve. It will certainly be a highly technical session and I sure hope the topic encourages you to vote for my session. So go to: VMworlds Session Voting website and please vote for my session.

The voting closes on May 26th, so please don't wait too long to vote for my session.

Last night I went to the #DutchVMUG to have a 'mini-meeting'. It was all about Powershell and the VESI, a free initiative from the cool guys Vizioncore. The session was sponsored by XTG, a Dutch VATC - thanks for the facilities and excellent lab environment (Marcel van Os created a quite large lab ). The other sponsor was Vizioncore - BIG thanks for the pizza and beer, and although I didn't drink any, you could certainly tell the guys appreciated it.

The sessions were presented by no-one less then:

Victor van den Berg, XTG - http://www.vmug.nl & http://www.viktorious.nl/blog/
Arnim van Lieshout - http://www.van-lieshout.com/
Arne Fokkema - http://ict-freak.nl/
Alan Renouf - http://www.virtu-al.net/

After kickoff and a short word from our sponsors we explored the core of Powershell. Presented by (V) and (A) - Viktor and Arnim. Starting how Powershell is structured, the methods, object based objects, the variables. Little smart things like: %, $_, | and ?. They also provided excellent links to great resources, so I hope they release the slides soon. I also liked the special variables like $global:defaultVIServer to check to what servers we have a connection.

After fiddling around with Powershell in the lab, pizza and beer, we had a short message from Scott Herold, thanking us for joining the session.

Then we had the VESI presentation from Arne and Alan. To be honest, the VESI was one of those tools I installed and didn't had a lot of time to play around with. I was doing my Powershelling with PowerGUI Editor, which works fine for me. But after this session I decided to migrate all my Powershell scripts to the VESI and create a Powerpack or something. Talking about Powerpacks: Alan has build a GREAT Powerpack: the VMware Community Powerpack. This is NOT to miss, grab it from here.

Anyway, I'm off to my homelab now, implement the latest version of VESI (1.2.5 atm), download the Powerpack and start converting my scripts to the VESI!!! And Viktor, thanks again for setting up this event!

After reading Duncan's Blog posts about Resource Pools misconfigurations, I couldn't resist writing a new article about it to emphasize the problem a bit further. I've done this in Prezi to make it more interactive. Be sure to watch it fullscreen - it shows the pictures a bit better.