If you would like to read the next part in this article series please go to Determining Guest OS Placement (Part 2).
As you consolidate physical servers in your organization, one of the decisions that you are going to have to make is where to place each virtual server. Deciding which physical server should host which virtual servers is something of an art form. In this article, I will discuss some criteria that you can use to assist you in virtual server placement.
Step one: Determine Each Host’s Capabilities
The first thing that I would recommend doing is taking an inventory of your host servers, so that you can figure out each host’s capabilities. Some important criteria to include in your inventory are the number of CPU cores included in the server, the amount of memory installed in the server, and the speed and capacity of the disk subsystem.
The reason why this is important is because each hosts server only has a limited amount of resources that can be shared between the virtual machines that are residing on it. Knowing what each physical server is actually capable of is the only proof positive way of mapping the virtual server’s needs to the physical server’s resources in an effective manner.
One aspect of the inventory process I have yet to hear anyone mention is that I would recommend taking the time to not only document what hardware is currently present on the server, but also what upgrades could be performed on the server if it were to become necessary. I believe that this is important because one of the main reasons why companies choose to virtualize their servers is so that they can make better use of their hardware, and use fewer physical servers.
With that in mind, imagine what would happen if a company were to install some virtual servers onto a physical server whose hardware capabilities have not been maxed out. If the company eventually needed to create more virtual servers, they may end up investing in an additional physical server to host the new virtual machine, because they believe that their existing hardware is already performing at its maximum potential. In most cases though, it would have been a whole lot less expensive for the company to simply upgrade their existing hardware than to purchase an additional server. Even if the hardware costs of doing so were the same, there are software licensing costs that must be considered.
Step two: Determine Each Virtual Server’s Needs
The next step involved in the virtual server placement process is to determine each virtual machines resource requirements. Generally speaking, I recommend treating a virtual machine in the same way that you would treat a physical machine. Suppose for instance that you were going to be deploying an application server, and application’s publisher stated that they recommend a dual core processor, 2 GB of RAM, and 100 gigs of hard disk space. The application publisher probably assumes that the application is going to be run on a physical server. Even so, it has been my experience that the various hardware requirements apply equally even if the application is going to be run in a virtual machine.
In my example above, I am not saying that as long as the host server has a dual core processor, 2 GB of RAM, and 100 GB of hard disk space that you will be able to run the application in a virtual machine. What I am saying is that if you can allocate those particular resources to a virtual machine in a way that prevents those resources from being consumed by other virtual machines running on the host server, then the application will probably run fine.
Of course there are exceptions to every rule. One thing that you need to be aware of is that when application publisher’s site hardware requirement, they do not take resource contention into account. Any time that you are hosting multiple virtual machines, all of those virtual machines compete with each other, and with the host operating system for a limited pool of server resources.
You can partially solve the resource contention problem by dedicating certain resources to the individual virtual machine. For example, memory is one resource that can be allocated in such a way as to prevent it from being used by other virtual machines hosted on the server.
CPU resources can also be allocated, but only to a degree. You can assign processor affinity settings for virtual machines. In essence, this means configuring virtual machines so that they are only allowed to use specific CPU cores. Doing so will not prevent the host operating system from using those cores, but it will prevent a CPU intensive virtual server from running away with all of the physical servers CPU resources. You can also treat the machine’s entire bank of CPU resources as a pool, and set some threshold values that limit the overall amount of CPU resources that a virtual server is allowed to use.
If you do decide to use processor affinity as a way of managing CPU resources for virtual machines, then you must make sure to leave at least one or two CPU cores unallocated. Doing so gives the host operating system some CPU resources that they can use without depriving the virtual servers of CPU resources. That is not to say that the host operating system will not use some of the CPU cores that you dedicated to the guest operating systems, but it does make it less likely. Generally speaking, if the host operating system is running Hyper-V and nothing else, then its CPU consumption will be minimal. Obviously some CPU resources are required for running the host copy of Windows, and there is a degree of CPU resources required for supporting Hyper-V’s overhead, I have never run into problems so long as I leave some CPU resources dedicated to the host operating system.
One of the trickier types of resources to allocate our disk resources. Most common practice for allocating disk resources is typically to create separate volumes for each virtual machine, and to then place the virtual hard drives onto the volume that you have set aside for that particular virtual machine. Sometimes a server will have disk requirements that require a more elaborate disk allocation method. For example, an Exchange mailbox server requires multiple virtual hard drives, and those virtual hard drives need to be positioned in a way that ensures performance and fault tolerance. For the purposes of this article let’s assume that each virtual server only needs one virtual hard drive, and that each of those virtual hard drives is located on a separate volume.
Even with this type of configuration, resource contention is still an issue. The reason is that although Hyper-V is able to communicate directly with the hardware for most types of hardware calls, any calls to the disk subsystem must pass through the host operating system. This means that it is easy for the server to get bogged down if you’re running a lot of disk intensive virtual servers on the same physical hardware, even if you are using separate volumes for each virtual hard drive (although that does help).
Conclusion
In this article, I have talked about some ways of determining what a physical server’s capable of, and some ways of allocating specific resources to virtual servers. In the next part of this article series, I will conclude the discussion by talking about some ways of mapping hardware resources to virtual server requirements, and about what to do when business requirements and virtual server mappings do not seem to match up.
If you would like to read the next part in this article series please go to Determining Guest OS Placement (Part 2).
