Yellow Bricks

by Duncan Epping

vmotion

MS Virtualization blogs and VMotion

· ·

Recently there was an article published on the Microsoft Virtualization Blog which compared Hyper-V’s High Availability/Quick Migration capabilities to VMware’s VMotion. (VMblog pointed me towards the article) In the second article the writer responds on a large amount of reactions he had regarding VMotion being superior:

After my last blog I received almost two dozen email telling me that VMotion was far superior for unplanned host downtime and that it was a much better HA solution because it could live migrate virtual machines. I’ve heard this fallacy espoused for many years and, folks, this simply isn’t the case.

In the case of unplanned downtime, VMotion can’t live migrate because there is no warning. Instead you must have VMware HA configured and the best it can do is restart the affected virtual machines on other nodes which is the same as what is provided with Windows Server 2008 Hyper-V and Failover Clustering.

I can imagine why people reacted, in the first post the writer only mentioned VMotion. For unplanned downtime VMware doesn’t use VMotion because when it’s unplanned the VM’s get cutoff and will be restarted on another host with the use of HA(VMware High Availability). There’s no need for a migration when a VM is powered off.

Indeed Microsoft can do the same with the use of Clustering. But can you live migrate virtual machines when a server needs maintenance? No, at this moment that’s not possible. In other words, you will have to wait for a suitable moment… planned downtime, probably after business hours. But in a 24×7 environment will there ever be a suitable moment? Even when your business isn’t 24×7, if there’s a possible hardware failure would you want to wait? But when you have a 8:1 consolidation ratio you probably will not be the most popular system engineer when “quick migrating” the file server or the mail server especially when these VM’s have a lot of RAM assigned.

Besides that, with the upcoming new product, Continuous Availability, even unplanned downtime will not crash your VM. CA will constantly mirror your VM to another host, like a continous VMotion I guess, and when the active host fails the standby host will become active. In other words, no unplanned downtime anymore.

CPU utilization increasing after VMotion in a DRS enabled cluster

· ·

VMwarewolf already posted this fix on his blog but had to remove it… Now VMware added it to their knowledge base. Check out the original article because it may change in time. For the lazy people I included how to diagnose the problem and more…

Diagnose the problem:

  1. Use the VI Client to log in to VirtualCenter as an administrator.
  2. Disable DRS in the cluster and wait for 1 minute.
  3. In the VI Client, note the virtual machine’s CPU usage from performance tab.
  4. In the VI Client, note the virtual machine’s memory overhead in the summary tab.
  5. Enable DRS in the cluster.
  6. Use VMotion to move the problematic virtual machine to another host.
  7. Note the virtual machine CPU usage and memory overhead on the new host.
  8. Disable DRS in the cluster and wait for 1 minute.
  9. Note the virtual machine CPU usage and memory overhead on the new host.

If the CPU usage of the virtual machine increases in step 7 in comparison to step 3, and decreases back to the original state (similar to the behavior in step 3) in step 9 with an observable increase in the overhead memory, this indicates the issue discussed in this article.

You do not need to disable DRS to work around this issue.

The workaround:

  1. Use the VI Client to log in to VirtualCenter as an administrator.
  2. Right-click your cluster from the inventory.
  3. Click Edit Settings.
  4. Ensure that VMware DRS is shown as enabled. If it is not enabled check the box to enable VMware DRS.
  5. Click OK.
  6. Click an ESX Server from the Inventory.
  7. Click the Configuration tab.
  8. Click Advanced Settings.
  9. Click the Mem option.
  10. Locate the Mem.VMOverheadGrowthLimit parameter.
  11. Change the value of this parameter to 5. (Note: By default this setting is set to -1.)
  12. Click OK.

To verify the setting has taken effect:

Log in to your ESX Server service console as root from either an SSH Session or directly from the console of the server.

  1. Type less /var/log/vmkernel.

A successfully changed setting displays a message similar to the following and no further action is required:
vmkernel: 1:16:23:57.956 cpu3:1036)Config: 414: VMOverheadGrowthLimit” = 5, Old Value: -1, (Status: 0x0)

If changing the setting was unsuccessful a message similar to the following is displayed:
vmkernel: 1:08:05:22.537 cpu2:1036)Config: 414: “VMOverheadGrowthLimit” = 0, Old Value: -1, (Status: 0x0)

Note: If you see a message changing the limit to 5 and then changing it back to -1, the fix is not successfully applied.

To fix multiple ESX Server hosts:

If this parameter needs to be changed on several hosts (or if the workaround fails for the individual host) use the following procedure to implement the workaround instead of changing every server individually:

  1. Log on to the VirtualCenter Server Console as an administrator.
  2. Make a backup copy of the vpxd.cfg file (typically it is located in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg).
  3. In the vpxd.cfg file, add the following configuration after the <vpxd> tag:
    <cluster>
    <VMOverheadGrowthLimit>5</VMOverheadGrowthLimit>
    </cluster>
    This configuration provides an initial growth margin in MB-to-virtual machine overhead memory. You can increase this amount to larger values if doing so further improves virtual machine performance.
  4. Restart the VMware VirtualCenter Server Service.Note: When you restart the VMware VirtualCenter Server Service, the new value for the overhead limit should be pushed down to all the clusters in VirtualCenter.