Since I have this lovely Lenovo W530 laptop with a couple of disks and 32GB of RAM, it is great to run VMs on!  As you can imagine, I have multiple different Exchange labs to reflect all the different versions and builds that are in use.  Generally I have been able to import all of my older VMs into Hyper-V on Windows 8 and 2012 with no issues.  But as you probably have guessed by now, if I had not ran into something this blog post would not be needed………

Update 22-10-2013:  If trying to import a Windows Server 2008 R2 VM into Windows Server 2012 R2 or Windows 8.1 please also see this post.

Update 10-1-2014:    Updated error message is present in Windows 8.1.  Please see this post.

What’s The Story, Morning Glory?

<Courtesy link to Oasis>

The machine we will look at is an Exchange ActiveSync emulator running Windows Mobile 6.5, but that’s not too relevant.  I copied the files over to the C:VMs folder, and then went to import the VM using the wizard:

   We can see the files have been copied over:

Now lets import the bad boy into Hyper-V:

As the Eurovision judges from Belarus say, “nil point”

In the Microsoft-Windows-Hyper-V-VMMS/Admin event log we can see that an error was logged.

• Event Source: Hyper-V-VMMS
• Event ID: 18364
• Event Body: The virtual machine configuration could not be read: Unspecified error (0x80004005).

The error is stating that Hyper-V is a smidge unhappy with the configuration it is trying to import.

Hmmm.  That’s a trifle annoying, isn’t it?  So let’s go get this fixed!

Don't Look Back in Anger

<Courtesy link to Oasis>

Taking a look at the directory structure, we see the following:

Looks like we have all the files, no?  There are VHD, export and some config type files.

Cracking open the World’s #1 troubleshooting tool, Process Monitor from Sysinternals, let’s trace to see what is going on at the file system level.  Maybe there is a deny NTFS permission ??

When firing up Process Monitor, it will capture a lot of data by default.  A lot.  So much so that we will need to tweak the capture filter to make it easier to parse the results.  When Process monitor is opened up, either click the magnifying glass icon or press Ctrl + E to stop the capture.  The magnifying glass icon will then have a red cross to indicate it is not capturing.

Then we can click onto the filter icon or press Ctrl + L to specify our custom filter.

In this case we know that the VM files are located in “C:VMsEAS VM” so let’s filter on that:

Click Include then add to include the path filter, then click OK.  You will see a new row with a green icon at the top of the filter view (not shown above).  Now that our filter has been saved let’s clear the screen with Ctrl + X.

We will then click the magnifying glass to start the capture, and then re-do the VM import that originally failed.  When the import fails, stop the capture with Ctrl + E.

As you can see, there are no access denied messages.  You can search for that easily in larger captures with Ctrl + F and searching.

What is interesting is that Hyper-V is looking at the .exp file and then moving on to the .xml file.  Hmm, wasn’t that one of the neat new features?  In Windows 2012 Hyper-V -- we do not have to specifically export a VM before it can be imported.  So why are both files here? Since I know that this VM was originally exported from a Windows 2008 R2 Hyper-V machine the .exp file is what is expected.

So lets backup and then remove the .xml file from the directory, and then re-do the import.  Note I said backup and not nuke, just in case!!  What happens now?

With the .xml file removed the import wizard is able to parse the VM and moves on to the next screen:

A couple more clicks to finish the wizard and then success!  The VM was successfully imported!  In the Process Monitor capture the .exp is processed and no errors are reported.

Champagne Supernova

<Courtesy link to Oasis>

After removing the spurious .xml file I was able to import the VM.   Note that there are other causes for the same error being raised.  The exact fix will depend on the version of Hyper-V.

As mentioned above each new release of Hyper-V has added new capabilities, and if we focus on just the VM import/export aspect:

Windows 2008 R2 Hyper-V added additional features when importing and exporting VMs, namely:

• Copy On Import – Can choose a different directory to import to.  Windows 2008 required admins to copy the VM package to the final destination and import from there.
• Export Snapshot – Can export just a single snapshot from the snapshot history as a complete VM.
• Fine grained Control – improved APIs to provide control over import & export operations.  Note that Configuration Only Exports are now done only via the API in Windows 2008 R2.

Windows 2012 Hyper-V removed the dependency on the .exp file.  In Windows 2008 and 2008 R2, a VM must have been exported before it could be imported.  This is a great feature for admins, and the following was a common scenario.  Why do we want this you ask?

Say that your lab Windows 2008 R2 Hyper-V host lost the RAID1 OS array, and you were left with only the RAID 5 array containing the VMs.  Because the VMs were not manually exported before the OS mirror failed, you could not just import them.  Backups of the VMs would be great, but not all lab VMs are backed up for example.  Sure you could create new VMs and attach the existing .vhd files to the new configurations but that means re-doing the IP addresses and depending on the OS having to clear out the old IP and NIC configuration.  How many times have I had to use KB 241257 with the command devmgr_show_nonpresent_devices=1 to purge stale NICs from a VM.

In Windows 2012 Hyper-V the VMs can be imported as-is – how neat is that?

One more thing to add on the Sysinternals topic.  You can go to live.sysinternals.com and directly download the tools that you want.  This is very handy if you know exactly what you want.

Cheers,

Rhoderick