Hyper-V backup support limitations

Because of the tight integration of Microsoft Failover Clustering with Cluster Shared Volumes and Hyper-V, the following limitations apply when you are using the backup-archive client.

Important: The following limitations apply only to Hyper-V backup and restore operations for Tivoli® Storage Manager configurations that do not have a license file for the Tivoli Storage Manager for Virtual Environments: Data Protection for Microsoft Hyper-V product installed. If you have that product and license installed, see the description of limitations at IBM Tivoli Storage Manager for Virtual Environments, Data Protection for Microsoft Hyper-V backup support limitations.

Microsoft Hyper-V support is provided for the following configurations:

A dedicated Hyper-V system
A Hyper-V configuration that is part of Microsoft Failover Clustering
A Hyper-V configuration that is part of Microsoft Failover Clustering with Cluster Shared Volumes

For Windows Server 2008, virtual machine backups can be performed only by a backup-archive client that is installed on the cluster node that is the current owner of the virtual machine. To see which virtual machines are owned by the node, select Server Manager > Roles > Hyper-V Manager. This restriction does not exist for Windows Server 2012 hosts.

For Windows Server 2008, a virtual machine should be restored only by a backup-archive client that is installed on the cluster node that is the current owner of the virtual machine. To determine the virtual machine configurations of the cluster, select Server Manager > Features > Failover Cluster Manager > cluster name > Services and Applications.. Use the Services and Applications window to change which node is the owner of the virtual machine before you restore it. This restriction does not exist for Windows Server 2012 hosts.

For Windows Server 2008, virtual machines that are currently owned by different nodes, and that have files on a common Cluster Shared Volume, cannot be simultaneously backed up, using the default system VSS provider. The second backup fails because the shared volume is owned by the first node. You can significantly reduce the amount of time that the first node owns the shared volume by using hardware snapshots through the VSS provider that is supplied by your storage hardware vendor. After the hardware snapshot is completed, the backup process can be initiated from the second node, therefore the backups can be running concurrently from both nodes. To determine which node owns the volume, select ServerManager > Features > Failover Cluster Manager > cluster name > Cluster Shared Volumes. The Cluster Shared Volume windows displays the status of the volume, including ownership, and if a backup is in progress (with redirected I/O enabled). This restriction does not exist for Windows Server 2012 hosts.

If your cluster environment typically has all of the virtual machines owned by a single node, and other nodes provide failover support only, the following applies:

Consider setting CLUSTERNODE YES for backups from the active node and restore to failover nodes (if needed).
Consider running the client scheduler as a failover service to periodically back up all virtual machines. For example: dsmc backup vm * -vmbackuptype=hypervfull. A failover starts the scheduler on the failover node.

If your cluster environment typically has some virtual machines that are owned by one node, and other virtual machines that are owned by other nodes, the following applies:

Consider using the Asnodename option to allow for backup from multiple nodes and restore to failover nodes (if needed).
Consider running the client scheduler as active on each node to periodically back up the virtual machines that are owned by each node. The schedules must be defined with non-overlapping start times to avoid contention for common shared volumes. If the scheduler on each node backs up with -vmlist=*, there is no need for the scheduler service to failover since the scheduler service on the other node will automatically pick up nodes that move over on the next backup.