I received a comment via e-mail that it can take 2-3 times as long to move a VM from one Hyper-V host to another host, when compared to VMware or Virtual Server.  I do not think that the person mentioning this was super familiar with Hyper-V export, but their comment did make a good point about the portability of VMs between hosts.  Their goal was to efficiently migrate VMs from one host to another as part of an upgrade, and they were concerned about downtime.

You can copy a VHD from one host to another, but the configuration must be re-created.  It’s very hard to replicate a VMs configuration (MAC addresses for NICs, memory configuration, other virtual hardware attributes) simply by moving a VHD.  Hyper-V includes an export / import feature to encapsulate the configuration with associated VHDs for reuse.  Exporting a VM duplicates the (sometimes) large VHD files from the source VM to another location.

The e-mail comment made it clear that the person had not considered exporting a virtual machine over the network to a new host, rather than to local disk on the source.  They also didn’t know that SCVMM has a fantastic capability to move VMs from one host to another (similar to export and import), without the requirement of block level shared storage.  I’m not going to talk about SCVMM here, since it’s really easy (point and click) to relocate a VM using SCVMM (check it out!).

I am going to detail how to export a Hyper-V VM over the network, since I don’t see it covered anywhere else (I Binged hard, I swear!).

In order to export a VM to a network share (on the ultimate Hyper-V target host) a network share must be created with the appropriate rights granted to the exporting Hyper-V host. 
This may not be entirely intuitive, since you as the administrator are actually kicking off the export.  To put it simply Hyper-V is doing the export, so it needs rights to the remote share, not you! 

I just did this in my lab using two systems Hypernode1 (new host) and Hypernode2 (old host from which I want to export).  Here are the steps I followed (FYI, I blanked out the domain name in all the screen shots):

1. Create share on Hypernode1 – I shared out C:\VMs – creating the \\Hypernode1\VMs share
   
   
2. I granted rights on the share to the Hypernode2 system.  This can be a little tricky, since the “Select Users, Computers, Service Accounts, or Groups” dialog does default to searching for computers. 
   You have to remember to search for “Computer” objects rather than the typical Users or Groups.  You have to change the Object Types to easily find a system (shown below):
   
       
   
   
3. Once the “Object Types” are squared away, you can enter your host name, and grant it rights to the share: 
   
   
   
   
4. You will want to grant sufficient share permissions to the host as well – not just READ:
   
   
   
5. You will also need to ensure that the exporting host has sufficient NTFS permissions – changing the “Select” is again something to do.  The permissions I used are as follows:
   
   

Once I granted the exporting host rights to the share and the folder (NTFS), I was able to export my VM over the network in one step from Hypernode2, and then import the VM on Hypernode1:

Let me know if you have any questions or comment!

-John

I speak with lots of customers about virtualization every week.  I’m always interested in how they manage their virtual environment, and often dig into their operational procedures and practices.  I find that organizations who adopted virtualization earlier have not taken full advantage of the technology.  Backup and recovery is a great example of this. 

How do you backup and recover your virtualized servers?  Do you still leverage agents inside the VMs to a central backup infrastructure?  Lots of companies charged down the “virtualize to consolidate” path without altering their backup and recover processes.  Savings realized through server consolidation can be substantial, but by not updating their backup method, they miss out.  In the event a server (VM) needs to be restored for some reasons,  leveraging an agent-in-the-VM backup means the server (VM) must be rebuilt and then restored.

Why not take advantage of the encapsulation of server instances to improve disaster recovery?  VMs live in files, why not backup and restore the few number of files that represent a VM, rather than reconstruct all the files and settings contained in those files?

VMware offers VMware Consolidated Backup to backup a VMware host and the hosted / encapsulated virtual machines, but it is by no means a low cost backup solution.  It still requires a VMware 3rd party backup solution as well as the extra cost of  VMware’s tools (at least VI Foundation).  Even with all that, it’s not a simple process to get it working.  I know that some people believe that Microsoft licensing could be simpler, but personally I think VMware makes things as simple as licensing backup capabilities hard with statements like, “To leverage the new Consolidated Backup capabilities — and backup of all virtual machines running on an ESX Server host — a VCB license key must be available for each processor within that host. Refer to the Virtual Machine Backup Guide for a description of this feature." Leave me a comment if I’m off base about the cost and complexity of VMware Consolidated backup.

Enough about all the added cost and complexity of VMware…the important question is…did you know that everything you need to do a Hyper-V backup is included in Windows Server?  Did you know that there are at least two ways to make complete, consistent backups of VMs on Hyper-V that can be quickly and easily restored?  Over the coming weeks, I want to show you how to backup and recover Hyper-V VMs using the “stuff” that comes in the box with Windows Server 2008 R2 (and then talk about System Center Data Protection Manager and why you might want to check it out too).  I’ll break my posts into four areas:

• The Wonder of Volume Shadow Copy
• Backing Up Non-Windows – Wicked Coolness
• Using Windows Server Backup (WSB) for Hyper-V
• DiskShadow / Xcopy backup of Hyper-V
• System Center Data Protection Manager with Hyper-V
• Cool 3rd party tools for backup and recovery of Hyper-V

Be sure to stay “tuned in” to learn how to efficiently backup and recover Hyper-V.

-John

I mentioned in my last post the diskshadow command line tool that was introduced in Windows Server 2008.  Jose Barreto did a nice job over viewing the command in his blog, so I won't cover the same ground.  I’m going to walk you through how I use diskshadow to create a consistent, restorable, consolidated backup of Hyper-V and running VMs. 

Diskshadow is a tool to manage VSS that can run interactively or execute a predefined script.  For my tiny lab, I use a script so I can easily repeat the backup process.  To run a diskshadow script, call it like this:

diskshadow –s <scriptname>

The script can include all sorts of interesting VSS related stuff as well as external commands.  My basic script file is named HyperVBackup.txt, and looks something like this:

set context persistent
set metadata C:\backup.cab
set verbose on
begin backup
     add volume C: alias ConfigVolume
     #The GUID of the Hyper-V Writer
     writer verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
     create
     EXPOSE %ConfigVolume% Y:
EXEC HyperVBackup.cmd
     UNEXPOSE Y:
end backup   

You can dig around TechNet and MSDN for more details on what it all means (and what else you can do in a diskshadow script), but the key things to note are the housekeeping lines at the top and the backup section (between “begin backup” and “end backup”).  What’s going on in “backup” this part of the script is the step-by-step process for creating and exposing a VSS snapshot for a single drive system, as well as the kickoff of a backup (using Xcopy).  Once a  point-in-time snapshot of the C: drive is created, it is exposed as Y: so that files of interest can be copied off.  The contents of HyperVBackup.cmd (a batch file) are pretty tiny:

Xcopy y:\VMs\*.* g:\HyperVBackup\VMs\*.* /e /s /y /F /O /X /R /H
copy c:\Backup.cab g:\Hypervbackup

In the batchfile, I copy all of the VMs (their VHDs and configuration information which on this server lives in the C:\VMs directory) to an attached USB drive, as well as a copy of the metadata generated by diskshadow (contained in backup.cab).  Note all the switches for Xcopy – they are necessary to preserve the security and other attributes of the files for a successful restore.

If you store your VMs on another drive (other than C:) you would to add those additional volumes to the diskshadow script (via add volume and expose) as well as add another Xcopy to the batch file.

That’s pretty much it.  Just those two files (one text file and one short batch file) used by calling diskshadow and the running Hyper-V VMs are backed up using the tools included in Windows Server 2008 R2!  Here’s a few screen shots of the process running on a system in my lab, incase you are interested (I’ll show you what was going on with the VMs in a later post).

The bad news is that this process does not work with CSV volumes (I’m sure that question was going to come!). 
We’ll get to how to backup and restore R2 failover clusters in later posts.

While a simple backup is great, the IMPORTANT piece is restoring!  I’ll cover that in my next post.

-John

In my last post I showed you how to create a consistent backup of a Hyper-V host using the no additional cost Diskshadow command and an attached USB drive (in contrast to the costly VMware Consolidated Backup).  Now I want to show you how to restore the VMs that you backed up to a separate host (what good is a backup of you can’t restore it!).

To recover the data, we’ll simply reverse the process on another Hyper-V host.  I attached the USB disk used for backup to a different system, and invoked the diskshadow script below using the command diskshadow –s HyperVrestore.txt.  HyperVrestore.txt looks like this:

set context persistent
#the backup.cab file mentioned below is the one created during backup.
load metadata G:\Hypervbackup\backup.cab
set verbose on
begin restore
exec C:\HypervRestore.cmd
end restore

It’s similar the HyperVBackup.txt script, except that it reads the metadata from backup.cab and uses Xcopy (in HypervRestore.cmd) to copy the files from the USB drive (G:) to the local system:

Xcopy g:\HyperVBackup\VMs\*.* C:\VMs\*.* /e /s /y /F /O /X /R /H

The command window looks pretty similar to the one I showed you in the backup posting.

The net effect of the restore is the important part. 

On the source system, I had two running VMs (an instance of Hannah Montana Linux and a Windows Server 2003 VM):

Before I ran the diskshadow restore, Hyper-V manager on the "recovery” system only showed three VMs:

Once the restore process completed, the recover host showed all 5 VMs!

Let me know if you would like me to go into more complex recovery scenarios (like different drive letters or changed drive letters / directories).

In my next post, I’ll show you some of the detailed wicked coolness of backing up non-Windows VMs using the Hannah Montana Linux instance noted above.

-John

In the last few posts I showed you a simple (and low cost) manual method for back and recovery of virtual machines running on Hyper-V.  When I ran through the process in my lab, I purposely used two different types of virtual machines:

• one Windows VM with a VSS-aware OS and enabled integration services (Windows Server 2003)
• VM without VSS or integration services and absolutely no support from Microsoft (Hannah Montana Linux)
  

I mentioned in the VSS Overview post that contemporary versions of Windows running in a VM on Hyper-V that support VSS and have the appropriate Integration Services installed can coordinate VSS activities with many of the applications and services inside the VM when a backup request is made on the physical host.  This coordinated VSS processing via the Hyper-V Integration Services means that VSS aware applications can be backed up in a VM with absolutely no downtime. without installing an additional backup agent inside the VM (saving cost and reducing complexity).

For that other class of VMs, those that do not support VSS or do not have the “Backup” Integration Service enabled, Windows Server 2008 R2 and Hyper-V still can create a consistent backup, but the process is a little bit different.  If the VM (for whatever reason) cannot itself consume the coordinate VSS request, Hyper-V will save the state of the VM (hibernate it) copying the contents of memory to disk and then generate a snapshot of the disk housing the VM.  Here’s how the process looks to a running VM in this category:

1. Backup is requested, and a running VM is found on the host – say, like Hannah Montana Linux (or Windows 2000), which does not have VSS
   
   
2. Hyper-V and VSS figure out that Hannah Montana can’t consume the VSS  request, so the state of running VM is saved to disk into the directory which contains the VMs configuration file – this usually takes only a few seconds, but depends on the amount of memory used by the VM and the speed of the attached disk storage
   
   
3. Once the VM is completely stopped and the configuration saved, the VSS snapshot on the host can be created
   
   
4. After the snapshot is generated, the VM is restarted
   
   
5. The VM starts right back where it was, with only a brief “freeze” and “thaw’
   
   

Remember I did this entire process simply by requesting a backup of the physical Hyper-V host – I didn’t need to request all of this to happen Windows Server 2008 R2 / Hyper-V / VSS did it all for me!   Any VSS aware backup of Windows Server 2008 should be able to do the same thing for you, if you use diskshadow, Windows Server Backup (WSB – part of Windows Server 2008), or a more full featured enterprise backup solution. 

The key thing to note is that you can improve the backup and recovery of even unsupported operating systems running on Hyper-V.

-John

Microsoft introduced the Volume Shadow Copy Service (VSS) as part of Windows Server 2003. VSS lets you coordinate necessary actions to create a consistent point-in-time copy (also known as a shadow copy or snapshot) of data for backup purposes.  It allows you to create manual or automatic backup snapshots of data and coordinates with properly registered applications and services.  VSS can (for example) be used to take periodic, point in time snapshots of a file server to give remote users the ability to restore old copies of their files. 

To create a snapshot, a VSS requestor (backup utility) requests that an image be created.  The VSS provider (comes with Windows Server) coordinates with application specific VSS writers to coordinate and “freeze” application data for snap shot creation.  Microsoft SQL Server and Exchange have VSS writers, as do many of the service that ship with Windows Server (including Active Directory, DHCP,WMI, and lots of others).  

With Windows Server 2008, Microsoft included a VSS writer for Hyper-V which enables consistent snapshots to be created of VMs running on Hyper-V! 
Microsoft also added a new command line tool for administrators to manage this VSS process called DiskShadow (more on this cool command in a later post).

When a VSS aware backup utility requests a backup of a system running Hyper-V, the system coordinates with the a VMs to “quiesce” disk IO.  There are two ways that a VM can be consistently backed up Hyper-V depending on the VMs level of “integration” with the host. 

1. If a VM is running a VSS capable operating system (Server 2003 or newer), has Integration Services installed, and  has the “Backup” integration service enabled (default), then the request to snapshot will pass into the VM and cascade into a VSS request to “quiesce” apps in the VM.  In this case, a consistent snapshot can be created with NO downtime of the VM!
2. If a VM is not VSS capable (Windows 2000, Linux, UNIX), does not have Integration Services installed, or the “Backup” checkbox is not selected as part of it’s configuration, Hyper-V will briefly freeze the VM – pause execution and save the contents of VMs memory to disk. Once memory is saved, the snapshot will be created, and execution will resume.

Once the snapshot is generated, the consistent image of virtual machines and their configuration can be exposed to the requestor (the backup utility) and restorable data can be copied off for later use.  Keep in mind that all the storage for a VM using a host-base backup must be leveraging VHDs for storage (not pass-through disk or iSCSI), otherwise the host can’t take an image of the VMs.  The files and data that is captured can be used to quickly and easily restore the virtual machines and their configuration.

If you want more details of how VSS works with Hyper-V, check out MSDN.   In my next post, I’ll describe a simple backup process you can use that takes advantage of the diskshadow command line tool.

-John