VM /ETC

Posts Tagged ‘drs’

I thought I was done blogging about VMware Partner Exchange 2010, but, twist my arm, there seems to be enough public knowledge about an upcoming feature of vSphere that I thought I would briefly point it out.

Steve Herrod discussed in his Wednesday Keynote  that vSphere will soon have the ability to set DRS Resource Shares on I/O per VM. Here’s a photo of Herrod discussing the feature last Wednesday.

Other’s have posted on this feature this week as well as in the not to distant past. Check out these posts for more info:
Read the rest of this entry »

VI3 Enterprise features VMotion, DRS, and HA require identical virtual networking settings on all of your ESX hosts. Unfortunately, VirtualCenter does not apply a central configuration policy or inheritance of settings from the cluster. Maybe a future version of VirtualCenter will evolve to include global configuration abilities? Until such a version is created, each ESX server’s virtual networking settings will continue to be configured individually by most administrators. However, there are some time saving, global configuration options available today. This post summarizes two methods provided by the virtualization community for creating PortGroups simultaneously across multiple ESX hosts. Read the rest of this entry »

I ended up with a Toyota Prius as my rental car for the week in San Diego. I’ve never driven a Prius before, and honestly, I’ve never really had an interest in the car until now. Like most, I knew that the Prius uses a Hybrid Synergy Drive (HSD) engine, but I had no idea about all the cool technology built into making the car so efficient. As a matter of fact, the Prius engine technology is in some ways similar to the Distributed Resource Scheduling and Power Management features of VI3 Enterprise.

According to wikipedia’s page about the HSD: Read the rest of this entry »

How do you design resource pools in an ESX Cluster? There are two strategies that are the most popular in my experience. The first strategy creates resource pools based on CPU and Memory shares for host resource conflict management, and the second strategy uses reservations and limits to guarantee physical resources and ensure VM containment. This post will use a 3 ESX host example to explain both strategies. Please feel free to comment on the pros and cons of each or why you think one is better than the other.

In the example scenario three ESX hosts each have 16 GB RAM and 2 dual core 3.0 Ghz CPUs. The three hosts will all be members of the same ESX cluster. 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 »

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!

This post is more of an idea then a report. If you’ve experimented with a design similar to my thoughts below please post a comment and let me know!

Have you tried to configure VMs in a MS cluster across separate ESX hosts? How about clustering a physical server with a VM? VMware’s guide can be found here. Referencing this guide I am specifically talking about “Clustering Virtual Machines Across Physical Hosts (Cluster Across Boxes)” and “Clustering Physical Machines and Virtual Machines (Standby Host)”.

Read the guide and you’ll find there are several prerequisites and restrictions. The most important ones being:

• you must use RDMs in physical mode for shared storage
• dedicate at least 2 physical nics to the VMs
• you can not use multipathing software
• you must use the LSILogic virtual SCSI adapter in your VMs
• you can only use 32 bit VMs. You can not cluster with 64 bit VMs
• iSCSI disks are not supported. NAS disks are not supported.
• you can only use 2 node clustering
• the boot disks for the VMs must be on local storage
• clustered VMs can not participate in an ESX cluster and use VMotion, DRS and HA

So how do we design a clustered VM application that can fully leverage VMotion, DRS, and HA? Read the rest of this entry »