I’ve been using Hyper-V for a couple of years now and there are a few things I’ve seen that just plain work, and if you go a different path you are either taking your chances or wasting your time. Of course, let me point out first that I am not the true authority on Hyper-V, Aidan Finn is, and you will see me reference his blog from time-to-time. You can visit Aidan’s blog here: www.aidanfinn.com (it’s also in my links area to the right). I’m pretty confident, however, that Aidan may agree with me on most of what I’m about to say. Here goes:
- Do not use a dynamic disk with any relational database. This includes, but is not limited to: SQL Server, Oracle, DB2, Microsoft Exchange (yes, it uses a relational database to store your email based on the Jet Engine from Microsoft), and so forth.
- Always provision 4G of RAM minimum for the host operating system.
- Always provide the host operating system with its own NIC. Do not let is share a connection with a VM.
- If you are in a small environment (e.g. 5 or fewer host operating systems), do not join the host to the domain. The benefits do not equal or exceed the hassle. For a few host operating systems, it’s easy enough to log on to them individually to update them or check stuff.
- Always disable time synchronization if your guest VM’s are Windows XP or higher (I cannot speak for older Windows guests or non-Windows guests) and have Internet connectivity. I cannot think of a single reason to have that feature on in Hyper-V – especially if the guest is a member of a Windows domain.
- Unless you have a solid reason to do otherwise, always set the Hyper-V host to properly shutdown the guest operating system if the host is shutdown (the default is to perform a save). This is especially true for guests that have a relational database such as SQL Server, Oracle, Exchange, etc..
- Do not go out of your way to use SCSI virtual disks for your VM’s. The IDE and SCSI virtual disk adapters have almost no differences in performance.
- Unless you have a bleeding need for speed (i.e. you run the New York Stock Exchange), do not go out of your way to use pass-through disks.
- If you are putting your virtual machines on a physical RAID 5 array, your controller should have a minimum of 512MB of RAM on the board – more if all or most of your VM’s are doing heavy writes. From what I can see, 512MB is pretty much the minimum these days, but there are still some used/cheap controllers out there.
- If you are going to virtualize a Terminal Server, stop what you are doing and read the free white papers here: http://www.projectvrc.com/
- If your machine is to be a Hyper-V machine, then that is the only role it should do. Install no other roles or features.
- If your machine is to be a Hyper-V machine, then the backup software agent you are using should be the only software you install on the machine. Furthermore, you should not install the entire backup suite (e.g. BackupExec), just the agent needed. If your only physical machine is a Hyper-V host and you need back up software that isn’t some big suite like BackupExec, check out www.backupassist.com.
- Never leave your host machine logged on. Once you are done administering the machine, log off.
- Guest VM’s on the same machine that need to communicate with one another often should be on the same virtual NIC when possible.
- Aidan’s going to kill me for this one, but: It is OK to install a VM on the same partition as the host operating system as long as the VM is low impact. Meaning it does not do any heavy reads, does not do any heavy writes, does not consume heavy CPU. For example, we use Team Foundation Server 2010 as our source code repository. There are only TWO developers. How much work do you think that TFS guest does? Barely noticeable.
That’s pretty much all I have for now. I may add more to this list as I learn more or read more about Hyper-V. Of course, comments either confirming or un-confirming what I say here are MORE than welcome.