You all know by now that I am a huge Hyper-V fan… I have been using it since 2008, but with the latest release I am unabashedly loving Microsoft’s Layer 1 hypervisor. The fact that it has been included in Windows 8 – as in, no different from the virtualization platform I use in my servers – is just the icing on the cake.
It is true that almost any IT Pro would be able to install and use Hyper-V on either the server or client platform without much guidance. However when you do start out – either with Hyper-V in general, or on a new system – there are a few things that you should know before you go. Here are some of my tips, in no particular order of importance.
1) Change the default file locations!
The default file locations for virtual hard disks and virtual machines are a bit obscure. I like to change them right out of the gate. Depending on which drive I want to store them on (in Windows 8 it is usually the C drive, while on proper servers it will usually not be) I will store them both right off the root… x:\VHDs and x:\VMs. That way I do not have to navigate to the defaults whenever I want to copy a file. I find x:\VHDs much easier than c:\Users\Public\Documents\Hyper-V\Virtual Hard Disks and c:\ProgramData\Microsoft\Windows\Hyper-V.
If I am going to use Failover Clustering with Cluster Shared Volumes the defaults will be different, but for standalone servers these defaults suit me fine.
STEPS:
- In Hyper-V Manager click on Hyper-V Settings… in the Actions Pane.
- Under the Server context, click on Virtual Hard Disks and change the default location. You will have to create the directory before going ahead.
- Still under the Server context, click on Virtual Machines and change the default location. Again, you will have to create the directory first.
It’s as easy as that. Of course, VMs that are already there will not be moved, but going forward all VMs will be placed in the proper directory.
2) Create your Virtual Switch!
When you start creating virtual machines there will be nowhere for them to go and nobody for them to talk to… that is, unless you create a virtual switch (previously called virtual network) to connect them to. Depending on your server and your environment this might be simple or complex, and may require more planning. However the long and the short of it is you have to make three decisions when creating a virtual switch:
- Is the network going to be External (can communicate beyond the physical host), Internal (can only communicate with other VMs on the same host, plus with the host), or Private (can only communicate with other VMs on the same host)?
- If External, what physical NIC (uplink) will it be bound to?
- Can the Management OS (on the host) use the same NIC?
STEPS:
- In the Action Pane of Hyper-V Manager click Virtual Switch Manager…
- In the navigation pane click New virtual switch
- In the right screen select External, Internal, or Private and click Create Virtual Switch
- In the Virtual Switch Properties window delete New Virtual Switch and name the switch something that you will understand (i.e.: CorpNet).
- Click OK to close the Virtual Switch Manager.
Again, this is all there is to it. Plain and easy, no fuss, no muss.
3) Configure Dynamic Memory
When you create a virtual machine there are a few defaults that Hyper-V thinks is a good idea… which I don’t. The main one that comes to mind is the Dynamic Memory option (per VM). When you configure Dynamic Memory the defaults are going to be:
Startup RAM: 512 MB
Minimum RAM: 512 MB
Maximum RAM: 1048576 MB
Ok, for a lot of our virtual machines 512MB may be a fine minimum… but unless you are driving a BAWL (Big @$$ Work Load) server on the VM you will nearly never need a terabyte of RAM. Granted it is nice that we have that ability, it is not going to be the norm. On the other hand, not setting a realistic maximum would mean that if your VM were to place a huge memory demand – say, because of an unchecked memory leak or a compromised server, or even something as simple as an Exchange Server grabbing as much physical (ahem… virtual) RAM as it can – then this would necessarily be at the expense of contention resources, which would no longer be available to other virtual machines on the same host.
My recommended best practice is to pick minimums and maximums that are reasonable to you for each server (and those will be different from VM to VM, depending on the load expectations). You will be able to tweak these up or down as needed, but the point is you will have reasonable limits. For many of my servers I set limits such as these:
Startup RAM: 512 MB
Minimum RAM: 512 MB
Maximum RAM: 4096 MB
These settings allow the VM to consume up to 4 GB of RAM when needed and available, but no more than that. If I discover the VM workload needs more then I will tweak it up incrementally. I am not letting resources go to waste, and I am making sure that my VMs work within their means – i.e.: as efficiently as they can.
STEPS:
Within Hyper-V Manager click on the VM in question and then in the Action Pane (VM Name) click Settings…- In the Navigation Pane click Memory
- In the Memory window change the Minimum and Maximum RAM as needed.
- Click OK.
4) …and Hard Disks!
By default the virtual hard disks that are created for us in the New Virtual Machine Wizard will be 127 GB. But do they really need to be that big? Actually, in a lot of cases they do. In many cases they should be bigger. Sometimes they should be smaller. If you are creating your disks this way then you should right-size them in the wizard.
With that being said, the one question that the wizard does not ask you is ‘what type of disk would you like to create?’ In Server 2012 there are actually three questions that you should be asked that are only asked when creating your disks using the New Virtual Hard Disk Wizard:
a) Would you like to create a VHD file (with backward-compatibility, and limited to 2 TB in size) or a VHDX file (which adds resilience to consistency issues that might occur from power failures, and are limited to 64 TB in size but offer no backward compatibility)
b) Would you like the disk to be Fixed size (pre-provisioned storage), Dynamically expanding (storage on demand), or Differencing disk (associated with a parent-child relationship with another disk)?
c) Would you like to create the new VHD(X) file based on the contents of an attached physical drive?
The solution is to pre-create your VHD(X) files to spec, and then point to them from the New Virtual Machine Wizard. While dynamically expanding disks are fine for labs and offer greater portability, I never recommend them in a production environment. Also if you think you might need to port your VMs back to Server 2008 (or Windows 7) then VHD will be required.
STEPS:
- From the Hyper-V Manager console in the Actions Pane click New > Hard Disk…
- Go through the wizard and select the options you choose.
- From the New Virtual Machine Wizard click the radio button Use an existing virtual hard disk and point to the right file.
- Click Finish.
Alternately, you could select the radio Attach a virtual hard disk later and create your VMs, then create your VHD(X) files, and then attach them. It seems like more work to me though…
5) …and CPUs!
There are a few new settings in the Processor tab of Hyper-V VMs than there used to be. Not only can you set the number of virtual processors (to the lesser of either a maximum of 64, or the number of physical cores in your computer), but you can also set the VM reserve, the percent of total system resources, the VM limit, and the relative weight. These are all set in the main screen of the Processor Settings page.
What a lot of people do not realize is that there are two subsections to the Processor tab: Compatibility and NUMA. In order to access these you need to expand the + next to Processor in the navigation pane.
NUMA stands for Non-Uniform Memory Architecture, and essentially means that a single VM can use memory that is assigned to different physical CPUs.
Compatibility in this context refers to CPU families, and is a very handy option indeed. In virtualization there is no way to live-migrate a VM from a host running on AMD CPUs to a host running on Intel CPUs. This is not a limitation of Hyper-V, rather of the architecture of CPUs, and is identical in VMware. However CPU family is not the only limiting factor to allow live migrations; CPU properties are a factor too, and because of advancements in the technology it would generally not be possible to live migrate a VM from a host with an older CPU to a host with a newer CPU.
A few years ago VMware saw this as an issue, and along with Intel developed a technology called EVC, or Enhanced vMotion Compatibility. What EVC does is it masks the newer chipset features (generally multimedia signatures and things like that) from the VM, so that all of a sudden you can migrate between older and newer hosts (say, an Intel i7 to an Intel Core Duo). In VMware this is assigned at the Cluster level.
Of course the technology is simple enough, but the intellectual property is not. EVC has the word vMotion (a trademark) in the title. Microsoft cannot use the term vMotion. As such their compatibility mechanism (which works the same way) is called Migrate to a physical computer with a different processor version (MTPCWDPV). The name is not nearly as sexy as EVC, but they compensated by assigning it to the VM instead of the cluster. It is a simple checkbox that you check (or uncheck) under the Compatibility Configuration screen.
If you are going to be using Live Migration between hosts with potentially incompatible CPU then follow these steps:
STEPS:
Within Hyper-V Manager click on the VM in question and then in the Action Pane (VM Name) click Settings…- In the Navigation Pane click Processor, then click the + next to Processor to expand the tree.
- Click on Compatibility
- Click the checkbox Migrate to a physical computer with a different processor version.
- Click OK.
Following these simple best practices will not make you an expert in Hyper-V by any means, but it is a good start… what they will allow you to do is get started comfortably and play with the technology without hitting some of the more common stumbling blocks that beginners seem to run into. As your needs grow you will be comfortable enough with the technology to try new things, explore new possibilities. Before long you will be as virtualization expert, ready to tackle concepts such as Shared Nothing Live Migration, Failover Clustering, Cluster Shared Volumes, and much much more.
In the meantime dip your toes into the virtualization waters… it’s warm and inviting, the hazards are not too dangerous, and the rewards are incredible. In no time you will be ready to get certified… but even if that is not your goal you have already taken the first steps to becoming a virtual wiz!
45.417000
-75.717000
Like this:
Like Loading...
