VM /ETC

Archive for the ‘vmotion’ Category

How to increase the number of simultaneous VMotions of guests allowed between VMware ESX hosts has been covered many times already. In fact, check out the following blog posts on this topic for extra information and insight not provided here.

• Increase Simultaneous VMotions as well as Increase Performance
• Guest blog entry: VMotion performance » broche.net – VMware …
• VMware Communities: ESX Tips: Increase number of VMotions per host
• Increase number of VMotions per host

One possible scenario for changing this setting would be to temporarily increase VMotions allowed in order to evacuate ESX hosts within a short maintenance window. I prefer to leave the setting at the default, so for this scenario be sure to change it back after the maintenance is complete. if you read the links provided above, others suggest they have changed the settings permanently.

This rest of this post contains a cut and paste of the steps necessary to make the configuration change with a brief explanation about setting the appropriate value. I am pasting from a VMware Partner PDF communication assembled by Michael White, VMware engineer.

Read the rest of this entry »

It’s been well publicized that Microsoft’s System Center Virtual Machine Manager (SCVMM) can manage VMware Virtual Infrastructure. In fact, Microsoft has demonstrated that SCVMM can initiate virtual machine (VM) VMotions between VMware ESX hosts. However, Eric Gray points out on his VCritical blog that if you use SVCMM to VMotion VMs that are members of ESX Cluster Resource Pools the Resource Pool membership disappears afterwords.

The following was taken from Eric’s post Don’t know much about resource pools:

“Now, let’s say that one of your fellow administrators wants to use SCVMM to manage this VMware environment.  He uses the SCVMM console to migrate a QA virtual machine from one ESX host to another in order to perform maintenance.

The VMotion completes without incident and everything seems OK…

Before too long, a QA engineer is on the phone asking what happened to his VM.  From his perspective, the VM has disappeared.

It’s not really gone, it has just been moved out of the resource pool.  Fortunately, you can log in with the VI Client and fix this problem by moving the VM back to the resource pool.”

I must first admit I have not done this personally, but I assume 2 things are happening here.

Read the rest of this entry »

Eric Sloof’s A whiter shade of green is an informative post about how the Maps tab in VMware VirtualCenter (VC) can be used to visually confirm if a VM can be live migrated between ESX hosts. By selecting a VM in the tree explorer of VC and then clicking the Maps tab (not the Maps button), you can see a diagram of all of the ESX servers, virtual networking, and storage that must be consistently shared between hosts for VMotion to succeed. As my borrowed version of Eric’s orignal screen shot image shows, when all are configured correctly the ESX hosts have green circles around / behind them.

When the green circles do not appear, the Maps view helps troubleshoot what is wrong because you can see exactly which pieces are not connected correctly in the diagram.

What I did not realize, and Eric’s post points out, is that Read the rest of this entry »

A reader named Tom commented on my Matrix to Determine VMotion Compatibility by Processor post today asking

“has VMotion evolved at all to the point where differences between Intel chips are less of an issue than they were in June when you blogged this?? “.

It always amazes me when the virtualization blogisphere seems to be talking about the same topics, and no sooner did I finish making my comment to Tom I found the “What is Enhanced vMotion Compatibility anyway?” post from the VMGuy.

So, this post expands on VMGuy’s example using the Matrix from my June post to show how VMware’s EVC can help with previously incompatible CPUs. You decide if this is an evolution or not. Personally, I’d prefer a cluster of hosts that use like, modern hardware which all take full advantage of the latest CPU advancements. Maybe EVC is acceptable in a lab scenario, but I want all “the bells and whistles” of my processors in production.

First, VMware KB Article ID:1003212 titled Enhanced VMotion Compatibility (EVC) processor support explains how EVC works: Read the rest of this entry »

There are several whitepapers, posts and articles already available to help you determine what processor models are compatible for VMotion between ESX hosts. I will provide some of those links at the end of this post. However, I stumbled across a new matrix published by Dell that, in my opinion, offers the easiest reference by processor model for preventing VMotion boundaries. Dell’s paper titled VMware VMotion and 64-bit VM Compatibility Matrix for VMware Infrastructure 3 and Dell PowerEdge Systems contains a VMotion and 32/64-Bit VM Compatibility Across Processor Models matrix that is easy to decipher. Of course, the .pdf provides a compatibility matrix by Dell server model number too.

Download the full paper at the link above, but the following image shows the CPU compatibility matrix for quick reference. Click on the image for a larger version. Read the rest of this entry »

Chad Sakac has a great post on his Virtual Geek blog titled The Case For And Against Stretched ESX Clusters. In this post Chad discusses the possibilities of configuring ESX Clusters between 2 different physical data centers. That is, spanning the SAN across a wide area network so that VMs can be vmotioned between sites. The concept is a frequently discussed desire of many administrators, and Chad brings to light some great points for and against this design with specific configuration details about making it work with VMware ESX.

For example, the post explores several options: Read the rest of this entry »

How many VMs should run on each ESX host? The answer is determined mostly by the physical resources of the host’s platform (storage, ram, cpu, etc.). Before VI3 introduced ESX Clusters with DRS and HA squeezing as many VMs on each ESX host as possible was acceptable. Today it’s not just ESX host capacity, but ESX Clusters need to be take into consideration. Planning Cluster capacity means ensuring availability of VMs while maintaining acceptable host performance in a fail over scenarios.

First, what is a fail over scenario? The first thing that comes to mind is a problem. One or more of your ESX hosts unexpectedly crashed. This is considered unplanned downtime. Another fail over scenario to consider is planned downtime such as rebooting after applying ESX patches. For both of these types of scenarios you want to make sure your VMs stay online.

VMware’s solution for planned downtime is VMotion. The solution for unplanned downtime is the HA feature of ESX Clusters. When determining your ESX capacity be sure to allow room to leverage these features.

VMotion migrates a VM to a different ESX host without users losing connectivity. Evacuating an ESX server by VMotion enables you Read the rest of this entry »