VM /ETC Go Green with Virtualization. Go UGLY Green with vmetc.com.

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.

• Continue reading or Leave a comment... (0)

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:

• Continue reading or Leave a comment... (1)

While doing some research to get ready to implement the new ESX 3.5 storage vmotion feature I came across some helpful blog posts, and a script that will be a real time saver.

Unlike the vmotion we are used to, you can not right click on a vm in the vi client and initiate a storage vmotion. You have to download VMware-VIRemoteCLI and install it. The VIRemoteCLI can be downloaded as:

* a virtual appliance
* a windows installer
* a linux installer

Once the RemoteCLI is installed in Windows for example,

• Continue reading or Leave a comment... (4)

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

• Continue reading or Leave a comment... (2)

I get asked this all the time. “How many NICs does ESX need? 2, 4, 6 or more?”

Well, it’s not really about how many NICs ESX needs. I’m not recommending it, but the fact of the matter is that VI3 really only needs 1 NIC per ESX host. It’s just smarter for a company to build some redundancy and load balancing into their VI design. So, let’s say then that ESX just needs 2 NICs minimum.

The real question is “How many NICs does your network infrastructure and VI performance require?” Do you have or will you have:

• Continue reading or Leave a comment... (1)

I got an email today about a problem I had not seen in a while. This company was still using local storage only and has not migrated to shared storage. So, unfortunately they have not been able to leverage DRS yet!

Here’s a cut and paste from my customer’s original email.

The process vmmemctl went crazy today for 30 seconds or so and made the machine unusable; after that, kswapd went nuts for about 30 seconds. Then things were back to normal. What’s up with that stuff? It seems every VMware virtual machine we’ve seen these kinds of problems on. They’re pretty annoying on a development machine, and really problematic on a production machine.

Here’s my reply:

It’s been a while since I’ve seen that! This problem used to occur more often in ESX 2.X days before VI3 - before shared storage, vmotion, and DRS became the norm. Back then this always surfaced when an ESX host’s physical resources were over committed.

The reason is because your ESX servers guest VMs are battling over RAM, and how ESX manages that (without DRS in VI3 Enterprise) is to write out the RAM to a balloon driver on the VMFS LUN. Unfortunately that process zaps the VM(s) and spikes the ESX CPUs.

Here’s some quick links for more about this:

http://communities.vmware.com/thread/55488

http://communities.vmware.com/message/769479#769479

http://www.vmware.com/pdf/vi3_esx_resource_mgmt.pdf ( ! ! check out page 132 for vmmemctl info )

You can try to work around this by reserving RAM for each VM to 50% of the assigned VM memory. For example, if your VM has 1GB ram then create a memory reservation for at least 512 MB RAM. That was done by default back in ESX 2.X, but it is no longer done with VI3. This will quickly limit how many VMs you can host though! Maybe start with the VMs that seem to be affected the most? I would also look closely at all of your VMs and scale back virtual RAM where possible - do all of your VMs really need all the RAM they were created with?

Of course you can always add other ESX servers and spread the VMs out across more hosts. Finally, once you get to shared storage then DRS will auto manage contention for you by auto vmotion, but you will probably still need more ESX servers!

• Leave a comment... (0)

Are you using IBM System X servers to run ESX? Are you planning on expanding your current VI with new IBM X series servers? Not sure which blades are compatible? Use this guide to make sure you do not create a vmotion boundary!

Although this is an IBM publication it does cover general processor compatibility. There are 3 tables. Table A is for IBM server compatibilties, Table B (incorrectly labeled as the first Table C) is for all Pentium processor compatibilities, and Table C is for all AMD processor compatibilities.

VMware VMotion Compatibility Guide for IBM System X and BladeCenter Servers

• Leave a comment... (1)