Day 10 - Optimizing MS Operations Manager Performance in Virtualization Scenarios

I occasionally get the question "Can I deploy and run MOM on a virtual server"? The answer is an emphatic "yes". As with purely physical server environments, ensuring systems are optimized for best performance is a key to a successful deployment.   So on this, the 10th day of Christmas, here are some thoughts on appropriate user and effective tuning in situations involving virtualization. While many of these tips are applicable for any virtualization scenario (including MS Virtual Server), these recommendations are directed primarily to a VMWare ESX environment, a platform which eliminates the Windows Host OS and thus offers a performance advantage over the Microsoft offering and it's relative, VMWare Server. See Microsoft's official support statement for non-MS virtualization software HERE.   Note: We're also talking about PRODUCTION scenarios, as the benefits of virtualization for test and development are well known to all. These suggestions really should be equally applicable to MOM 2005 and Operations Manager 2007 Management Server roles (although we'll see what official MS guidance is on the latter when it releases in Q1 2007).   Which MOM roles should I run in a virtual machine?   I think the most obvious win here is for the Management Server role, which provides a quick road to scaling out to support monitoring greater numbers of servers, supporting more console connections, as well as for support of geographically distributed servers and administrative staff.   While there are also use cases where virtualizing SQL Server can be justified (generally when SAN storage, database replication and/or disaster recovery are involved), I would suggest you stick to a physical server for the MOM Database Role unless your specific circumstances dictate otherwise. Tuning Recommendations    Optimize the pagefile, or even remove the pagefile from the VM altogether if it is running 2003 SP1 to minimize disk I/O. See HERE for details on Windows pagefile optimization. Note: VMWare ESX implements its own paging mechanism independently of that of the guest machines which allows assigning more memory to each virtual machine than they might otherwise be possible (although the guest OS best knows which pages are unneeded). Ensure that there is no logging of the VM activity within ESX.   Next, I Disable any logging in the VM such as IIS website logs, SMTP and others. Note that this must be turned on in case of troubleshooting. Minimize the number of VM disks used. No More than 2 virtual disks per VM.   First is for the OS, Applications and Data the second one is for any "Sequential" disk access for such things as transaction logs.  If there aren't any transaction logs, use only one virtual disk.   This is ultimately more efficient for the host and the disk subsystem.  "Snapshot" or Redo Logs should be disabled for the VM's. For all VM's on a host, the OS versions for the VM's should match the stated OS version in the configuration file. Format the virtual disk BEFORE installing the Operating System. This deserves some additional explanation. Most SANS use 64K blocks and the virtual disks that are used to install a VM on should be mounted under a separate VM and be formatted with the appropriate "Allocation Unit" size that also matches the HBA/SCSI Stripe depth size.   Transactional systems are the only systems that will differ in the required Allocation Unit size.  The reason for mounting under a separate system is that the OS still formats the OS partition to an allocation unit size of 4K which is extremely inefficient and thus the OS install process should never be used to format a disk that is being installed onto. Good Additional Reading:   Memory Resource Management in VMWare ESX Server http://www.stanford.edu/class/cs240/readings/waldspurger.pdf