<h1>How to Setup a Virtualization Lab (I)</h1>

Now that I have concluded a general overview of most of the theory related to High Availability and Virtualization it is time to start testing some of those concepts and see them in action.

My goal for the next posts is to produce a series of tutorials showing how anyone can easily install a handful of virtual machines and be able to explore the wonderful possibilities provided by this technology. I will be using an old laptop powered by a Turion 64 X2 CPU with a 250 Gb SSD HD and 4 Gb of RAM combined with a desktop running Windows 7 Ultimate on a Athlon 64 X2 4800+ with 4 Gb of RAM and lots a free disk space scattered through 3 SATA hard drives.

Virtual Machines Creation

I will not go through the details of OS installation because I am assuming the ones reading these tutorials are way passed that.

I started by installing a fresh copy of Windows Server 2008 R2 SP1 Standard on a secondary partition in my laptop.  Once I was done with the installation of all the available updates from Windows Update and with OS activation, I was ready to add the Hyper-V role in order to be able to install the virtual machines. To do this I just went into Server Manager/Roles, started the Add Roles Wizard, selected Hyper-V and followed the procedures. Nothing special so far, right?



Note: All the pictures are clickable and will open a larger version in a separate window.

Then it was time to start setting things inside Hyper-V. I always start by creating a virtual network that will allow my VMs to connect outside of the physical host.



I opened the Virtual Network Manager and, as you can see in the figure, I created an External Network, renamed it External (duh…!) and connected it to my physical NIC so that the VMs using this connection can access it directly.

Now I was ready to install my first VM and that is also a straight forward procedure:

1. Choose a name: LAB-DC it will be my domain controller;
2. Assign memory (RAM): 500 Mb will do for now;
3. Configure networking: at this stage I created only one virtual network so I had to choose the External network;
4. Create a virtual hard disk: I created a 20 Gb new .vhd file;
5. Installation Options: I installed Windows Server 2008 Enterprise Edition SP1 from a DVD;
6. Check your settings: The default settings will get you started but before you start installing, you can change some other settings to adjust the VM’s behavior to your needs.

Upon installation it is good practice to fully update the OS with all the available patches but there is no point in activating it at this stage and you will understand why in a moment. Now, with the first VM ready and fully updated, it was time to install one or two more. But why not just clone the first one instead? This can be properly done using System Center Virtual Machine Manager or by hand. In any case, the first step is to use sysprep in order to “clean” the machine.

Virtual Machine Cloning

Performing a virtual machine export is simple. As with any other cloning operation, you will want to configure the virtual machine that you want to clone (do not try to clone a production virtual server), and then run sysprep. If you have two machines that are completely identical, then networking ceases to function. To avoid any complication, it is mandatory to make some things unique for each computer:

• The Windows Security Identifiers (SIDs);
• The Media Access Control (MAC) address;
• The Internet Protocol (IP) address;
• The NetBIOS and Fully Qualified Domain Names (FQDN);

Given that some system attributes are required to be unique, simply copying virtual hard drive files and building another virtual machine around them will not work. In Windows Server 2008, sysprep is installed by default. You can access sysprep by going to C:\Windows\System32\Sysprep and running sysprep.exe. When you do, you will see a screen that is similar to the one that is shown in the next figure.



As you can see in the figure, the sysprep interface is pretty simple, but even so it is very important to pick the correct options. Otherwise you could find yourself having to go through the configuration and preparation process all over again.

The System Cleanup Action drop down list contains two options; Enter System Out of Box Experience (OOBE) and Enter System Audit Mode. I had to choose the Enter System Out of Box Experience (OOBE) option and select the Generalize check box. Otherwise, the system will not have been stripped of its uniquely identifying attributes. Finally, I had to set the Shutdown Options to Shutdown. It is important to select Shutdown and not Restart, otherwise the recently generalized system will reboot and enter into Windows mini-setup mode, effectively undoing all the prep work.

Now, I could begin the actual export process. To do so, I just opened the Hyper-V Manager and selected the virtual machine to export. Next, I clicked the Export link that is located in the console’s lower, right pane. When I did so, Windows opened the Export Virtual Machine dialog box, shown in the next figure. I entered the destination folder and waited for a couple of minutes.



After exporting my virtual machine, I could clone it. There is no proper cloning wizard in Hyper-V but a syspreped machine can be easily cloned manually just by copying and renaming the vhd file and using it as a base disk for a new VM. Yes, it’s as simple as that. At least for the setting of a lab environment, in a production scenario you should pay attention to a different set of details but I won’t go into that now.

Take a look at what I did:



I took the exported LAB-DC.vhd file from the destination folder (C:\Export) and copied it to some previously created folders under the Hyper-V\Virtual Hard Disks default folder. Then I renamed the .vhd files to LAB-NODE1.vhd and LAB-NODE2.vhd and used these files as hard drives for new VMs. In a couple of minutes I had two clones from my previously created and fully updated Windows Server 2008 Enterprise SP1.

Once booted, all the VMs had to be renamed and activated (now was the time to activate them!) but that took a few minutes only, instead of the hours needed to install and update multiple fresh copies of the operating system. Besides, I kept a copy of the exported syspreped .vhd file to use as a master for any future clones.

Setting the Virtual Connections

Before explaining what I did to setup networking for all the VMs, let’s take a look at what happened in the host OS in the meantime. As soon as I created the External Network inside Hyper-V, a new network appeared in the host’s Network Connections. I renamed it to VLAN just to make it clear.



Before we go any further, I believe it would be best to explain a bit more of what is actually behind all this magic.

A closer look at Hyper-V

Remember when I went through all the different kinds of virtualization, namely the different hypervisors used in full virtualization? Well, in order to better understand what lies ahead I have to give you some additional details on the way how Hyper-V works.

Hyper-V is a microkernelized Type 1 hypervisor requiring hardware acceleration.

This means all of the operating systems in a Hyper-V environment are actually guest operating systems. Some of you are probably asking “What about the operating system I used to install Hyper-V?” The answer comes from the installation process for Hyper-V because prior to that we have to go to the BIOS and enable hardware virtualization. If your CPU doesn’t have hardware virtualization support, then forget about it. Once we have enabled hardware virtualization then we install Hyper-V. But Hyper-V has to come from somewhere and we can actually install Hyper-V Server which is a free download command line version of Windows Server with only the Hyper V role as an option for install.

After the installation of Hyper-V the system will demand for a reboot. When the machine reboots Hyper-V will now regulate the startup of all operating systems, even the operating system that was used to write the hypervisor (Hyper-V) to the physical hardware. But that original operating system has a special function being that it can actually write to the hypervisor so we don’t simply call it a guest operating system; instead we call it the Parent Operating System or the Parent Partition.



In Hyper-V, the parent partition does not have full control over the server’s hardware. Most of the hardware functions are managed by the hypervisor which ensures that hardware resources are made available to each virtual machine and to the server’s primary operating system.

That being the case, the parent partition does not directly use the physical network adapter. Instead, all network requests pass through the virtual network adapter, and then through a virtual switch, and ultimately to the physical network adapter. Thus, the virtual network switch serves as a link between the physical and the virtual network adapters. But maybe we should focus on more practical things, right?

Enough already with the theory!

Connecting the Virtual Machines

These are the settings for my Physical Connection:



And the settings for the VLAN Connection:



As you can see in the previous pictures, the VLAN has a fixed IP whilst the Physical Connection is using DHCP and in order to guarantee simultaneous outside connectivity to both the host (parent partition) and the VMs, the Physical Connection has to be shared. Now let’s take a look at how the virtual networking looks at this stage. From the VM’s perspective we have this:
 

The Switch is purely virtual, created by Hyper-V, and the Gateway appears to be the host physical machine. But from the host’s point of view we have something else:



The host can see the real Gateway, my router, and the Windows 7 desktop connected to it because they are on the same subnet with IPs given by the router’s DHCP service. This can be a very useful setting if you want to isolate your VMs and, at the same time give them outside connection using the parent partition as a gateway.



This is what is going on from the virtualization point of view. The end result is that the Parent
Partition, Child Partition 1, Child Partition 2, and Child Partition 3 can all communicate with each other, because each of these partitions is connected to a common virtual switch within the parent partition.  Besides, they can also communicate with the desktop PC connected to the physical router.

At this stage all my machines (two physical and three virtual) have full internet access and can communicate over my LAN. So it’s time to move on to the next stage: create VMs inside the Desktop computer and connect them to the network.

That will be next post’s topic…