Andy Dawson's Blog

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.

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.

I’ve been a bit delayed writing this final blog post from Tech Ed EMEA 2008, so I’m back in the UK. The final day at Tech Ed 2008 EMEA IT was not quite as session filled as previous days, mainly because Rik and I had to be heading off to the airport shortly before 3pm to catch our flight home.

The first presentation of the day was on getting the most out of WSUS 3.0 SP1. One of the items that was mentioned was the arrival of WSUS 3.0 SP2; this is currently in the planning phase and aims to fix the top customer and partner issues seen. It will also install on Windows Server 2008 R2. A number of scenarios for WSUS were discussed, including larger numbers of clients, branch offices and disconnected clients (submarines being the example used!) and some best practices discussed. If the video of this talk is available (at the time of writing, it isn’t unfortunately) and you use WSUS, I’d recommend watching it.

The second (and last) talk of the day I went to discussed Exchange 2007 SP1 and Hyper-V. The good news is that Exchange 2007 SP1 is fully supported on any of the x64 hypervisors validated by Microsoft on Windows Server 2008. If you want to virtualise your Exchange 2003 installation, you’ll need to use Virtual Server 2005; note that Exchange 2003 is explicitly not supported on Hyper-V.

Following these talks Rik and I spent some time talking to more of the experts in the ask the experts pavilion and got some answers to some long-standing questions.

Our flight home was uneventful, but it seemed rather cold when we stepped out of the plane at Manchester after the week in Barcelona!

Today has been interesting. Rik and I started the day doing the sightseeing we had time for. The Gaudi cathedral had been particularly recommended, so with limited time at our disposal, that’s what we decided to see. We arrived at the gate just as it opened, and were in within a few minutes. The cathedral is very, very impressive, though there is an awful lot of construction work going on at the moment. It is an amazing structure, with a very impressive sense of light and space inside:

Following the trip to the cathedral, we headed back towards the convention centre to get lunch and to try to get into the main auditorium for the keynote early enough to get a good seat. I was glad that we made the effort as we managed to get seats near the front tucked off to one side. Here’s our view of the stage, and the auditorium once it had nearly filled:

The keynote by Brad Anderson was interesting, with a number of announcements and some very useful demos. I was particularly impressed with the drive towards virtualisation, and the available and forthcoming tools to help you manage the resulting data centre. There was a live migration demo using Server 2008 R2 which demonstrated a live move of a virtual machine from one host to another with no interruption of service. In addition, Gemini was demonstrated; a self service BI offering allowing anyone within the organisation to view and manipulate data from sources such as SQL Server. The most impressive part of the demonstration as far as I was concerned was the ease (and speed!) with which the data could be published to SharePoint for consumption within the business:

Also mentioned were items such as Cross Platform Extensions for SCOM allowing monitoring and management of non-Microsoft systems and server Application Virtualisation allowing the separation of the server OS and the server application allowing each to be managed (and patched) separately – all very interesting! A number of announcements were also made, for example System Center Operations Manager 2007 R2 Beta will be available for download at the end of November.

From there it was off to the first session; Planning and Operations Tools for SharePoint which provided some useful pointers and allowed the possibility of some feedback to the managers of the solution accelerators programme.

After the sessions this afternoon, Rik and I spent some time wandering around the Ask The Expert area generally asking awkward questions of most of the people we could find.

All in all it’s been a very useful first day.

Following my last blog post regarding SCVMM 2008 Beta and the issues I was seeing with non-admin access to remote machines via Hyper-V manager, I thought it would be beneficial to forward my query to the team concerned via Connect. Here's the answer I got:

"What you are seeing is expected behaviour. When you add a Hyper-V host in SCVMM the Initialstore.xml file is no longer used for Hyper-V security. Instead SCVMM creates a new XML file and modifies it based on the user and admin roles that apply to that host in the SCVMM. That means that the step where you ran Azman and updated the Initialstore.xml file is lost. There is not a good workaround for this issue. The only thing that could be done is to add the user that needs access as a delegated administrator in SCVMM (with the right to administrator this specific host). Then SCVMM will update the XML file it uses with the correct info. Note that if you edit that file manually those changes will be lost when SCVMM refreshes it. It is called Hypervauthstore.xml."

This is useful insofar as it does indeed allow me a nice way around the problem I was describing. It does however raise another issue, which is that I don't believe that there is enough granularity in the delegated administrator role mentioned. I can only assign a host to a delegated administrator, not an individual guest. While I can limit which virtual machines a delegated administrator can log onto via user accounts, it may well generate a lower administrative overhead if I could limit the machines that a delegated administrator can connect to (say in the same way that TS Gateway works with RAPS and CAPS).

I'll feed this suggestion back to the team via Connect.

Yesterday I finally got around to installing SCVMM 2008 beta onto a virtual machine (mainly to help us with some virtual machine migrations we've got coming up).  I must say that I think SCVMM 2008 beta is very nice indeed!

On my Vista machine I use Tore Lervik's Hyper-V Monitor Gadget for Windows Sidebar, and have done for some time.  With the number of virtual machines we run, I have found it an invaluable addition to my sidebar.

This morning however, when I tried to connect to one of the virtual machines listed by the gadget, I got an error message 'An error occurred trying to find the virtual machine <GUID> on the server <servername>'.  In addition, when I tried to use Hyper-V manager, I received the error 'The virtual machine management service is not available'.

We thought for a while that it was related to remote rights (WMI/DCOM) on the servers in question (well, technically it is...) and I spent a while trawling through John Howard's articles relating to the required rights for remote management (well worth a read by the way).  Unfortunately even working through the articles didn't solve my problem.

After a little more rummaging, it turns out that installation of the SCVMM agent onto the servers hosting the virtual machines I want to remotely manage is what is causing the problem.  Anyone who is a local admin on the servers in question can freely manage the remote virtual machines; if you're not a local admin, you can't.  There are two potential solutions to the problem:

1. uninstall the SCVMM agent from the servers in question (which would no longer allow us to manage them from SCVMM)
2. Make anyone who needs to remotely manage virtual machines a local administrator on the servers in question

Lets be honest, neither option is entirely appealing (it's not that we don't trust some of the people who need to remotely manage specific machines, I just always would prefer to work from a 'minimum rights necessary' point of view), but as we have some migrations coming soon for which SCVMM is going to really help, we've gone for the latter.

I hope that this is something that is corrected in the RTM version of SCVMM 2008!