I read a blog post over at Windows IT Pro recently that prompted this post. Mr. Greg Shields asks the question “When was the last time you VMotion-ed?”

To answer your question Mr. Shields, I did it just this morning and once this afternoon. Nobody even noticed.

Mr. Shields goes on to quote one of his clients:

Well, we thought about that.  But we found that we really don’t use VMotion pretty much ever.  We know that we can use VMotion, and sometimes we do.  But, our performance is acceptable so we don’t need DRM, and we find that that we’re really never doing activities that require us to relocate or re-balance our virtual machines.

With a followup to this:

That response really got me thinking about the uses of VMotion in contrast with all the publicity its feature gets in the IT press:

• You use VMotion prior to rebooting a host.
• You use VMotion to re-balance load (often through DRM’s automated processes)
• You use VMotion’s HA after an unexpected failure.

Since Mr. Shields didn’t mention a product that does not have a feature like Distributed Resource Scheduler (hence, the argument against it), I won’t either. However, considering the source, I can tell you that it is probably a Redmond-based product.

So, here is my response to Mr. Shields, since he asked:

Just a few small points to clarify for those new to VMware that may be reading this.

First, VMotion and HA are two different things. You don’t use “VMotion’s HA”.

HA or High Availability is when you have a host failure (for unplanned downtime).

VMotion is a live migration (for planned downtime such as maintenance). I find that those new to VMware get these two confused all the time.

DRS (Distributed Resource Scheduler), not DRM (Digital Rights Management?) is a feature that VMware uses to balance the load across the cluster of available host resources utilizing the VMotion functionality.

Having cleared up those few items, here is my perspective.

My clients like being able to use VMotion to do maintenance during normal business hours on their hosts. I see it all the time.

My clients also enjoy not worrying about performance at the host level (like you would do in the physical world) by utilizing DRS. As long as they have enough resources in the cluster and their virtual infrastructure architecture is properly designed, they don’t have to worry about manually placing or load balancing their VM’s on certain hosts.

In summary, I’m all for VMotion and DRS. You can leave DRM in iTunes. I buy all my music DRM free from Amazon anyway .

I was recently setting up a Capacity Assessment for a client when I ran into an issue with perfmon. Perfmon is used on the physical windows servers to collect performance information. This information is used to help determine the best route (design, hardware specs., etc.) to virtualization for the physical servers. However, upon trying to collect the information on some systems I received an error that the performance counter “object was not found.” The VMware Capacity Planner data manager will tell you that this error is usually due to traffic not getting through a firewall or anti-virus product on the server.

I did some digging and found that the firewall was not the problem. I opened up perfmon directly on the problem servers and found numbers for counters instead of the names. This told me that I had corrupt counters. The fix in this case was really simple. I copied the counters (*.dat files) from a server that the performance metrics were working on (same OS) to the problem servers.

The two files in question are %systemroot%\system32\perfc009.dat and %systemroot%\system32\perfh009.dat.

Once these files were replaced with the ones from the good server, I restarted perfmon and the counters were there. The data collection could continue. There is a chance that you may need to dig a little deeper to restore the counters in your specific scenario. The following Microsoft KB article should help: KB300956

A bug was discovered that caused an ESX PSOD on a host if you try to upgrade it to vSphere 4.0 Update 1 AND you have third-party management agents installed on the host. The details are in the VMware knowledge base KB1016070 article.

This bug offers two reminders of practices that should be followed when possible.

• Don’t update your ESX hosts right away when a new update number is released. Give it 3-6 months and follow the community for serious bug information.
• Try to keep third-party agents out of your Service Console. Some will say that they are there to alert the administrator of “failures.” However, that does absolutely no good if they cause the failures themselves.

I ran into a situation recently with a client that had an Exchange server VM that would not start due to a locked VMDK file on the ESX host. I am writing this post to remind myself and others how to unlock a VMDK (or any open file) on an ESX (with Service Console) host without rebooting the host. Why couldn’t I reboot the host? Here’s the story.

I was called in to help a client with an ESX 3.5 host failure in their environment. HA had kicked in, but they only had one host available (with multiple VMs already running on it) and the Exchange server VM would not boot. I got the Exchange server to boot, but that is a story for a different post . When the Exchange VM booted, I discovered that the system volume (C:) was nearly out of space. So, the Exchange Transport service would not start. So, I used VMware Converter to convert the existing Exchange VM to a new VM on the same ESX host with a larger system volume (C:).

However, there was a catch. I couldn’t convert the system volume (C:) and the data drive for the Exchange VM. There was not enough space on the datastore. So, I just converted the system volume (C:) and re-sized it accordingly. Then, the plan was to move the data drive into the newly converted VM’s folder and attach it to the VM. It would have worked too, if it wasn’t for that meddling open file lock. I got the old “Cannot start <VMName> because there is a lock on a file” error when I tried to start the new VM.

I verified that the original Exchange VM was powered off, so I figured it must be a hung process that had the VMDK file still open. Here is how you can find and kill the process.

• Log on to the Service Console of your ESX host.
• Use the Linux lsof (list open files) command along with grep to find the VM process that is responsible for locking your VMDK file.
  • lsof |grep vmname (Where vmname is the name of the VM in question.)
• Then, kill any processes that have your VMDK file open with the kill -9 pid command (Where pid is the process ID of the offending process).

That’s it! Next time you find yourself needing to kill a process on your ESX host instead of rebooting, you can just track it down.

The folks over at the VMware knowledge base have a new ESX and ESXi 4.0 comparison that is similar to the ESX and ESXi 3.5 comparison.

ESX and ESXi 4.0 Comparison

ESX and ESXi 3.5 Comparison

My new article has been published at SearchVMware.com. Partition alignment is often forgotten by busy administrators. However, if you forget to align your partitions, you could be missing some disk performance in your virtual infrastructure. Here is an excerpt from my latest article:

Since VMware enables you to create new virtual machines (VMs) from a template, investing the time to make performance tweaks on a single VM that will be used as a template for others can provide a noticeable system-wide performance boost. One way to gain performance is by aligning disk partitions, which enables faster disk reads. In this tip, we’ll cover how to boost overall performance from Windows-based virtual machines by aligning disk partitions for a template VM, which can then be used to create other, properly-aligned and performance-enhanced VMs.

You can read the rest of the article at SearchVMware.com. Happy Reading!