Andy Dawson's Blog

Tuesday’s IT Camp in Leeds was great fun and introduced lots of people to Hyper-V.

The day itself was very different to the normal events that we’ve seen or been part of; I think I counted two PowerPoint slides during the entire event! The attendees were given the opportunity to try out Microsoft’s Hyper-V Server installing it on a VHD on the file system on their own laptops. We’d brought a couple of laptops along with blank disks so that others could also play and these were snapped up very quickly.

As is usually the case, not all of the demos went entirely according to plan, however nobody present seemed to mind too much. Andy and Simon did a marvellous job working around the problems and keeping the event flowing. There was lots of enthusiasm for more events in Leeds – we’ll keep you posted when more dates in Leeds become available.

There were lots of specific questions both relating to Hyper-V and on other subjects, which we were pleased to help with. I hope that everyone who attended left with knowledge about, and enthusiasm for Hyper-V, which is what the day was all about. A good many of the attendees seemed to enjoy getting stuck in with Hyper-V server.

Along with Rik’s recommendations, I have a few additional resources related to Hyper-V that I use on a regular basis:

• To allow remote administration of Hyper-V from a Windows 7 computer, you’ll need the remote server administration tools for Windows 7. After installing the appropriate package from the link above, the remote admin tools can be enabled from the ‘turn Windows features on or off’ area of Control Panel. A combination of the remote admin tools and John Howard’s HVRemote allows quick and easy setup of administration of Server Core or Hyper-V Server.
• Tore Lervik’s Hyper-V Monitor Gadget allows quick and easy monitoring of Hyper-V virtual machines from your desktop – this is an invaluable tool to keep an eye on your virtual servers and those of us who look after our Hyper-V servers at Black Marble recommend it!
• The Microsoft iSCSI Software Target was mentioned a couple of times during the event; I’ve used it a few times to create the shared storage that is required for a cluster. It’s a quick and easy setup and turns almost any old computer into storage suitable for building a cluster on. It’s even supported in production, and is completely free!

Andy and Simon are running more hands-on IT Camps; a full list can be found at http://uktechdays.cloudapp.net/it-pro-camps/ – if there’s anything on the list that you’d like to see, get registered and come along!

Building a Hyper-V virtual machine from scratch almost always seems to involve mounting an ISO image at some point during the installation process. I suspect that like us, many other organisations already have a network location in which we store ISO images. The ability to mount an ISO image from our usual network location saves us having to copy the ISO images to the local Hyper-V servers.

The ability to remote mount an ISO image requires that a couple of configuration changes are made. Attempting to remote mount an ISO image without making the configuration changes usually results in an err along the lines of

Inserting the disk failed

Failed to add device ‘Microsoft Virtual CD/DVD Disk’

The file ‘\\RemoteServer\Share\ISO_Image.iso’ does not have the required security settings. Error: ‘General access denied error’

There are two configuration changes that need to be made. The first is ensuring that the Hyper-V hosts can access the share itself that contains the ISO images. As a workaround, you can always grant ‘Everyone’ read access to the share. If you want to control access to individual servers, you need to specify the Active Directory computer object for each server you want to give access to.

The second configuration change that is required to to grant Constrained Delegation on the virtual host objects in Active Directory:

• Log onto a domain controller and open Active Directory Users and Computers from the Administrative Tools menu, or open the remote administration Active Directory tools from another server or client
• Locate the Hyper-V host computer object
• Right-click the object and Select Properties from the context menu
• Select the Delegation tab
• Select the ‘Trust this computer for delegation to specified services only’ radio button and then the ‘Use any authentication protocol’ radio button
• Click the ‘Add’ button:
  
• The ‘Add Services’ dialog will open:
  
• Click the ‘Users or Computers’ button and add the remote server hosting the ISO images. Click OK
• Select the ‘cifs’ service type from the list shown:
  
• Click OK to close the dialog, the computer object properties should look like the following:
  
• Click OK to apply the change
• Repeat the above steps for any other Hyper-V hosts servers.

You should now be able to remote mount ISO images from the server specified.

We’ve recently seen an issue running Windows Server 2008 R2 with the Hyper-V role installed on an Acer 6593G laptop. We’d updated the BIOS to the latest version available from the Acer site (1.16 at the time of writing) and Server 2008 R2 would no longer boot once the Hyper-V role was installed.

Rolling back the BIOS to the 1.11 version solved the problem.

We’ve also tested the 1.09 version, which seems to work okay, but have yet to try the 1.13 version which is also available. I’ll update this post when we’ve tried the 1.13 version.

One of the issues I’ve seen during our migration of virtual machines to our new Windows Server 2008 R2 Hyper-V cluster relates to network load balancing (NLB).  We have a number of NLB setups running which will need migrating in time.  My first test migration of a pair of NLB virtual machines (actually, technically a trio of servers making up a SharePoint farm) didn’t go as smoothly as I’d hoped.

The machines in question have been running on a Windows Server 2008 Hyper-V machine quite happily for some time.  I followed the procedure we’ve used to migrate other machines to our new Windows Server 2008 R2 Hyper-V cluster, connecting both network adaptors to the appropriate network when the import had completed.  When I looked at the network settings in the GUI, two network adaptors showed up and the configuration at first glance seemed okay.  When looking at the network configuration using ipconfig however, only the values for one network adaptor (the primary, i.e. non-NLB, adaptor) were shown, with the NLB adaptor missing in action.

In addition, NLB manager showed the following error when I tried to reconfigure the cluster:

The solution to the issue is actually simple; in the Hyper-V VM settings for the NLB network adaptor, turn on MAC address spoofing:

This immediately fixed the issues we were seeing with the NLB adaptor of the machines we were migrating.

At Black Marble, we’re in the process of migrating some of our virtual machines to a Windows Server 2008 R2 Hyper-V cluster.  The process of migrating machines from a single Hyper-V host to a Hyper-V cluster is not quite as straightforward as migration of a machine from one single host to another.  In addition, our migrations are made slightly more interesting as our Hyper-V cluster is built on Server 2008 R2 Core machines, so no GUI interface on those machines to help us!

Due to our cluster being Server 2008 R2 Core machines, we do all of our administration remotely.  Once the cluster is built, we rarely spend much time directly connected to the cluster machines.  Most of the administration for virtual machines is done from the Failover Cluster Manager on another server we use as an application server.  While the Failover Cluster Manager allows us to create new virtual guests directly from the interface, there is no apparent way to import virtual machines that already exist onto the cluster directly from the interface.

Importing pre-existing virtual guests onto the cluster therefore becomes a two stage process; firstly import the machine using Hyper-V Manager, then make them highly available.

To import the virtual machine, the following steps need to be taken:

1. On the Hyper-V host running the machine you wish to migrate, export the virtual guest.  In the case of a few of our machines, they were built using differencing disks and we took the decision to merge the disks so we didn’t have base disk stacks littered all over the place.  As our virtual machines were hosted on Windows Server 2008 Hyper-V, this meant that we had to delete any snapshots we had as well and then switch off the machines and allow the background disk merge required in these circumstances to finish before we could merge the differencing disk stack we’d created.
2. Once the export had completed, copy the resultant files to an appropriate location on the CSV disk on the new Windows Server 2008 R2 Hyper-V cluster.  The use of a CSV location is required to allow us to make the virtual guest highly available later.
3. Using Hyper-V manager connected to the specific virtual host in the new cluster the migrated machine should run on initially, import the virtual machine.  Note that with Hyper-V R2, you can choose to duplicate the files so that the virtual machine can be imported again should you need to.
4. Once the virtual machine has been imported, you’ll need to check the settings and may need to connect the network adaptor(s) to the appropriate virtual network(s).  Note that the required virtual networks need to be created individually on each of the Hyper-V cluster nodes.

At this point, you have a virtual guest that has been migrated to its new host, but has not been made highly available.  To achieve this, the following steps need to be taken:

1. Connect to the Windows Server 2008 R2 Hyper-V cluster using Failover Cluster Manager.
2. Right-click on the ‘Services and applications’ header in the left pane of the Cluster Manager and select ‘Configure a Service or Application…’
3. A new window, the High Availability Wizard, will open. Click next on the first page, then select ‘Virtual Machine’ from the list of available service and application types on the next screen and click next
   
4. The imported virtual machines that have not been made highly available will be presented as a list with checkboxes beside them. Select the virtual machines you wish to make highly available and click next
   
5. Click next on the confirmation screen and wait until the wizard completes. Click finish on the summary page, unless you wish to vie the more detailed report (if for example an issues were encountered during the HA wizard).

Your migrated, highly available virtual machines should now be available via the Failover Cluster Manager.  You may wish to modify the properties of the migrated high availability virtual machines to set items such as preferred owner and failover/failback settings before starting them.