Is your network primarily Microsoft Windows-based? Are you interested in installing a Virtual Server? Have you had performance-related issues when attempting to use Microsoft's Virtual Server?
After answering yes, yes and yes, I combed the Internet for information pertaining to Microsoft Virtual Server so that I could optimize my virtual serving environment. It is my hope that my research, along with any tips you might add, will allow us to create a living Best Practices document for Microsoft virtualization.
(Note to VMware enthusiasts: Though VMware's highly touted server outperforms Microsoft Virtual Server, Microsoft has previously stated it will only provide support for Windows-based virtual servers running on its Virtual Server product. So don't mock my choice too harshly. After all, these tips may also help your VMware environment.)
I first installed the latest Virtual Server 2005 R2, created a Virtual Machine (VM), installed a Virtual OS (guest) on that VM, installed VM additions on the Guest OS and then turned it all on. If you know anything about this process, you'll probably know it did not turn out good. Performance was horrendous. It was like installing Windows Server 2003 on a box that barely meets the minimum specs. Yet it should have been running like a champ, since my host server's basic hardware specs are:
- IBM X-series 366
- CPU: two dual core 2.8GHz Intel Xeon processors
- 4 GB RAM
- 10,000 RPM SCSI hard disk
- 1000 Mbps Ethernet network interface card
This should have been enough to run at least four virtual servers with few performance issues. Yet running just one was pathetically slow. After determining that I had no hardware issues and that I had followed Microsoft's best practices for implementing a virtual server, I decided to search for any performance-related tips and tricks that I could apply to get my system running smoothly. Here is what I found:
Note: Some of the tips I offer may be in conflict with published Best Practices guides, which are out-of-date.
Hardware configuration do's and don'ts
Don't starve your host OS of RAM. You might think giving a VM lots of RAM will help it, but performance won't improve if the VM is robbing RAM from the host. Be sure you allocate less than half of your physical memory to your VMs. I recommend starting with 256 to 512 MB and seeing how well your VMs perform. You can go up or down after that.
The same optimization strategies that apply to disk subsystems for physical servers also apply to virtual servers. You want fast (high-rpm) drives, multiple drives to spread the workload and a RAID solution that fits your needs for performance/protection. Some experts recommend putting your VM on a RAID 0 array, but I do not like the idea of sacrificing protection for performance.
If possible, putting each VM on its own physical hard drive/array, especially one that is separate from the physical host server's system drive and other VM's drives, will increase performance as well. Putting all VM on their own physical drive will also help out. Doing so will reduce disk contention between your host and VM(s).
Use Gigabit network cards. Using Gigabit Ethernet network interface cards can dramatically improve overall performance. Even though the guest OS emulates a 100Mb connection, when you have multiple VMs and the host using the same physical NIC, the performance increase from having a 1 GB NIC will be noticeable. Otherwise, dedicate a separate NIC to each server, or at least one for the host and one for the VMs. Technically, you should go through the process of discovering which systems utilize their NIC the most (most chatty), regardless of whether they are VMs or the physical host, and give them their own NIC. Then group the servers with the lowest utilization (least chatty) onto the same NIC.
CPU to VM ratio. This is tricky. The rule of thumb I came across is you can try running two to four virtual servers per any newer physical CPU core in the host server. But this depends on what your virtual servers will be running. If you're building out virtual servers for low-impact, line-of-business applications, you can push towards a "high VM per core" strategy. But if you are running applications that needs lots of processing and networking horsepower, you should lean towards a "low VM per core" strategy.
