Hyper-V R2 Import/Export – Part 1 – The Case for New Import/Export Functionality

Hyper-V R2 Import/Export – Part 1 – The Case for New Import/Export Functionality

  • Comments 8
  • Likes

This is the first blog entry of a multi-part series of blogs that addresses Import/Export in Windows Server 2008 R2. This blog talks about the scenarios enabled by the changes made to import/export in R2.

Ben Armstrong had blogged earlier about the intricacies of Import and Export with v1 Hyper-V in his blog posts:
http://blogs.msdn.com/virtual_pc_guy/archive/2008/08/26/hyper-v-export-import-part-1.aspx
http://blogs.msdn.com/virtual_pc_guy/archive/2008/08/27/hyper-v-export-import-part-2.aspx

Now, the big problem with how import export worked in v1 was that it just did not give the user enough control over the process of exporting and more significantly, importing a VM. Additionally, it was rather unforgiving. I bet many a user has been burnt trying to import a VM a second time only to find out that since he/she had imported it once already, the import folder could not be used anymore.

So, introducing the R2 version of Import Export: a lot more fine grained control on the entire process as well as added capabilities that are more in tune with user needs. Here is a list of capabilities enabled with the new Import Export functionality:

  1. Copy on Import: The R2 Import/Export APIs now allow the user to specify a location to import to and not use the import directory as the VM's execution directory. Thus, the user can now create a "gold VM", export it once to a file share and then import it multiple times from that file share. This capability ends up enabling a number of scenarios as a result:
    a. Backup-restore: For the users who do not want to use a backup application to backup their VMs, they can use import/Export and can restore the same files multiple times. Additionally, they can now have their backup media as read-only.
    b. Moving/Cloning VMs: The users do not need to do a separate file copy operation in order to move a VM now. They just have to export to a file share and then import it. Additionally, at import time, the user can now specify where to place the VM on the target machine.
  2. Export of a Snapshot: Picture this in the v1 days of Hyper-v: Tester Fred is running a number of tests using virtual machines. During the course of the tests, he takes snapshots at different points in time. Now, after snapshot #5 of 20, he sees a bug. So, he would like the developer to take a look at it. However, he would need to export the entire VM and all its snapshots in order to do that. In R2, he can export snapshot #5 as a separate and independent VM and send it to the developer to debug.
    Additionally, this functionality has enabled another scenario in the IT arena: IT Admin John has a staging environment where he experiments with a number of versions of software in a VM to determine which works best for his scenario. Using R2 Hyper-V, he can create snapshots for each version of the software being tried out. When he determines a version that would work best in his deployment, all he has to do is to export that snapshot and then import it as an independent VM in the production machines.
  3. Fine grained control: In R2, we have a much richer APIs for Export and Import, enabling the user to tweak parameters like VHD paths, network connections and AzMan during import. Additionally, these parameters can be modified regardless of how the export was carried out. In v1, if the users did a full export (ie: export with configuration as well as VHDs), there was little available to the user to tweak upon import. If they exported config only, they had to edit the config.xml file upon import. None of that in R2. All the parameters can now be tweaked via the import APIs. More on this in the following blog
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • <p>PingBack from <a rel="nofollow" target="_new" href="http://valuableinternetinformation.com/?p=30904">http://valuableinternetinformation.com/?p=30904</a></p>

  • <p>I have a better understanding of this article with the description thank you</p>

  • <p>Hi...I know this is an old blog, but I was hoping to find an answer related to this topic. &nbsp;</p> <p>Why is it (architecturally) that if I copy a VHD file over to another Hyper-V server (instead of Export/Import) and create a new VM that uses that VHD, it always loses its network settings, even when the virtual networks are named identically on each server.</p> <p>The behavior is similar to performing an export and then importing into a machine that does not have an identically named Virtual Network - the network card inside of the VM drops off and a new one configured for DHCP gets created.</p> <p>If I perform an export/import between the exact same two Hyper-V servers, the network settings are preserved without issue. &nbsp;What is the import doing differently under the covers than simply mounting that VHD on a new server?</p> <p>Thanks for any insight you can provide!</p> <p>Doug</p>

  • <p>Doug,</p> <p>Think of what happens when you do the following to a physical machine.</p> <p>1. Remove the hard drive.</p> <p>2. Install the hard drive in a different physical machine.</p> <p>3. Start the new machine with the moved hard drive in it.</p> <p>When that hard drive is first started in the new physical machine the current hardware resources available are detected and drivers are installed to use those detected devices.</p> <p>Moving a VHD from one host to another and then creating a new VM is essentially the exact same process. &nbsp;The network settings for a VM are not stored in the VHD file but rather in the VM configuration file (that is not on the new host if you only copied the VHD file to the new location). &nbsp;When you export a VM to a folder on the other host and then import that VM on the new host, the network settings are preserved because the file that contains them has also been copied to the new host. &nbsp;Since the new host has a virtual network with the same name/identity as the old host, the VM is able to reuse those network settings that were transferred during the export/import process.</p> <p>The import is using the VM configuration data that is copied to the new location when a VM is exported. &nbsp;Look at the contents of the folder where you export a VM. &nbsp;Not only is the VHD there but also the other files necessary to get the VM running, the memory configuration, the network settings, the disk locations and settings for not only a VHD file but also any passthrough disks.</p> <p>Please review the following post on the TechNet Wiki for more information regarding the files that are associated with a Hyper-V VM.</p> <p><a rel="nofollow" target="_new" href="http://social.technet.microsoft.com/wiki/contents/articles/hyper-v-how-to-find-vm-files.aspx">social.technet.microsoft.com/.../hyper-v-how-to-find-vm-files.aspx</a></p> <p>Hope this helps.</p> <p>David</p>

  • <p>If I import a new VM from an Existing snapshot export, &nbsp;can I delete the original VM ?</p>

  • <p>Hi,</p> <p>I am in the process of setting up a new DR infrastructure in another Site . New DR environment is in &nbsp;hyper V platform. Can i use hyper v export in primary datacenter along with installed application and import it in DR datacenter then change hostname and IP. Will the installed application on VM will &nbsp;work like a new installation ? </p> <p>Rgds</p> <p>Arvin.</p>

  • <p>Hi,</p> <p>I am in the process of setting up a new DR infrastructure in another Site . New DR environment is in &nbsp;hyper V platform. Can i use hyper v export in primary datacenter along with installed application and import in DR datacenter then change hostname and IP. Will the installed application on VM will &nbsp;work like a new installation ? </p>