A critical skill, too often handled haphazardly on-the-fly, is the creation and sizing of virtual machines.  The efficiency of modern hypervisors often covers for configurations that could have used a little more forethought, and many SMBs won’t tax their systems enough for it to be of great concern — at least not until the bug of VM sprawl that eventually infects most installations makes it a concern.  To maximize your potential for virtual machine density, taking great care in the creation of guest configurations can provide substantial payback.

Pre-configuration Tools in System Center Virtual Machine

If you are creating virtual machines on a regular basis, System Center Virtual Machine Manager has a few tools to aid the process. These are all accessible on the “Library” tab in the main interface in the right-hand pane.

Templates

You cannot create a template from scratch. Clicking “New template” allows you to build a template from an existing virtual machine or from a previously created template. The process syspreps the item and places it within library storage. Note that this action is taken on the actual virtual machine, so if you want to keep the one that you’re creating the template from, clone it first (SCVMM will warn you about this). From there, you have the option to “Deploy” the template. Doing so creates another clone of the base template, but this time it is placed onto the host of your choosing as a live virtual machine.

The best usage of templates is in a one-to-many deployment environment in which you will reuse a pre-installed copy of an operating system and vital software as a “Gold Master” image

Hardware Profiles

Hardware profiles establish all the settings on the “Hardware Configuration” tab of a virtual machine but do not create any VHDs.

Hardware profiles are useful in any situation in which you will reuse the same basic hardware configuration. It is not tied to any particular operating system. You may simply want to create a base hardware profile that checks the “Enable Num Lock” box for you.

Guest OS Profiles

Guest OS Profiles are for deployment of Windows virtual machines for which you would like a little extra control over at creation time. You can preset the computer name, local administrator password, product key, time zone, operating system, domain/workgroup, and even specify a sysprep.inf or unattend.xml file for further customizations. Additionally, you can specify commands to be run after the virtual machine’s first boot. The only time guest OS profiles are used is during the creation and deployment of templates.

Guidelines and Explanations for First Creation of Virtual Machines

If you haven’t already got templates and profiles ready, or if you’re setting up a one-off configuration, or if you’ve only got Hyper-V Manager at your disposal, it is worth your time to carefully plan each new build with an eye toward balancing the performance of the individual virtual machine against the need to ensure the resources of your hosts won’t be prematurely overtaxed as your infrastructure grows.

All of Your Resources Are Shared or Divided

This should be the never-forgotten-thing in modern virtualization: none of the resources on a host belong to any one virtual machine. There are ways to manage and shape resource utilization on a host so that critical VMs have better and more access to hardware, but they still share resources with other VMs and contention is always a possibility. This makes benchmarking a far less enlightening tool than it is in a non-virtualized environment, although it doesn’t make it entirely useless. It should always be remembered that if a particular VM starts acting sluggishly, it may be because of a different VM entirely, or because of the cumulative effects of all the other VMs on a host. Achieving maximal VM density is as much art as science.

Resource	Allocation Type
CPU Cycles	Shared
Memory	Divided
Disk I/O	Shared
Disk space	Divided
Network	Shared

CPU

Most virtual machines won’t need more than 2 CPUs, and unless you have a definite need for a single CPU VM, always use at least 2 virtual CPUs. That secondary execution thread makes a very noticeable difference in performance. If you are building a server that will run an application that would benefit from having more available CPUs for concurrent execution, such as SQL, e-mail, or web servers, feel free to add them. Hyper-V does a good job balancing CPU resources, so unless you have few cores in your host or many moderate- to high-load VMs, you probably will not experience meaningful levels of CPU contention. If maximizing density is your goal, try to stay at 2 virtual CPUs per VM. Hyper-V R2 with Service Pack 1 supports 8 virtual processors per logical processor unless all of the VMs are Windows 7, in which case it supports 12 virtual per logical.

If you’re using SCVMM, you have the option to select a CPU type. This is used solely for SCVMM’s intelligent placement metrics. It has absolutely no bearing on which CPU capabilities are exposed to the VM. If you view Device Manager from a guest, it will show exactly the CPUs that are in the physical host (if it can identify them). When a VM is migrated using SCVMM, it will calculate CPU load history as though it were running on the CPU set here to determine expected CPU load. Hyper-V Manager does not have this option. Unless you will be relying on SCVMM’s intelligent placement, you can ignore it.

Memory

Memory is easily the most precious resource in a virtualized environment. Unlike most other resources, it is not shared between VMs; it is divided between VMs.

Client OS guests running Windows from Vista onward and server Windows guests from 2003 onward can benefit from dynamic memory. Other operating systems will only ever use the amount set as startup. Dynamic memory is a large topic and will be covered in more detail in the next posting. For quick guidance, ensure the guest in question is running a supported OS and has the latest guest integration services installed first. Set the startup RAM to a number that is below what you think the VM will need. Hyper-V is aggressive about reducing RAM in guests using dynamic memory management. Set the maximum to the same place you would set it if you weren’t using dynamic memory at all.  The “Buffer” setting tells Hyper-V what percentage of the base to always have set aside to add to the VM. Make this lower for non-essential VMs.

Because memory cannot be shared, this is the place where you can make or break your density requirements. Hyper-V will not allow you to overcommit a single host, so the sum of allocated static RAM, startup RAM plus memory buffer reserve, and overhead cannot exceed the total physical RAM in the host. While there is no exact science to assigning RAM, it is safe to say that it is more common to assign more RAM than is necessary than less. Exchange and SQL Servers generally require high quantities of RAM, but most other clients and servers can run adequately with 1-2GB or less. If you’re not sure, start a VM higher (around 4 GB) and use Performance Monitor to track it for two weeks. Typically, the most tell-tale metric is “Memory: Pages/sec”. If this counter comes back as near-zero, then the VM can probably stand to have its memory reduced. If it’s consistently over 20, then the VM probably does not have enough memory. Remember that paging is a burden on disk I/O, which is also a shared resource, so don’t reduce your memory allocation so much that you cause other bottlenecks. Memory tuning is an ongoing process, especially as you try to get more density onto your hosts, but when in doubt, start a little lower and increase as necessary.

Hard Drives

There are several variables to consider when making hard drives, and a haphazardly built VM deployment can become a nightmare if not monitored.

IDE or SCSI?

Performance between the two types is identical in most cases. Remember that these are virtual; both types are going to live on the exact same underlying equipment. However, the synthetic IDE controller operates with the same limitations as a real one: only a single IDE device per controller can be active at a time and they cannot be hot-added or removed. Also, you can only use the two IDE controllers Hyper-V provides, so you are limited to a maximum of 4 IDE devices per VM. Unlike SCSI, IDE has no need of specialized drivers for guests to use it, so it has the greatest compatibility with guests. Currently, Hyper-V will not attempt to boot a VHD on its SCSI chain, so the first drive in a system must be IDE.

	Virtual IDE	Virtual SCSI
Driver type	Emulated	Synthetic
High performance
Loads before boot?
Can hold page file
Maximum per VM	4	256

 

Fixed, Dynamic, or Pass-through?

Both fixed and dynamic times are VHD files managed by the hypervisor. The fixed type VHD will be the exact size you set (or expand to). A dynamic type will start out with very little space allocated to the VHD file, but the guest operating system believes the drive to be the size you set. As the guest allocates more space, Hyper-V dynamically grows the size of the VHD to accommodate. This is known in other technologies as “thin-provisioning”. The final type of drive you can create is a pass-through disk. This is not a VHD at all. It maps the guest’s drive directly to a LUN on the host.

Pass-through is the fastest of the drive types as it occurs no overhead from the hypervisor whatsoever. However, they cannot be snapshotted by Hyper-V, they cannot be moved or copied to another location the way a VHD can, and if they are attached to a clustered VM, there is a pause during LiveMigration while the drive is dismounted, ownership is transferred from the source host to the target, and then remounted. Benchmarks vary, but pass-through disks are typically only a fraction of a millisecond faster than fixed VHDs; they are generally not worth it.

For a general purpose application, dynamic drives are usually sufficient. They are slower than fixed, but not by much except when the drive is expanding. Where they can struggle is in high I/O situations like SQL Server, even if the drive has already been sufficiently expanded. Because Hyper-V has to track all the VHD blocks as they have expanded (or been compacted), it is much like having to access a secondary file allocation table. Tracking the dynamic changes also incurs a relatively minimal amount of CPU and memory. In a high I/O setting, these impacts can actually become significant.

Hard Drive Planning

In consideration of all of the above, the following is recommended:

• For general purpose virtualized server and client operating systems, just use the default dynamic VHD. If the default of 40GB won’t be enough, set the maximum to a reasonable number. You can increase it later if necessary (you must down the VM to do so).
• For higher-I/O VMs or those that will need lots of space that you’d like to keep segregated from the primary VHD, leave the first VHD at defaults (40GB dynamic IDE) and install only the operating system on it. Add a SCSI controller. For high-I/O VMs (i.e. SQL and Exchange), use fixed SCSI disks to hold the data. For lighter applications, use dynamic disks.

Notes on virtual SCSI in Hyper-V: non-bootable; up to 4 SCSI controllers with up to 64 drivers per controller; hot-add/remove.

A final consideration for fixed drives: If you will be using backup software that operates at the parent partition level and not from within the VM, be aware that it backs up VHD files as they sit. So, if you built your Exchange Server with 250GB fixed drives even though they’ll only have 20GB to start, you’re going to need enough storage on your backup device to hold the entire 250GB.

With dynamic drives, you will almost undoubtedly overprovision. Ensure that you periodically review the actual usage of your storage system. If Hyper-V runs out of space, it will pause VMs, and that is not a situation you want to be in.

Networking

Networking resources are often all but forgotten in a virtualized environment. If you have VMs that will be shipping a lot of data (backup servers, heavy-draw file servers), then don’t forget to balance for these. If you’ve only used one physical NIC in each host for virtual switches, then there isn’t a lot that can be done here. If you have multiple, then you have a couple of options. The first is to team the NICs together at the host level using the NIC manufacturer’s driver settings and creating the virtual switch on that. In that configuration, all of your VMs will be sharing one large pipeline. Another option is to keep the physical NICs unteamed and create multiple virtual switches. That gives you more granular control over which VMs utilize which virtual switch, allowing you some ability to shape traffic.

Giving Hyper-V Hints

Now that you have the resources designed on your VM, it’s time to give Hyper-V some guidance on what to do when those resources are under contention between this and the other VMs. If you do nothing, then Hyper-V will essentially act in a “first-come-first-served” method, assuming that VMs that were already using the resources take precedence over those who asked for them later. You can override this behavior to ensure your mission-critical VMs get preferential treatment. In Hyper-V Manager, set CPU and Memory weights on their respective tabs. In SCVMM, set them both on the “Priority” tab. Giving higher weight to a resource means that this VM will have higher priority if contention occurs.  This setting is especially important if you expect VMs to fight over memory. Hyper-V is somewhat blind to what is going on inside the VMs, so if a guest configured to use dynamic memory asks for more RAM at the same time another one does, Hyper-V won’t know that one is a SQL Server processing your CEO’s dashboard while the other is a customer service rep requesting a large file copy, so it’s up to you to have set priorities properly.