We have a customer who has a number of physical machines hosted with us. They were deployed before we had a virtualised environment. The specs were defined by the customer based on what they thought they’d need for a new service.
They asked us to look at replacing (not converting) their Windows Server 2003 web servers with Windows Server 2008/2008 R2 virtual web servers. They also asked if the back end servers could be looked at as virtualisation candidates. Operations Manager to the rescue!
OpsMgr is constantly gathering performance data. It keeps over a year of it in a reporting database. I ran some reports. CPU and memory were the two important ones.
The web servers were simple enough. Their CPU average utilisation proved to be low with the occasional spike. The standard deviation was very small and the spikes were very infrequent. As Hyper-V VM’s on a cluster, this is no problem. If a spike is detected by OpsMgr, the VMM Pro Tips integration will move the VM using zero-downtime Live Migration to an idle host and allow the VM the CPU resources it needs. As it turns out, they use exactly 50% of their RAM. The nice thing here is that we have empirical data to justify a reduction of the ram by 25%. If it needs to go up then it’s just a couple of minutes of mouse clicks to do that.
The back end servers were another story. The average CPU was low, but not quite as low. I also could see much more frequent CPU spikes. The standard deviation was much greater. To be honest, this was what the customer and I both expected. These machines are not virtualisation candidates.
So instead of doing a blind P2V, or sticking a wet finger in the wind, we went through a scientific decision making process, courtesy of the reporting database in Operations Manager 2007 R2. There will be no worrying about any future deployment, we should know what the end result will be.