Windows Virtualization Team Blog : VSS

Guest Post: All Eyes on SteelEye with DataKeeper Support for Hyper-V

porourke — Thu, 20 Aug 2009 07:10:00 GMT

Hi all,

My name is Dave Bermingham and I’m the director of Windows product management for SteelEye Technology, a provider of business continuity and disaster recovery solutions. I’d like to thank Microsoft’s Virtualization team for the opportunity to guest blog on SteelEye’s continued support for Hyper-V as well as exciting new features coming in support of Hyper-V on Windows Server 2008 R2.

I can’t believe it is almost a year ago since I demonstrated SteelEye DataKeeper Cluster Edition at the Microsoft Virtualization Launch event in Bellevue, WA. In the past year we have seen the interest in our Hyper-V disaster recovery products increase dramatically and with the recent release of Windows Server 2008 R2, I believe we have just seen the tip of the iceberg!

SteelEye’s mission is to “Replicate Any Data, Protect Any Application.” We pride ourselves on our commitment to provide the Windows marketplace with flexible, scalable and cost-effective solutions that are enterprise-grade yet customizable for any size business. Most recently SteelEye identified an opportunity to extend Microsoft’s Windows Server 2008 Failover Clustering (WSFC) by delivering SteelEye DataKeeper Cluster Edition, a real-time data replication solution that integrates seamlessly with WSFC to enable multi-site clusters while eliminating the single point of failure traditionally associated with shared storage resources. A comprehensive and cost-effective disaster recovery solution, DataKeeper Cluster Edition helps supports improved productivity and availability of your Hyper-V VMs.

SteelEye soon will be announcing support for Windows Server 2008 R2 and the highly anticipated “Live Migration”. As our Windows team continues to develop and build additional capabilities for enhanced disaster recovery support of Hyper-V, we welcome your comments and suggestions. To learn more about the latest developments for Hyper-V support, take a look at our FAQs or visit the SteelEye DataKeeper Cluster Edition page on our website.

Thanks,

Dave

Re: Windows Server 2008 SP2 Hyper-V

porourke — Wed, 17 Jun 2009 19:51:00 GMT

Hi Isaac Roybal here. I’m a technical product manager on the Windows Server team covering Hyper-V.

It’s been 3 weeks since the release of Windows Server 2008 Service Pack 2 (SP2) and we’re seeing great adoption. From a Hyper-V point of view, we’re excited because the final Hyper-V release is an integrated feature in SP2 making it easier and faster to deploy Hyper-V. If you recall, when Windows Server 2008 was released, Hyper-V Beta was included. This meant to get the final Hyper-V release, you needed to go to Windows Update, download and go through the update process.

With Windows Server 2008 SP2, Hyper-V final bits are included so there’s no need to pull down individual downloads which speeds up deployments. There are also some notable updates in SP2, including scalability enhancements for running on systems with up to 24 logical processors which enables support for up to 192 running virtual machines, update for Hyper-V when managed with System Center Virtual Machine Manager 2008 and updates for backup/restore of virtual machines with the Volume Shadow Copy Service (VSS).

For those of you who have already deployed Hyper-V, SP2 is a simple upgrade. Here are a couple of top-of-mind things to think about when you’re planning your upgrade or fresh install of SP2:

· In-place upgrades of Windows Server 2008 to Windows Server 2008 SP2 is supported for both the parent partition and child VMs.

o If the Hyper-V role was enabled on the parent partition prior to the upgrade to SP2, it will be automatically enabled once the upgrade is completed.

o Uninstall any prerelease versions of SP2 that might be installed.

· If a fresh SP2 install is being done and you’d like to move VMs to it, export the VMs from the originating Windows Server 2008 host and import them on the SP2 host.

· Integration Components (ICs) for the child virtual machines must be updated to the SP2 version.

o If you’re doing a fresh install or an upgrade of SP2 on the parent partition, it does not update the integration components inside the virtual machine. Be sure to update the VM ICs after SP2 is installed.

o If you have virtual machines created on the Beta version of the Windows Server 2008 Hyper-V role, and you installed the Beta version of the integration components on those machines, you must uninstall the integration components and reinstall the latest SP2 integration components.

o When upgrading to SP2 inside a Windows Server 2008 child VM the ICs are automatically upgraded.

o If you are running a supported Windows operating system other than Windows Server 2008 as a VM, you need to use vmguest.iso to upgrade the integration components

Isaac

UPDATE. Responding to question by Ed051042

Yes, your assertion is correct. Follow these steps when upgrading a cluster to SP2:

1. Evacuate the cluster node of VMs via quick migration (assuming you’ve extra capacity) to other nodes in the cluster.

2. Upgrade the node to SP2 while it is still part of the cluster

3. Once the SP2 install is complete, quick migrate those VMs back to node and update VMs’ ICs. The last bit is important.

4. Follow the same process starting step #1 until entire cluster had been updated to SP2

For more info see KB 174799 which outlines how to install SPs on a cluster and Microsoft's Failover and Network Load Balancing Clustering Team Blog which explains a rolling upgrade of a cluster.

Trying to achieve granularity of backups with the Hyper-V VSS Writer

SoumyaDB — Mon, 09 Mar 2009 08:36:00 GMT

Another area of feedback on the Hyper-V VSS Writer is that it does not give much by way of granularity beyond the level of the virtual machine. As a result of that, backup applications are stuck to backing up the entire VHD file, which could easily end up being a rather onerous process, expesially if the administrator is backing up to a separate DR site.

To work around this, backup vendors have been looking into solutions for browsing/indexing the files in the in the VHD file. In general, the user can mount the VHD as another drive on the host and browse its file system. The way to do this is not available via the UI in Windows Server 2008 Hyper-V, but is available via the WMI API. Ben Armstrong has a blog post on doing that via vbscript/powershell over here. Given this avenue, the first approach is to follow the following steps:

1. Create VSS snapshot of that involves the VM

2. Mount the VSS snapshot as a volume on the host

3. Get the VHD residing in the VSS snapshot

4. Mount the VHD as drive on the physical machine

5. Go to town on the files residing in the VHD.

Problem with the steps above is that #4 fails due to the fact that the snapshot volume is a read-only volume and the WMI API for mounting VHDs tries to mount it in RW mode. So, we add a step 3a to the sequence and modify step 4 slightly. Here is the updated sequence:

1. Create VSS snapshot of that involves the VM

2. Mount the snapshot as a volume on the host

3. Get the VHD residing in the VSS snapshot

3a. Create a differencing disk on a physical volume with the VHD in the VSS snapshot as the parent disk

4. Mount the VHD created above as drive on the physical machine

5. Go to town on the files residing in the VHD.

since the differencing disk sits on a RW volume, the Mount API will succeed, while keeping the VHD in the snapshot unaffected. The backup application can now browse/index the files inside volume residing in the VHD at will and allow for a more granular and thus optimized backup experience for the user.

There are some important caveats to keep in mind about this approach:

1. While this approach allows for granular backup of specific files inside a virtual machine, the onus for ensuring the right files are available upon restore rests on the backup application as well. So, the backup application will need to do a similar process of mounting the VHD and copying down the right files during the restore process.

2. If the virtual machine in question has snapshots, this approach is not possible in v1 it is not possible for a user or a third-party application to create a differencing disk off a snapshot VHD file (ie: a .avhd file). If the virtual machine has snapshots, the backup application will need to copy the VHD and avhd files to RW media before mounting the avhd files in the physical machine. Additionally, the backup application will need to know the latest snapshot in the snapshot tree.

3. In Windows Server 2008 R2, VHD files can be mounted in RO mode using the native disk management APIs. Thus, there is no need to create differencing disks anymore and the VHDs (as well as AVHDs) can be mounted directly from the snapshot volume.

Working around the pass through limitations of the Hyper-V VSS Writer

SoumyaDB — Tue, 03 Mar 2009 22:53:00 GMT

While the Hyper-V VSS writer provides backup admins significant flexibility in their ability to back up VMs in an application-consistent way while running backup applications in the physical machine, it does have a prominent limitation when it comes to VMs with pass-through storage. The VSS Writer excludes pass-through storage from the set of items to be backed up for a VM. Here I am using the term “pass-through” rather loosely, to include local storage which may be configured directly on the virtual machine (which may be iSCSI initiated from the physical machine or FC attached to the physical machine) as well as iSCSI targets that are initiated directly from the guest. Technical issues due to the way we create VSS snapshots as well as challenges while doing the restore operation has kept us from providing this functionality so far. I will not, however, belabor the reader with the details of the technical challenges. Instead, let us look at ways to work around this limitation.

Approach 1: run backup in guest and backup in host

One approach is to run backup applications within the virtual machine along with a backup application in the host. The backup application running in the virtual machine will capture the data residing on the pass through disk while the host side backup application will capture the VHDs and configuration files associated with the VM. The user would then need to run the backup in the virtual machine followed by backup in the host. During the restore process, the reverse process is followed: restore the host-side files and then run the restore inside the virtual machine after booting it up.

There are a two problems with this approach. Firstly, having to orchestrate the backup process within the virtual machine with the backup process in the host and doing something similar during restore is going to be challenging for any management entity; be it an IT admin or a management application. Secondly, there is an additional limitation for pass-through disks which are connected to the host via FC: The value-added storage management functionality provided by the storage manufacturer (for example, hardware VSS snapshots) is filtered out from the VM due to the fact that the Hyper-V storage stack filters out custom CDBs. These two combine to make this workaround rather unattractive.

Approach 2: Fixed size VHDs

At this point, let us take a moment to look at the motivation behind using pass-through disks for virtual machines. The first reason, stated by many is the enhanced performance available through the use of pass-through storage. The second reason is the ability to use the advanced management capabilities provided by the storage providers for backing up LUNs (iSCSI or FC).

Now, in Windows Server 2008 R2, the performance difference between VHD-based storage and pass-through storage has been reduced a lot. This is particularly true for fixed-size VHDs. In our internal perf labs, we have had test runs where the performance of fixed size VHDs actually matched the performance of pass-through disks. Even in v1, the performance of fixed disks was pretty close to that of pass-through disks. So, instead of configuring the LUN as a pass-through device on the virtual machine, the user could make the LUN online on the physical machine. The user could then create a fixed size VHD that occupies the entire space of the LUN and configure the virtual machine to connect to that VHD. Since the LUN is exposed to the physical machine, the management capabilities provided by the storage provider (e.g: hardware VSS snapshots) are available to be used. In this configuration, the user then does not need to run any backup application inside the virtual machine, as none of the volumes in the virtual machine (by virtue of being backed by VHDs) are excluded from the backup. Additionally, the hardware VSS snapshots and LUN management capabilities provided by the storage manufacturer can be leveraged entirely from the host.