The most important part of my installations!!!

Ok I have done some nice VMware projects recently with both blade systems and rack servers, some have been SRM installs across sites and some have been Metro Clusters (NetApp) and some have been bog standard installs with a handfull of hosts at each site.

I have done the , conceptual, low level and then high level design elements before creating an installation guide for the consultants installing the systems (when it has not been myself) and also created a validation plan for the install after to make sure it has filled the fundamental requirements identified in the design phase.

However one of the most important elements of the design recently has been the assistance of migrating workloads.  All of my recent customer have been migrating from an ageing VMware platform to the new system I have been installing.

During the design phase and the gathering of the fundamental requirements one of the key requirements is to improve performance.  Either the performance of the aging hardware is poor or a handful of VMs are performing bad.

Often customers will chose to do the migration themselves.  I have seen customer use a number of ways to do this from block level storage copy, to un mounting of LUNs from the live system and mounting them to the new system, Copying VM folders, V2V with VMware converter or other third party tools. I have even seen some customers use the old sVmotion script for 3.5 migrations.

However the migration is performed, the outcome from the customer is always the same, initially the system will perform OK but after more VM's are created the performance decreases.  The system is nowhere near the consolidation ratio that was quoted in my capacity planning and the customer becomes unhappy.

So my company will receive a call and we will go and investigate.  What will we find!!!!

1. The migrated workload is badly sized - VM's with 4 CPU's and 8GB of RAM 
2. The migrated workload VM's have version 4 or version 7 hardware 
3. The migrated workload has out of date VM tools
4. The migrated workload is all sitting on the same datastore
5. the migrated workload VMs have reservations and limits configured on the VMs

All of the above my seem simple but they are always the reasons for bad performing V2V Virtual machines.  Often physical migrations have additional problems with post and pre checks, driver removal etc.  But the physical migrations are becoming more and more rare these days.

So one of the most important parts of a vSphere migration in my view is sizing the VMs correctly, often customers dont appreciate that giving VMs more vCPU can have a negative affect on its performance.  I may cover the technical bits as to why this is the case in a later blog.