A Hyper-V update rollup package is available for Windows Server 2008 R2

Several issues around VSS based protection & recovery are being addressed with this Hyper-V update rollup package. The package can be downloaded from:

The last three issues might sound familiar if you already perform host level protection of virtual machines on Cluster Shared Volumes (CSV) with Microsoft System Center Data Protection Manager 2010.

Issues that are fixed in this update rollup package

Issue 1
Consider the following scenario:

  • Some Internet SCSI (iSCSI) connections are created in a virtual machine that is running Windows Server 2003.
  • You back up this virtual machine on the virtual machine host server.

In this scenario, the error code 0x800423f4 occurs when you back up the virtual machine. Additionally, the following event is logged into the Hyper-V Virtual Machine Management Service event log:

The number of reverted volumes does not match the number of volumes in the snapshot set for virtual machine "’virtual machine name’ (Virtual machine ID <GUID>)".

Cause of Issue 1
When a virtual machine is being backed up, the VSS writer of the server that is running Hyper-V makes a call to the guest virtual machine to check whether any iSCSI connections exists. This call has a default time-out of 60 seconds. If this call does not return within the time limitation, the VSS writer of the server that is running Hyper-V incorrectly assumes that there is no iSCSI connection. Therefore, the backup operation fails.

Issue 2
Consider the following scenario:

  • Cluster shared volumes are enabled on a failover cluster for Hyper-V.
  • Some virtual machines are saved on the same volume. But they are running on different nodes.
  • These virtual machines are backed up in parallel.

In this scenario, the virtual machine backup operation fails.

Cause of Issue 2
When the virtual machines on different nodes are backed up in parallel, every node waits to become the cluster shared volume owner to create the snapshots. However, the Cluster service moves the volume owner from one node to another node immediately after a snapshot is created without waiting for post-snapshot tasks to be completed. If another node requests the same shared volume for a backup operation before the post-snapshot tasks are completed, the Cluster service changes the volume to another node. Therefore, the VSS writer that is in the previous node cannot find the cluster shared volume locally when it performs post-snapshot tasks. This behavior causes the virtual machine backup operation to fail.

Issue 3
Consider the following scenario:

  • A virtual machine is being backed up on a server that is running Hyper-V.
  • At the same time, an application backup operation is being performed in the same virtual machine.

In this scenario, some data is truncated from the application backup in the virtual machine. Therefore, this behavior causes data loss.

Cause of Issue 3
The application backup operation in the virtual machine is incorrectly affected by the virtual machine backup operation on the server that is running Hyper-V.

Issue 4
Consider the following scenario:

  • A virtual machine that has some snapshots is backed up on a server that is running Hyper-V.
  • Then, this virtual machine is restored to another location.

In this scenario, the restore operation fails and the virtual machine may be corrupted.

Cause of Issue 4
The snapshot files are not restored successfully when you restore the virtual machine.


Full details: http://support.microsoft.com/kb/975354

Leave a Reply

Your email address will not be published. Required fields are marked *

Our Sponsors

Powered by