If you would like to read other parts to this article series please read:
- Resource Allocation in Hyper-V (Part 1)
- Resource Allocation in Hyper-V (Part 2)
- Resource Allocation in Hyper-V (Part 3)
So far in this series, I have focused primarily on talking about the complexities of determining the amount of CPU resources that are required by a virtual machine, and some methods that you can use to figure out exactly how much CPU time a virtual machine is using. In this article, I want to conclude the discussion by talking about the ways in which virtual machines use memory and disk resources.
Memory Allocation
One of the things that I find most interesting about memory allocation for Hyper-V is that Microsoft does not seem to make any specific recommendations as to the required amount of memory. If you check the hardware requirements section of the Hyper-V website, you will see that Microsoft really only lists two different requirements. First, the host operating system must be running a 64-bit version of Windows Server 2008. Granted, this is not exactly a hardware requirement, but it does imply the need for a 64-bit processor. The other requirement is that the server must support hardware assisted virtualization. Both Intel and AMD solutions are supported.
These are the only two hardware requirements that are listed beyond those required for running the host operating system. My own personal observation is that when you launch a virtual machine, it seems to consume a trivial amount of memory on the host operating system, but not enough to really worry about, as long as the host operating system is not deprived of resources. Of course this is in addition to the memory that you allocate to the virtual machine.
I have spent a lot of time working with Hyper-V, and I have experimented with a lot of different memory configurations. My own recommendation for allocating memory to virtual machines is to start out by figuring out how many virtual machines you want to run simultaneously. After doing so, plan the system requirements for those virtual machines just as you would if they were physical machines. Finally, add all of the required memory together, and then add 2 GB for the host operating system. Some people like to allocate a bit more memory to the host operating system, but I have found that this really is not necessary as long as the host operating system is not hosting any applications other than Hyper-V.
I recently virtualized some of my production servers using a physical machine that had 8 GB of RAM. I subtracted 2 GB off the top for the host operating system, which left me with 6 GB to play with. I split the remaining memory evenly into three 2 GB chunks that I used for three separate virtual machines.
One important thing to keep in mind when you are allocating memory to virtual machines is that you can only allocate memory to virtual machines, not to the host operating system. The host operating system uses what is left over after all of your virtual machines have started. It is also important to remember that simply allocating memory to a virtual machine does not cause the memory to be consumed. The memory is only consumed once the virtual machine has been started. Until you start a virtual machine, the memory that has been allocated to that virtual machine is available to the host operating system.
The reason why I wanted to point this out is to show that it is important not to shortchange the host operating system. After all, you cannot reserve memory for the host operating system, and it gets whatever memory is left over after the virtual machines start, so it is easy to accidentally leave the host operating system with insufficient memory.
Disk Resource Allocation
Every virtual machine that you create is assigned one or more virtual hard drives. A virtual hard drive is simply a large file that acts as a repository for all of the files that are associated with the virtual machine. Like any file, you can tell Windows to put a virtual hard drive just about anywhere so long as there is sufficient disk space. Of course this leaves the question of where you should put your virtual hard drive files so that the server will perform optimally.
I tend to think that the answer to this question depends on how much money you want to spend. From a performance standpoint, the ideal solution would be to use an independent storage array for each virtual hard drive. Another optimal solution would be to store your virtual hard drives on a SAN.
The biggest problems with these two solutions are cost. The whole point of using virtualization is usually to help reduce hardware costs. You are not exactly reducing the costs if you end up having to purchase a bunch of direct attached storage arrays, or if you end up having to build a Storage Area Network. On the other hand, if you happen to already have a SAN in place then you should definitely use it.
So, what if you do not have a huge budget and you do not have a SAN at your disposal? Hyper-V does not really limit you in terms of where you can put the virtual hard drives. From a software perspective, it makes no difference to Hyper-V if you put the virtual hard drive files on the server’s system volume or if you put each virtual hard drive on a dedicated raid array. Of course if you did put all of your virtual hard drives onto the system volume then the server’s performance is going to suffer tremendously.
I have several servers in my own organization that are acting as host servers for virtual machines. I use two different techniques for placing virtual hard drives, depending upon how heavily I anticipate disk resources being used.
If the virtual machines being hosted on a server are not running disk intensive applications, then I usually end up just creating one large raid 10 array and using it to store all of the virtual hard drives.
If I know that a virtual server is going to be more disk intensive then I start with the same physical hardware that I would if I were creating a large raid 10 array. Rather than creating one large array I allocate the individual disks into several smaller arrays. By doing so I am able to ensure that no one virtual hard drive consumes all the available disk throughput. This technique also helps me to avoid the costs associated with purchasing individual dedicated arrays for each virtual machine.
I have found both of these techniques work really well for me. The biggest trick is just anticipating what type of load each individual virtual machine is going to be placing on the disk subsystem.
Conclusion
As you can see, it is far easier to plan disk and memory allocation than it is to determine CPU resource consumption for a virtual machine. Even so, it is important to remember that both disk and memory are critical resources for virtual machines, so you must take the planning process seriously.
If you would like to read other parts to this article series please read:
