Resource pools can be a very powerful tool that helps an organization achieve very aggressive CPU and Memory utilization.  Properly configured resource pools ensure that cluster resources are intelligently allocated during times of contention.  Critical virtual machines can be given preferential access to compute in the form of shares and/or reservations, while less critical virtual machines, with fewer shares, will receive fewer CPU cycles and less access to memory.  Sadly, they are often improperly configured and can have quite the opposite effect.

Resource pools should not be used to simply organize your VMs.  I have seen large vSphere implementations where VMs are organized into Pools named after their application, performance, or DR tiers, without any thought to the effect on share values.  This can create unbalanced resource pools and have unintended consequences.  Use folders to organize your VMs and delegate permissions instead.

The most common example of this misconfiguration I see is the old “High, Normal and Low” design, where three sibling pools are created that are given default High, Normal and Low shares with no reservations and named accordingly.  Craig Risinger does an excellent job of explaining and illustrating the issue in his posting The Resource Pool Priority-Pie Paradox.  Many a well-meaning engineer has implemented this design under the mistaken assumption that this will ensure that VMs in the High pool will always receive higher shares to resources than the Normal and Low.  Not so fast!  In our example, sibling resource pools are given 8,000, 4,000 and 2,000 CPU shares or 57%, 29% and 14% of total cluster CPU respectively to split among their member VMs.  All works as expected as long as there is an equal number of VMs in each pool (Table A), but when the cluster becomes unbalanced (Table B), our Low Priority VMs wind up with 2.5 times the access to CPU.

Note: This example illustrates our problem using CPU shares and assumes a single vCPU/VM for simplicity.  The issue is true of memory shares as well, with a ratio of 4:2:1.

Table A – Balanced Resource Pool, Default Shares

Table B – Unbalanced Resource Pool, Default Shares

Chris Wahl explains how to maintain cluster balance in his article Understanding Resource Pools in VMware vSphere  using Custom Share Values, and he even provides a sample PowerCLI script to help automate the process.  This is not a one-time process.  vSphere Admins need to constantly monitor their clusters and adjust these values as VMs are moved in and out of the pools.  In order to make our High, Normal and Low pools work as expected we need to assign custom CPU shares as detailed in Table C.

Table C – Unbalanced Resource Pool, Custom Shares

Now that you have your resource pools configured with appropriate custom share values, make sure you don’t make the other most common mistake: placing VMs in the Root resource pool.  Eric Sloof, in his article Don’t add resource pools for fun, they’re dangerous, shows how a few casually misplaced VMs placed in the root resource pool (these VMs become siblings of large resource pools) can provide them with an inordinate amount of % shares.

Please note that VMware resource management is not limited to shares.  An effective resource management strategy could include reservations, along with network and storage I/O control, though each is worthy of more attention than is feasible in a blog posting.  Thank you for listening to this public service announcement; I hope it helps you when architecting your own resource pool designs.

There are five things to think about before deciding to go virtual or not:

1. How many servers do you have?  If you have one server and it is running your entire business, you are not a good candidate for virtualization because it will cost much more than just replacing that server and having good backups.  There is no magic number of servers that will put you in the “should virtualize” category, but if you have three or more servers, going virtual is something to consider.
2. My server is doing everything!  It is a best practice to keep a server limited to one function or application.  I very often see these small companies running Active Directory, SQL server, and other applications on one system. Virtualization will allow you to have more VMs, each with, at the most, two functions without the added expense of additional hardware. This makes disaster recovery and security much easier when the roles are separated.
3. All my eggs are in one basket.  Most of these environments do not have, and cannot afford, any redundancy. They have a few physical servers running their business critical applications and a switch and (hopefully) firewall. Upgrading to a virtual environment is a great time to build in the redundancy you need to lose any individual piece of hardware and not lose any business critical services.  No need for the “48 hour downtime is acceptable” mentality.
4. That is not supported. The days where applications are not supported in a virtual environment are gone.  The vast majority of software in the commercial and enterprise market supports virtualization, and some are now starting to offer a virtual only delivery model. Tier one applications such as Microsoft SQL Server, Oracle, Exchange, and SAP all support use in a VMware, Xen, or Hyper-V environment.
5. I do not know how to run or maintain a virtual infrastructure. Well, that may actually be true.  That is still not a show stopper in all cases. The administration skills to run a VMware environment are becoming like a high school degree; it’s one of the base skills that employers are looking for. The sooner you jump on the bandwagon, the sooner you will avoid getting run over by the virtual bus. We have some clients who decided that the benefits of virtualization were too strong to resist and went virtual knowing they did not have the skills yet. GreenPages supported them for 6 months to a year with our Managed Services team until they were confident enough to take over.

Done correctly, switching your aging physical systems to virtual will give you the ability to have redundancy at the physical server, switching, and storage level. VMware has a very good entry level bundle that is a great value (even with the licensing changes introduced in vSphere 5.0) and features that SMB customers need, such as High Availability and vMotion. These features allow you to lose a physical server and still keep all of your applications running. You can also move all of your virtual machines to the other host and then apply patches to the physical server. You also gain the ability to spin up a new virtual machine for testing or a new application without having to go and ask for money for a physical server.

Virtualization is not right for every business in every situation. But for most of the SMB clients I work with, it is the right choice. They tell me three to six months after we have taken them virtual that they don’t know how they ran a business on physical servers and regret not making the move sooner!

I was part of a panel at a recent GreenPages event and a question was asked by the audience regarding best practices for thin provisioning in a virtual environment.  More specifically, the question was, what is the best practice regarding thin on thin storage provisioning?  

First, let me provide a bit of background on the question.  Thin Provisioning is essentially a process for “faking out” an operating system or other platform in such a way that you make it believe it has more storage available than what truly physically exists.  Why would I want to do this, you may ask?  There are several reasons why this could make sense, such as that pesky application vendor who demands that you provision 200GB of disk space for a database that you know will only truly use maybe 5-10GB.  It also allows for dynamic growth as one can add the true physical capacity to meet the ‘advertised’ capacity if/when necessary without any alterations needed within the OS or application.

So, “how” do I use this technology?  Herein lies the challenge as there are really multiple ways to accomplish this.  One method is within the virtual infrastructure itself, as I can create a virtual disk with a size of 100GB and choose to “thin provision” it.  This means that the virtual disk actually starts out with a much smaller size than 100GB, and will dynamically grow as new data is created within the vdisk.  The full 100GB is advertised to the OS, so it believes there is 100GB of capacity available even though in reality there is probably less than that.  Hopefully you can see the challenge here from a management aspect.  Take a single VMFS volume with a physical size of 500GB and, let’s say, I create 10 VMs on that VMFS volume, each with a single 100GB thin provisioned vdisk.  I’m advertising 1TB of capacity collectively to the VMs, but I really only have 500GB there.  What happens when the total used capacity of the 10 VMs reaches 500.0001 GB??  Let’s just say that wouldn’t be a good day for the VMware administrator.  So I need a way to monitor the actual used capacity and be alerted far enough in advance of the 500.0001 problem so that I can add additional physical capacity or move VMDKs around to avoid running out of space.

Another method of thin provisioning involves the shared storage array itself.  In this situation, we are provisioning a LUN or Datastore and advertising that it has a size of 1TB when in reality there is only 500GB of actual capacity on the array.  Same situation as above, but in this case I will typically use true ‘thick’ provisioning on the actual virtual disks themselves, meaning that I could only create 5 VMs with each having a 100GB vdisk on this thin provisioned datastore.  I can run into a similar issue with the monitoring here as I need to be notified in advance so I can move things around or add physical capacity prior to attempting to add that 6^th VM to the datastore.

This brings us to the “thin on thin” question posed to the panel.  This concept basically means that I’m using both of the above mentioned methods simultaneously.  The good news is I can advertise a ton of capacity although I may be truly using only a small fraction of that space.  The bad side of this is I REALLY have to continuously monitor and manage this environment because the edge of that storage capacity cliff gets pretty blurry when both methods are used.  It has always been the recommendation of GreenPages that our customers choose to use one method or the other, but not both, as to minimize the risk of driving the car off the cliff while thinking you have a nice straight paved road in front of you.  As for which method is the best to use, well the consultant in me always says “it depends” because everyone’s business and technical requirements and skillsets are different so I can’t really say there is a single correct answer in this regard.  I’m interested in hearing your own experiences and thoughts around this topic so please feel free to comment!

Many people agree that both XenServer and Hyper-V are lacking some of the features that VMware has.  But the main argument I hear is that Hyper-V, and even XenServer, is less expensive than VMware. That is the main issue I want to discuss in this post.

The short answer is… it depends.  Yes VMware is more expensive than Hyper-V, but it does a lot more also.  All of the price comparisons I have looked at are for 5 hosts, and these use Enterprise Plus as the price level which is the highest possible price.  We have clients at both ends of the spectrum, some with less than 3 hosts using Essentials Plus and others with more than 5 hosts using Enterprise or Enterprise Plus.  Let’s take both cases and talk about them.

For small customers, the entry level Essentials Plus from VMware provides licenses for up to 3 hosts and vCenter for ~$3000.00.  This gives users the ability to do vMotion and HA (High Availability) which are key to maintaining an up-to-date and fail-over capable system.  Yes you will still need to buy the Microsoft or other OS licenses on top of this, but you need them to run your applications anyway.

An equivalent Hyper-V environment with 3 hosts will need a few add on pieces to manage everything to match what vCenter does.  The management pieces are all part of System Center Management suite.  You will need System Center Operations Manager, Configuration Manager, Virtual Machine Manager, and Data Protection.  All of those pieces are ~$2031.00 plus you need per user licenses for Systems Center Management Suite and Data Protection.  Not to mention the 4-5 Windows OSes and training to run all those pieces.

For larger environments, there is no doubt that Hyper-V is less expensive.   I think that you get what you pay for.  In larger and more complex environments, features such as Storage vMotion, Storage I/O Control, Network I/O Control, Memory compression, Transparent Page Sharing and VAAI (vStorage API’s for Array Integration) and fine user access controls make VMware the hypervisor of choice.  There is a reason that the vast majority of the Fortune 1000 run VMware and it all has to do with enterprise functionality and stability.

All in all, VMware for smaller clients is about the same cost and easier to manage than Hyper-V.  Large customers depend on the richer features that are part of VMware Enterprise and Enterprise Plus.  There is also the large 3^rd party vendors that already have integrated with VMware and may or may not have integration into Hyper-V.  I want to run my production workloads on the best platform possible.  For many of our clients that is VMware.  But for others it may be Hyper-V or XenServer.  That is one of the awesome things about working for GreenPages.   We support our clients, not a software or hardware vendor. What are you’re thoughts on this?

First off, I love what VMware has done with vSphere 5.  Many great improvements and it is faster and better than 4.1.  Auto Deploy will help larger customers deploy new physical hosts quickly and easily and will provide much more efficient patching of ESXi hosts.  There are many improvements to storage including Storage DRS (Distributed Resource Scheduler), Storage I/O control for NFS, and support for larger vmdk files.  I also think that the Network I/O control for individual VMs will be useful in many environments.

VMware is still selling vSphere 4.1 for a few months so new customers can choose to stay with the tried and tested 4.1 or go right to vSphere 5.  The upgrade path from 4.1 to vSphere 5 is not hard and can easily be done with VMware Update Manager so that is not a major concern.  Most of the clients I talk to start with 4.1 since it has been well tested, and they do not want any issues on the start of their virtualization journey–especially if they are new to virtualization and do not want to deal with any odd issues that may come up because vSphere 5 is a new version.

Many of our more seasoned clients, who have been virtualized longer, are considering going to the new version.  The general consensus, however, is to wait until it has been tested by other users, then upgrade to it after service pack one has been released.  The exceptions are customers who need some feature that is in the new software.  I have talked to a few customers who are going to vSphere 5 soon to take advantage of Network I/O at the VM level or to support very large files (larger than 2 TB).

The only thing that might give someone pause about immediately upgrading to 5.0 is HA (High Availability).  The original HA was based on code that VMware purchased, and they decided to totally rewrite this piece of critical functionality.  This is such an important feature that some are preferring to wait and see how it behaves in the wild before trusting it in their critical infrastructure.  I do think that everyone (myself included) is being over cautious.  vSphere 5 has been out for weeks, and I have not heard of any major issues.  The main reason for the caution is that there are many more important workloads running on ESX hosts, thus, any issue with the hypervisor can cause widespread mayhem if something goes wrong.

For the cautious people out there, a good way to ease into vSphere 5 would be to upgrade Tier 2 systems first along with Virtual Center to get a comfort level with the new features and stability. After that, upgrade your Tier 1 hosts once the comfort level has been established.

www.youtube.com/watch?v=qyOFYU5KDzY