Redpaper
Alex Osuna
Ravi B
Kyle Burrell
Amrita Das
Luiz Paulo Moreira
SnapManager 1.0 for Hyper-V
Backups, restores, and disaster recovery can place a huge overhead on the
Hyper-V virtual infrastructure. SnapManager for Hyper-V simplifies and
automates the backup process by leveraging the underlying N series Snapshot
and SnapRestore technologies to provide fast, space-efficient, disk-based
backups and rapid, granular restore and recovery of virtual machines (VMs) and
the associated data sets. This document details the recommendations for
deploying and using SnapManager 1.0 for Hyper-V.
With the adoption of virtualization technologies, data centers have been
transformed, and the number of physical servers drastically reduced.
Virtualization has had many positive effects, not only reducing the number of
physical systems, but also reducing network, power, and administrative overhead.
In contrast to physical environments, where server resources are underutilized,
fewer resources are available in virtualized environments. Where each physical
server had dedicated network and CPU resources, virtual machines (VMs) must
now share those same resources, which can result in performance issues,
especially while backing up the virtual environment, as many VMs utilize host
network and CPU resources concurrently. As a result, backups that once
completed during non-business hours have seen their backup window grow.
SnapManager for Hyper-V (SMHV) addresses the resource utilization issue
typically found within virtual environments by leveraging the underlying N series
Snapshot technology, thereby reducing the CPU and network load on the host
platforms and drastically reducing the time required for backups to complete.
© Copyright IBM Corp. 2011. All rights reserved.
ibm.com/redbooks
1
SMHV can be quickly installed and configured for use in Hyper-V environments,
saving valuable time during backups and allowing quick and efficient
restorations, thus reducing administrative overhead.
This IBM® Redpaper™ provides recommendations for deploying SMHV to back
up and recover Hyper-V VMs. It describes the key features and
recommendations for effectively managing the complete backup life cycle for
Hyper-V VMs. This document is intended for Hyper-V administrators, storage
administrators, backup administrators, and architects implementing a backup,
restore, and disaster recovery solution for Hyper-V environments running on
N series storage. For detailed instructions about installation and configuration,
refer to the SnapManager for Hyper-V Installation and Administration Guide
available on the IBM Storage support website:
http://www.ibm.com/storage/support/nas
SnapManager 1.0 For Hyper-v
This section provides information about how SnapManager for Hyper-V can be
useful for system administrators.
Technical details
Note the following technical details about SnapManager 1.0 For Hyper-v:
򐂰 It allows system administrators to create hardware-assisted backup and
restore of Hyper-V VMs running on IBM N series storage.
򐂰 It provides integration with Microsoft Hyper-V Volume Shadow Copy Service
(VSS) writer to quiesce the Hyper-V VMs before creating an
application-consistent Snapshot copy of the VM.
򐂰 It allows an administrator to create application-consistent backups of Hyper-V
VMs if the customer has Microsoft Exchange, Microsoft SQL Server, or any
other VSS-aware application running on virtual hard disks (VHDs) in the VM.
򐂰 It provides mirroring of backup sets to secondary locations for disaster
recovery (DR) planning.
򐂰 It supports the back up and restore of shared VMs configured using Windows
Failover clustering (WFC) for high availability and also on Microsoft cluster
shared volumes (CSVs). SMHV makes sure that the scheduled VM backups
can happen seamlessly irrespective of any VM failovers.
򐂰 It supports management of multiple remote Hyper-V parent systems from
one console.
2
SnapManager 1.0 for Hyper-V
Figure 1 shows the SnapManager for Hyper-V.
Figure 1 SnapManager for Hyper-V
Planning
Microsoft Windows 2008 Server R2 with Hyper-V role enabled offers various
storage infrastructure configurations and provisioning methods.
Storage configuration
Infrastructure virtualized with Microsoft Hyper-V offers support for the use of
either direct-attached storage (DAS) connected through FC/iSCSI or shared
storage connected to the Windows 2008 R2 Server. However, the
high-availability and disaster recovery features of Hyper-V integrated with
Windows Failover Cluster (WFC) are only available on shared storage.
SnapManager 1.0 for Hyper-V
3
Shared storage
The traditional shared storage is a LUN provisioned from an IBM N series
storage system connected to multiple Hyper-V server nodes, which are a part of
a single WFC. However, out of these nodes, only one Hyper-V server can
perform read and write operations on the shared storage disk. This implies that
when a VM is migrated from one Hyper-V host to another in a WFC (using Live
Migration or Quick Migration), read/write access to the LUN with VM is
transferred to the Hyper-V destination host. A consequence of this is that VM
migration moves all VMs that reside on that LUN to the destination Hyper-V host,
because that is the only host with read/write access to that LUN. To achieve
granular migration of VMs, each LUN can only contain a single VM.
Recommendation
The recommendation while deploying Hyper-V on traditional shared LUNs is to
have one VM per LUN configured. All the VHDs relative to a single VM (VM
with multiple drives) can reside on a single LUN provisioned as a shared storage
to a WFC. Figure 2 shows exclusive read/write access to owned LUNS when
using Hyper-V.
Figure 2 Exclusive read/write access to owned LUNS when using Hyper-V
Cluster Shared Volumes
A Cluster Shared Volume (CSV) is a physical disk that is a shared LUN that is
accessible to multiple Hyper-V hosts, which are a part of a single WFC that can
be written to and read from by these host nodes simultaneously. This is a
clustering feature available to users from Windows Server 2008 R2, which is
supported only for the Hyper-V role. CSVs can be created using the Cluster
4
SnapManager 1.0 for Hyper-V
Manager User interface and from the shared disks provisioned from a IBM N
series storage system.
CSVs were primarily introduced to serve as a clustered file system so that the
available nodes within a cluster could perform read-write operations
concurrently. Hence, CSV configuration within a Hyper-V environment can be
used to set up highly available VMs using the live migration feature. However,
configuring CSV is not mandatory to set up live migration because the traditional
shared storage can also be used to achieve the objective. In such a case, you
must adhere to the Microsoft recommendation of maintaining a one-to-one
mapping of VMs to shared storage.
Storage layout
You must plan and consider the storage requirements for Virtual Machines in
Microsoft Hyper-V environments ahead of the storage provisioning activities. The
data drives of the virtual machines hosted on a Hyper-V server can reside on
virtual hard disks (VHD files), pass-through disks, or directly attached LUNs
using the Microsoft iSCSI software initiator in the VMs. Regardless of the storage
option, the VM’s disks are formatted with the file system native to the guest OS.
Virtual hard disk files
VHDs are a commonly used storage option for VM configurations. With VHDs,
the actual data of the VM is kept within a VHD file stored on a LUN formatted with
NTFS, which is connected to the Hyper-V host system. The LUNs can be
accessed over Fibre Channel or iSCSI. Hyper-V supports three types of VHDs:
򐂰 Fixed-size
򐂰 Dynamically expanding
򐂰 Differencing VHDs
Fixed-size VHD
In this type of VHD, the entire amount of storage space configured for the Virtual
Machine is pre-allocated. Therefore, the file does not expand while the VM is
under operation. Out of the available VHD types, fixed-size has the least
performance overhead. For production environments, this type of VHD is most
recommended.
Dynamically expanding VHD
As the name indicates, this type of VHD expands while the VM is in operation as
the data gets populated. The VHD expands to the maximum configuration size
defined during the VHD creation. Because dynamic expansion of the disk occurs
while the VM is under active I/O, this type of VHD has the highest performance
SnapManager 1.0 for Hyper-V
5
overhead. This type of VHD residing on an N series LUN is mostly suited for a
test and development environment wherein the disk performance is not critical.
Differencing VHD
Differencing VHDs are created as part of the Hyper-V snapshot process (which is
not the same as N series Snapshot technology). Differencing VHDs function very
similar to the Dynamically Expanding VHD and point to a parent VHD that can be
of any type (fixed or dynamically expanding). The performance impact of this
type of VHD is similar to that of dynamically expanding, and therefore must follow
the same recommendations when used.
Pass-through disks
Pass-through disks are physical disks presented to the Hyper-V host that are
directly attached to the guest OS as raw disks. These raw disks are formatted
with the guest OS file system. This disk type is used in case of large data sets
and intense I/O requirements.
Directly attached storage to the guest OS
In this method, the LUN is directly attached using the initiator software from the
guest OS and is formatted with the guest OS file system. These LUNs can only
be data drives, as Microsoft does not support booting a guest OS over an iSCSI
LUN for Hyper-V.
Tip: SMHV can only back up VM data stored in VHDs that reside on IBM N
series storage. It does not back up data on pass-through or direct attached
iSCSI Disks. SMHV does not support MBR LUNs for VMs running on shared
volumes or CSVs.
6
SnapManager 1.0 for Hyper-V
Thin provisioning
The typical storage provisioning practices followed by most of the storage
administrators is to pre-allocate the disk space requested by the user. N series
software solutions facilitate the feature of storage virtualization where the
administrators can over commit on the space allocated to the users (Example 1).
This method, referred to as thin provisioning, allows users to utilize storage on
demand. Here the available storage resources are treated as a single shared
resource pool, and the consumption is accounted as it gets utilized. SMHV
supports LUNs created on flexible volumes and performs backups and restores
on these volumes.
Example 1 Thin provisioning over commitment
'Alexvol2' has size 120g.
'FlexVol2' has size 100g.
'itso' has size 500g.
'itso2_sm' has size 25g.
'mrstorage' has size 100g.
'pl_install' has size 200g.
'res_install' has size 150g.
'vmware' has size 100g.
'FlexVol3' has size 400g.
itsotuc4> df -g -A itso
Aggregate
total
itso
1135GB
itso/.snapshot
59GB
used
953GB
0GB
avail capacity
181GB
84%
59GB
1%
Deduplication
Data deduplication is one of the flagship features of IBM N series storage
systems and helps eliminate duplicate data at the block level in the environment
deployed on Hyper-V. This feature can be introduced in the storage systems
without affecting the administration practices or tasks from the Hyper-V server
end. Deduplication runs on the storage system at scheduled intervals without
affecting the resources of the server hardware. Infrastructure that uses fixed-size
VHDs and multiple VMs created out of a single VHD golden copy for a VDI
environment can take advantage of the deduplication feature to achieve effective
storage utilization.
For further information, refer to the IBM System Storage N series A-SIS
Deduplication, SG24-7709, available at:
http://www.redbooks.ibm.com
SnapManager 1.0 for Hyper-V
7
SMHV simplifies backup and recovery
SnapManager for Hyper-V automates and simplifies backup and restore
operations for Microsoft Windows Server 2008 R2 Hyper-V environments hosted
on N series storage. This management tool enables you to leverage N series
snapshot and replication technology for instant application-consistent backups
and cost-effective DR.
Prerequisites
SnapManager 1.0 for Hyper-V needs SnapDrive 6.2 or later for Windows (SDW)
to be installed as a prerequisite. SnapDrive manages LUNs on a storage system,
making these LUNs available as local disks on Windows Hyper-V hosts. This
allows Windows hosts to interact with the LUNs just as though they belonged to a
directly attached redundant array of independent disks (RAID).
Information SDW is required on Hyper-V parent hosts, but is not required on
client hosts. For WFC configurations, SDW and SMHV have to be installed on
each node of the cluster.
Terminology datasets
A dataset is a grouping of virtual machines that helps you to protect data using
retention, scheduling, and replication policies. You can use datasets to group
VMs that have the same protection requirements. A VM could be a member of
multiple datasets. This can be useful for VMs that belong to multiple groupings.
For example, a VM running the SQL Server instance for a Microsoft Office
SharePoint Server configuration might need to belong to both the SQL Server
and MOSS datasets.
Protection policies
Policies allow customers to:
򐂰 Schedule/automate the backups of the datasets at a predefined time
(schedule policy).
򐂰 Provide retention capabilities for older backups (retention policy).
򐂰 Replicate the block changes to the SnapMirror destination volume after the
VM backup is created (replication policy).
Policy includes other capabilities that allow customers to run scripts before and
after the backup.
8
SnapManager 1.0 for Hyper-V
Backup and recovery
SMHV provides local backup and recovery capability with the option to replicate
backups to a remote storage system using SnapMirror relationships.
Backups are performed on the entire dataset, which is a logical collection of
VMs, with the option of updating the SnapMirror relationship as part of the
backup on a per job basis. Similarly, restores can be performed at an individual
VM level.
Backup retention policy
Retention policies can be used to specify how long you want to keep a dataset
backup based on either time or number of backups. Policies can be created
specifying the retention period, allowing administrators the flexibility to meet
varying service-level agreement (SLA) levels within their environment.
Alert notification
Alert notifications are created on a per scheduled backup job basis and are sent
by e-mail to administrator-defined accounts. Alert notification can be configured
to e-mail the specified account after every backup, although this is not
recommended as the number of e-mails can become unmanageable.
Configuring alerts to notify administrators after an error or warning within a
backup offers a more useful and practical alert level.
Unprotected resources
Unprotected resources are VMs that are not part of any dataset. These
resources can be protected by adding them to a dataset.
Port usage
For SMHV and SDW, make sure that the following ports are kept open:
򐂰 SMHV, port 808
򐂰 SDW, default port 4094
򐂰 If SDW is configured to use HTTP protocol, port 4095
Tip: When installing SMHV on a cluster, the same port number must be used
across all nodes.
SnapManager 1.0 for Hyper-V
9
You can use the netstat command at the command prompt to verify that ports
are open. After SMHV and SDW installation completes, run netstat -a and
check the results (Example 2).
Example 2 Opened TCP ports at SMHV server
C:\>netstat -a
Active Connections
Proto
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
TCP
10
Local Address
0.0.0.0:135
0.0.0.0:445
0.0.0.0:808
0.0.0.0:902
0.0.0.0:912
0.0.0.0:2638
0.0.0.0:3306
0.0.0.0:3389
0.0.0.0:4094
0.0.0.0:4095
0.0.0.0:4319
0.0.0.0:5357
0.0.0.0:8009
SnapManager 1.0 for Hyper-V
Foreign Address
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
WIN-OZI5BOZ5IEJ:0
State
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
LISTENING
Architecture
Figure 3 illustrates the SMHV architecture and the components that work
together to provide a comprehensive and powerful backup and recovery solution
for Hyper-V environments.
POLICIES
Figure 3 SMHV architecture
Components
This section discusses the items required for building a virtual machine
environment with SMHV.
License requirements
A SnapManager for Hyper-V license is required on the Windows host system.
Choose either host-based licensing or storage system licensing:
򐂰 If you select host-based licensing, you need to provide a license key during
installation. You can change the license key after installation by clicking
License settings in the SnapManager for Hyper-V Welcome window.
򐂰 If you select storage system licensing, you must add the SMHV license to all
storage systems. SnapManager 1.0 for Hyper-V. Example 3 shows how to
add a SnapManager for Hyper-V license at the system storage.
Example 3 Adding SnapManager for Hyper-V at system storage
itsotuc4> license add IZXBHDG
A snapmanager_hyperv 90 day site license has been installed.
SnapManager 1.0 for Hyper-V
11
Ensure SnapManager for Hyper-V is installed on the Hyper-V
Server.
itsotuc4> Fri Mar 18 11:02:58 MST [rc:notice]: snapmanager_hyperv
licensed
itsotuc4> license
a_sis
cifs
cluster
cluster_remote
compression
disk_sanitization
fcp
flash_cache
flex_clone
flex_scale
flexcache_nfs
gateway
gateway_hitachi
http
iscsi
multistore
nearstore_option
nfs
operations_manager
protection_manager
provisioning_manager
smdomino
smsql
snapdrive_unix
snapdrive_windows
snaplock
snaplock_enterprise
snapmanager_hyperv
snapmanager_oracle
snapmanager_sap
snapmanager_sharepoint
snapmanagerexchange
snapmirror
snapmirror_sync
snapmover
snaprestore
snapvalidator
sv_applications_pri
sv_exchange_pri
12
SnapManager 1.0 for Hyper-V
ITSOTUC
site ITSOTUC
not licensed
not licensed
not licensed
not licensed
site ITSOTUC
not licensed
site ITSOTUC
not licensed
not licensed
not licensed
not licensed
not licensed
site ITSOTUC
not licensed
ITSOTUC
ITSOTUC
not licensed
not licensed
not licensed
not licensed
not licensed
not licensed
not licensed
not licensed
not licensed
site ITSOTUC
not licensed
not licensed
not licensed
not licensed
site ITSOTUC
not licensed
not licensed
not licensed
not licensed
not licensed
not licensed
sv_linux_pri
sv_marketing_pri
sv_ontap_pri
sv_ontap_sec
sv_oracle_pri
sv_sharepoint_pri
sv_sql_pri
sv_unix_pri
sv_vi_pri
sv_vmware_pri
sv_windows_ofm_pri
sv_windows_pri
syncmirror_local
vld
itsotuc4>
not
not
not
not
not
not
not
not
not
not
not
not
not
not
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
licensed
In Example 3 on page 11, an evaluation license was used. Remember that you
must have a valid license for SnapManager when installing it in a production
environment.
IBM Data ONTAP
SMHV will only function within a IBM N series storage environment. SMHV
requires that the primary storage, where the VMs actually reside, and the
secondary storage used as the SnapMirror destination run the Data ONTAP
storage software.
Table 1 lists the licensing and ONTAP versions.
Table 1 Licensing and ONTAP versions
If you use
Then use Data ONTAP Version
Host-based licensing
7.3.1P1 or later
Storage system licensing
7.3.2 or later
Storage system licensing with vFiler
7.3.1.1 P8, 7.3.2P1, or later
For the most current information, see the N series Interoperability Matrix Tool
(IMT) at:
http://www-03.ibm.com/systems/storage/network/interophome.html
In addition, the following licenses are required:
򐂰 SnapRestore
򐂰 The required protocol license (FCP, iSCSI)
SnapManager 1.0 for Hyper-V
13
򐂰 SnapMirror (if required)
򐂰 SnapDrive 6.2 or later for Windows (needs to be licensed on the
Hyper-V host)
SnapManager for Hyper-v supported configurations
SMHV must run on Windows Server 2008 R2 x64.
Platform support
The following platforms are supported for SMHV:
򐂰 Windows Server 2008 R2 x64 Standard, Data Center, and Enterprise Editions
(full and core installation)
򐂰 Hyper-V Server 2008 R2 x64
Remote Management Platform Support
The following remote platforms are supported for SMHV:
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
򐂰
Windows Server 2008 x64 Standard and Enterprise (full installation)
Windows Server 2008 x64 Standard and Enterprise with SP2 (full installation)
Windows Server 2008 R2 x64 Standard and Enterprise (full installation)
Hyper-V Server 2008 R2 x64 (full and core installation)
Windows Vista x64 SP1: Windows Vista x86 SP1 and later
Windows XP x86 with SP3 and later
Windows Server 2003 x64 and x86 with SP2 and later
VM support
The following VMs are supported for SMHV:
򐂰 Windows Server 2008 R2 (VM configured with 1, 2, or 4 virtual processors)
򐂰 Windows Server 2008 x64 Edition (VM configured with 1, 2, or 4
virtual processors)
򐂰 Windows Server 2008 x86 (VM configured with 1, 2, or 4 virtual processors)
򐂰 Windows Server 2003 x86 (VM configured with 1 or 2 virtual processors)
򐂰 Windows Server 2003 R2 x86 (VM configured with 1 or 2 virtual processors)
򐂰 Windows Server 2003 R2 x64 (VM configured with 1 or 2 virtual processors)
򐂰 Windows Server 2003 x64 Edition (VM configured with 1 or 2
virtual processors)
򐂰 Windows Server 2000 (VM configured with one virtual processor)
򐂰 Linux Distributions (VM configured with one virtual processor)
14
SnapManager 1.0 for Hyper-V
For the most current information, see the N series interoperability matrix at:
http://www-03.ibm.com/systems/storage/network/interophome.html
SnapManager for Hyper-v Snapinfo settings
The SMHV SnapInfo folder stores backup metadata. This can be set up by
specifying the SnapInfo settings in the Hosts Management wizard. The metadata
information is critical to recovering VMs if a failure occurs. SnapInfo settings
must be configured for the host or cluster added to SMHV so that VMs within that
host can be added to a dataset. Figure 4 shows how to start the Configuration
Wizard.
Figure 4 SnapManager for Hyper-V - Starting Configuration Wizard
The SnapInfo path must reside on a Data ONTAP LUN. For managing dedicated
VMs, the SnapInfo location needs to be a dedicated Data ONTAP LUN. For
managing shared VMs, the SnapInfo location needs to be to a shared Data
ONTAP LUN. The SnapInfo path must not reside on a CSV.
SnapManager 1.0 for Hyper-V
15
Figure 5 shows how to enter the SnapInfo folder path. The SnapInfo folder was
created in a Data ONTAP LUN from an N series device.
Figure 5 Configuring SnapInfo folder
If SnapInfo settings are changed you need to manually move all files from the
original SnapInfo location to the new location. SnapManager for Hyper-V does
not move them automatically.
Recommendation: IBM recommends having the SnapInfo LUN on a volume of
its own.
SnapManager For Hyper-v Report Settings
Report settings must be configured for a host or cluster added to SMHV so that
VMs within that host can be added to a dataset. The report path must not reside
on a CSV.
SnapManager for Hyper-V event notifications
the event notifications setting can be configured to send e-mail and AutoSupport
messages in case an event occurs.
16
SnapManager 1.0 for Hyper-V
The SMHV process flow
This section describes the backup and restore process flow on SMHV and
provides recommendations for adding VMs to the dataset and managing hosts
on SMHV.
Adding a Hyper-V parent host or host cluster
If you add a single host, SMHV manages the dedicated VMs on that host. If you
add a host cluster, SMHV manages the shared VMs on the host cluster. If you
plan to add a host cluster, SMHV must be installed on each cluster node.
If the backup repository settings, report directory settings, and notification
settings are not configured for SMHV, you can configure them after you add the
host, using the Configuration wizard. You must configure the backup repository
and report directory settings to add and manage VMs using SMHV. Notification
settings are optional.
Important: Dedicated and shared VMs that belong to the same host cluster
must not exist in the same dataset. Adding these types of resources to a
single dataset can cause the dataset backup to fail.
Although it is best to manage a host from only one management console, if you
need to do so from multiple consoles, you can import and export host and
dataset configuration information from one remote management console to
another to ensure data consistency. You can also use the Import and Export
wizard to change host and dataset configuration settings to a previously exported
setting. If you perform this operation in a clustered environment, you need to
import the settings on all nodes in the cluster so that all host and dataset
configurations are the same. Do not import or export configuration information to
the directory where SMHV is installed. If you uninstall SMHV, this file will be lost.
Adding a new parent host
When adding a new parent host to the SMHV console, follow the following steps:
1. Select the dataset that you want to add a new host.
2. On the Add Host window, enter the new host name or IP address.
3. Select Add.
SnapManager 1.0 for Hyper-V
17
Figure 6 shows how to add a new parent host to an existing dataset.
Figure 6 Adding a new host to SMHV
The backup process and implications
SMHV leverages N series Snapshot technology to create fast and space-efficient
backups of SMHV datasets and their associated VMs. These backups offer
point-in-time images, or copies, of the VMs and are stored locally on the same
storage platform on which the VMs physically reside.
In addition to the Snapshot copy stored locally, SMHV also provides an option to
update an existing SnapMirror relationship upon the completion of a backup.
This can be selected on a per backup job basis as required by the administrator.
The unit of backup in SMHV is a dataset, which can contain one or more VMs
running across multiple Hyper-V hosts. SMHV supports restoring an individual
VM. It does not support restoring an entire dataset.
Using SMHV, on demand or scheduled backups of VMs are possible. SMHV
supports backups of dedicated or clustered VMs. It also supports backups of
shared VMs running on CSVs.
18
SnapManager 1.0 for Hyper-V
Figure 7 represents a high-level overview of the typical SMHV architecture on the
primary site storage. Figure 7 depicts the backup process flow described in these
steps:
1. The SMHV Service is a VSS Requestor that initiates a VSS backup of VMs
within a dataset in coordination with the Microsoft Hyper-V VSS writer.
2. The Hyper-V VSS writer works together with the integration services within
the VM to create application-consistent “software” Snapshot copies of all VHD
volumes attached to each VM.
Figure 7 Hyper-V infrastructure and associated storage during an SMHV backup
3. SMHV then implements a VSS requestor component to coordinate the
backup process and create a consistent Snapshot copy in Data ONTAP using
VSS Hardware Provider for Data ONTAP LUNs.
4. The VSS framework requests the hardware provider to mount the LUNs from
the Snapshot copy.
5. The Hyper-V writer recovers data on the LUNs and brings it to the state of the
software Snapshot copy that was created in step 2.
SnapManager 1.0 for Hyper-V
19
6. The VSS provider creates a second Snapshot copy of the LUNs and then
dismounts them from the Snapshot copy.
7. Upon completion of the local backup, SMHV updates an existing SnapMirror
relationship on the volume if the SnapMirror option was selected. For further
details on SnapMirror, see Chapter 17, “SnapMirror,” in the IBM Redbooks®
publication IBM System Storage N series Software Guide, SG24-7129.
SMHV enables you to create application-consistent backups of a VM if you have
Microsoft Exchange, Microsoft SQL, or any other VSS-aware application running
on VHDs in the VM. SMHV coordinates with the application VSS writers inside
the VM to make sure that application data is consistent when the backup occurs.
For a backup to succeed, all files of the VM (VHDs, VM configuration files, and
the VM Snapshot files) must reside on LUNs managed by Data ONTAP.
Important: Only one backup operation can occur on a host at any given time.
If the same VMs belong to different datasets, do not schedule a backup of the
datasets at the same time. If that occurs, one of the backup operations will fail.
SMHV backup fails for VMs that have a VHD created by copying the contents of
a physical disk on the same host. The Create New VHD wizard of Hyper-V
manager gives this option. As part of copying the physical disk contents, it is also
copying the disk signature, and this causes the disk signature conflict during the
backup. More information is available here:
http://support.microsoft.com/kb/975695
Do not create a VHD using the “Copy the contents of the specified physical
disk” option on the Configure disk page in the new VHD creation wizard in
Microsoft Hyper-V manager. SnapManager for Hyper-V does not support the
backup and restore of virtual machines running on SAN boot LUNs. This is a
limitation of SDW.
Tip: When creating a dataset, select all VMs that reside on a particular Data
ONTAP LUN. This enables you to get all backups in one Snapshot copy and
to reduce the space consumption on the storage system. It is preferable to
add VMs running on the same CSV in the same dataset. If you add VMs on
the same CSV in different datasets, you need to ensure that the backup
schedules of these datasets do not overlap
If you change a VM Snapshot copy location to a different Data ONTAP LUN after
creating the VM, create at least one VM Snapshot copy using Hyper-V manager
before creating a backup using SMHV. If this is not done, the backup might fail.
20
SnapManager 1.0 for Hyper-V
Scheduled backups and retention policies
SMHV allows administrators to schedule a dataset backup at a particular time.
SMHV uses the Windows Tasks Scheduler for creating or modifying scheduling
policies. The 255 N series Snapshot copies per volume limit must be taken into
consideration when scheduling backups and configuring the associated retention
policies. The number of Snapshot copies per volume can be managed with the
proper scheduling and retention policies on a scheduled backup basis while still
meeting SLAs on the VMs.
Backup scheduling
Using scheduling policies, administrators can schedule backup jobs at particular
times, allowing them to automate the process. Multiple policies can be scheduled
per dataset that apply to all hosts that are dataset members. To configure a new
policy, take these steps:
1. On the left side of the SnapManager window, select Protection.
2. On the Datasets tab, select the dataset where the new policy will be created.
3. On the Dataset menu, select Add Policy. The Add Policy Wizard will start.
Figure 8 shows an example of a dataset backup policy for a daily base to start
at 7 p.m.
Figure 8 Backup schedule policy
SnapManager 1.0 for Hyper-V
21
Tip: The backup frequency, as well as the number of different backups
performed against a dataset (for example, one backup running against
dataset ds_1 weekly and another monthly), must be taken into account when
specifying the retention policy so as not to exceed the maximum number of
Snapshot copies per volume. If the number of Snapshot copies exceeds 255
on any given volume, future backups against that volume will fail.
Retention policies
Table 2 lists the retention tags available in SMHV.
Table 2 Backup schedules available at SMHV
22
Hourly
Hourly intervals
Daily
A specified time within a 24-hour period.
Weekly
A specified day and time within a seven-day period.
Monthly
A specified day and time within a calendar month.
Unlimited
Backups are never deleted.
SnapManager 1.0 for Hyper-V
After choosing a retention type, you can choose to delete either backups that are
older than a specified period of time or backups that exceed a maximum total.
Figure 9 shows how to set a retention policy at the dataset configuration wizard.
Figure 9 Dataset retention policy
IBM recommends using the policies not only to meet specific SLAs, but also to
maintain a supported number of N series Snapshot copies on the underlying
volumes. For SMHV one backup creates two Snapshot copies on the storage
systems to make sure of data consistency. For example, setting a retention
policy of 30 backups on an hourly backup will limit the maximum number of
Snapshot copies associated with the backup to 60. However, if the retention
policy had been configured as 30 days, the Snapshot limit per volume would be
reached in five days, and backups would begin to fail from that point on.
Tip: Choose a backup retention level based on your backup creation and
verification schedule. If a Snapshot copy deletion occurs, ensure that a
minimum of one verified backup remains on the volume. Otherwise, you run a
higher risk of not having a usable backup to restore from in case of a disaster.
Use the unlimited option with caution. When selecting this option, backups and
the associated N series Snapshot copies will be maintained until manually
deleted by the administrator. These Snapshot copies are included in the
maximum number supported on a volume. Of further note, the N series Snapshot
SnapManager 1.0 for Hyper-V
23
copies associated with on demand backups must also be considered when
determining the number of Snapshot copies maintained against a volume.
After creating a dataset backup, SMHV creates a Snapshot copy of the SnapInfo
LUN. SnapInfo Snapshot copies are not deleted if the backup is deleted.
SnapInfo Snapshot copies have a different retention policy. By default, SMHV
retains 30 SnapInfo LUN Snapshot copies and deletes the older ones when the
SnapInfo Snapshot count exceeds 30. You can configure the number of
SnapInfo Snapshot copies that you want to retain for each Hyper-V host using
the following registry key:
򐂰 For stand-alone Hyper-V hosts
Registry key: HKLM\SOFTWARE\NetApp\SnapManager for Hyper-V\Server
DWORD value: snapinfo_snaps_count (number of SnapInfo Snapshot copies
to be retained)
򐂰 For clustered Hyper-V hosts (to be configured on each node in the cluster)
Registry key: HKLM\Cluster\SOFTWARE\NetApp\SnapManager for
Hyper-V\Server DWORD value: snapinfo_snaps_count (number of SnapInfo
Snapshot copies to be retained)
Handling saved state backup of VMs
The default behavior of SMHV is to fail a backup if one or more VMs cannot be
backed up online. If a VM is in the saved state or shut down, an online backup
cannot be performed. In some cases, VMs are in the saved state or shut down
for maintenance, but backups still need to proceed, even if an online backup is
not possible. To do this, the VMs that are in the saved state or shut down can be
moved to a different data set with a policy that allows saved state backups.
You can also select the “Allow saved state VM backup” check box to allow SMHV
to back up the VM using the saved state. If you check this option, SMHV will not
fail the backup when the Hyper-V VSS writer backs up the VM using the saved
state or performs an offline backup of the VM. Doing a saved state or offline
backup can cause downtime. For more information about online of offline VM
backups, see the Hyper-V Planning for the Backup information in the Technet
library at:
http://technet.microsoft.com/en-us/library/cc753637(WS.10).aspx
24
SnapManager 1.0 for Hyper-V
To enable the saved state backup of VMs you must edit your current data set
and check the “Allow saved state VM backup” box (Figure 10).
Figure 10 Enabling saved state backup of VMs
For mission-critical VMs, disable the “Allow Saved state VM backup” option.
Backup scripts
Using SMHV you can run optional backup scripts to run either before or after the
backup takes place. These scripts will run on all dataset member hosts unless
you indicate a specific server. The following environment variables can be used
as arguments for backup postscripts:
򐂰 $VMSnapshot: This specifies the first VM Snapshot copy name that is
created on a storage system as a result of the backup. The second name
uses the first name plus appendix _backup.
򐂰 $SnapInfoName: This specifies the time stamp used in the SnapInfo
directory name.
򐂰 $SnapInfoSnapshot: This specifies the SnapInfo Snapshot copy name
created on the storage system. SMHV makes a Snapshot copy of the
SnapInfo LUN at the end of the data set backup.
SnapManager 1.0 for Hyper-V
25
This scripts path must be entered in the Backup Options from Add Policy Wizard
(Figure 10 on page 25).
During the post script execution phase, SMHV replaces the $VMSnapshot
variable with the Snapshot name, $SnapInfoName with the time stamp of the
backup, and $SnapInfoSnapshot with the SnapInfo Snapshot name.
Remeber: The $SnapInfoSnapshot variable is supported for dedicated virtual
machines only.
Quick/live migration implications
SMHV cannot back up a VM that is actively undergoing migration. If a backup
runs against a dataset that has VMs actively being migrated, an error will be
generated, and those particular VMs will not be backed up.
Restore process
SMHV can restore a VM from a backup. SMHV can also restore a VM that is part
of a cluster. To restore the VM, SMHV uses the file-level restore feature in SDW.
You can spread the associated files of a VM, including the configuration file,
Snapshot copies, and any VHDs, across multiple Data ONTAP LUNs. A LUN can
contain files belonging to multiple VMs.
If a LUN only contains files associated with the VM that you want to restore,
SMHV restores the LUN using LUN clone split restore (LCSR). If a LUN contains
files not associated with the VM that you want to restore, SMHV restores the VM
using the file copy restore operation.
These differences in restore types aside, the process flow used by SMHV during
a restore is:
1. SMHV restores a VM in coordination with Hyper-V VSS writer. Hyper-V VSS
writer powers off the VM and deletes it before restore.
2. Files are restored as described above based on restore type.
3. SMHV notifies that the files of the VM are restored properly. Hyper-V VSS
writer registers the VM and VM gets added back in the Hyper-V manager.
4. SMHV starts the VM after restore and executes a post script if specified in the
restore wizard.
26
SnapManager 1.0 for Hyper-V
While restoring, the following warning messages might be displayed:
򐂰 VM to be restored is not [currently running] on the host.
򐂰 VM to be restored is currently running on the host, and:
– It has more VHDs associated to it than at the time of backup.
– It has fewer VHDs associated to it than at the time of backup.
– The Snapshot location of the VM has changed.
– The names of VHD files or their file system paths or N series storage
system LUN path have changed.
In all of the above warning scenarios, the VM can be restored, but you have to
acknowledge that you are sure that you want to go ahead with the restore.
To restore files from a VM from SMHV, follow these steps:
1. Open the SnapManager for Hyper-V management console.
2. Select Recovery on the left side menu.
3. Access the dataset and select the VM for which that backups will be restored.
4. In the Backups list, select the backup that will be used to restore data.
5. Select Restore from the right side menu. The Restore Wizard starts.
6. On the Welcome page from the wizard, click Next.
7. The Restore Options page appears. On this page you can select the
following options:
– Select a command or script to run after completion of restore.
– Enable snapshot verification at completion of restore.
– Restart VM after restore is completed.
8. Select the options according to your restore plan and click Next.
9. The Summary page displays. Click Finish to complete the restore.
SnapManager 1.0 for Hyper-V
27
Figure 11 contains an example of a restore from a VM through SMHV.
Figure 11 Restoring a VM from SMHV
If the VM no longer exists, you can still restore it if the LUNs on which the VM
was created still exist. The LUNs must have the same drive letters and Windows
volume GUIDs as at the time of backup. If the VM no longer exists, you can still
restore it by selecting a backup to which it belonged. If the VM was removed from
all datasets before it was deleted, you can still restore it by selecting unprotected
resources and selecting a backup to which it belonged.
Tip: If the number of VHDs attached to a VM at the time of backup and restore
is not same, the restored VM might have extra/fewer VHDs. If that is the case,
manually update the cluster configuration of the VM and its dependencies.
SMHV does not back up the cluster configuration of the VM, so it does not
restore the cluster configuration. If the VM and cluster configuration are lost, you
28
SnapManager 1.0 for Hyper-V
can restore the VM from SMHV, but you have to manually make it
highly available.
Mounting a backup
Backups can be mounted using SnapDrive 6.2 for Windows. The mounted
backup is a clone of the protected VM. After it is mounted, the backup is
displayed within the explorer of the Hyper-V host. To browse it follow
these steps:
1. Select the LUN, and within Snapshot copies select the backup to mount.
2. Right-click the desired Snapshot copy and select the Connect Disk option.
The Connect Disk Wizard starts (Figure 12).
Figure 12 Connect disk wizard
SnapManager 1.0 for Hyper-V
29
3. On the Provide a Storage System Name, LUN Path and Name panel, perform
the following actions:
a. In the Storage System Name field, type the name of the storage system
where the LUN will be connected, or choose a storage system from the
drop-down list.
b. In the LUN Path field, type the path to the LUN. Alternatively, click Browse
and navigate to the LUN that you want to connect. Click Next (Figure 13).
Figure 13 Selecting the LUN to mount the backup
4. If the LUN is a dedicated disk, go to the next step. Otherwise, if the LUN is a
Windows cluster resource, perform the following steps in the Specify
Microsoft Cluster Services Group panel. In the Specify Microsoft Cluster
Services Group panel, perform one of the following actions:
– Select a cluster group from the Group Name drop-down list.
– Select Create a new cluster group to create a new cluster group.
Tip: When selecting a cluster group for your LUNs, choose the cluster
group that your application will use. If you are creating a volume mount
point, the cluster group is already selected. This is because the cluster
group owns your root volume physical disk cluster resources. Create
new shared LUNs outside of the cluster group.
30
SnapManager 1.0 for Hyper-V
– Select Add to cluster shared volumes.
Click Next.
5. On the Select LUN Properties panel, either select a drive from the list of
available drive letters or enter a mount point for the LUN that you are
connecting (Figure 14). When you create a volume mount point, enter the
drive path that the mounted drive will use (for example, G:\mount_drive1\).
Figure 14 Select LUN properties
SnapManager 1.0 for Hyper-V
31
6. On the Select Initiators panel, choose an initiator for the LUN (Figure 15).
Figure 15 Select Initiators
7. On the Select Initiator Group Management panel, specify whether you will
use automatic or manual igroup management. If you select the manual
option, you must specify an existing igroup or create a new one.
8. On the Completing the Connect Disk Wizard panel, perform the
following actions:
a. Verify all the settings.
b. If you need to change any settings, click Back to go back to the previous
wizard panels.
9. Click Finish.
32
SnapManager 1.0 for Hyper-V
10.Browse the backup by selecting the drive letter on the explorer of Hyper-V
host. Figure 16 shows that volume H was mapped by Hyper-V as a new drive
(J drive).
Figure 16 Snapshot mapped by Hyper-V as J drive
At this point, users can access the contents of the snapshot mapped by Hyper-V.
Single file restore capability
In addition to backup verification, mounting a backup provides a way to restore a
single file from within a VM on a case-by-case basis. This is performed by
attaching a VHD from within the mounted backup as an existing hard drive to a
VM within Hyper-V manager.
Requirement: The virtual machine must be turned off before you can access
settings and add a new VHD.
After a backup has been mounted, follow these manual steps to perform the
restore of a single file, or multiple files, from within a VM backup:
1. Right-click the VM to which the VHD will be attached.
2. Click Settings in the drop-down menu.
3. Select IDE controller.
SnapManager 1.0 for Hyper-V
33
4. When asked to choose the type of device that you want to add, select Hard
Drive and click Add (Figure 17).
5. Select the virtual hard disk (.vhd) file and click Browse.
Figure 17 Adding a mounted backup to an existing VM
6. Browse to the mounted backup.
34
SnapManager 1.0 for Hyper-V
7. Select the required VHD file and click OK (Figure 18).
Figure 18 Previous mounted backup added as a VHD into a VM
8. The VHD file will be attached to the specified VM after clicking OK.
Create a “landing” VM that can be used as a target system when mounting
backups and attaching preexisting hard drives (VHDs). One VM must be created
as a target for each guest operating system within the Hyper-V environment.
After the VHD is mounted, files can be copied across the network back to their
desired location. By following this practice, the landing VM can be powered off
after the restore is completed without interrupting production, and the VHD
removed before unmounting the backup.
Not only is this desirable, as it limits disruption to a production VM, but it also
prevents a backup from remaining in a mounted state for an extended period
of time.
SnapManager 1.0 for Hyper-V
35
Leaving a backup in a mounted state places Snapshot copies in a busy
condition, preventing the deletion of both the mounted backup and any preceding
Snapshot copies. Backup must be unmounted when not in use.
To remove a VHD follow these steps:
1. Power down the VM.
2. Right-click the VM with Hyper-V Manager and select Settings from the
drop-down menu.
3. Within the IDE controller window, select the hard disk that needs to be
removed. Verify that you have selected the correct disk by checking the disk
file name before clicking Remove.
4. Click OK.
At this point, the backup can be unmounted by taking these steps:
1. Select the disk that you mounted.
2. Right-click the disk and select Disconnect.
High availability
The availability of the shared storage infrastructure is more critical than the
actual availability of the individual physical servers hosting the VMs on a
Hyper-V server itself, as they support features such as live/quick migration,
which makes sure of the high availability at the hypervisor layer. With N series
software solution most of the availability requirements of a virtual infrastructure
can be addressed.
Note that the SMHV, being a host-end application, offers services provided that
the storage is continuously available.
The following section provides a detailed description on the available tools that
facilitate storage availability.
Multipath HA with active-active N series controllers
The N series active-active controllers offer easy, automatic, and transparent
failover capabilities to deliver a high-availability solution. Configuring multipath
HA with N series active-active controllers enhances the overall storage
infrastructure availability and promotes higher performance consistency. It offers
protection against storage failure events such as FC adapter or port failure,
controller-to-shelf cable failure, shelf module failure, dual intershelf cable failure,
36
SnapManager 1.0 for Hyper-V
and secondary path failure. This equips environments running business-critical
applications such as the Microsoft Hyper-V virtual infrastructure to provide
uninterrupted services.
Tip: Use the active-active storage controller configuration to eliminate any
single points of failure (SPOFs).
Use multipath HA with active-active storage configuration to get a better storage
availability and higher performance.
Data ONTAP DSM for Windows MPIO
Microsoft MPIO is a protocol-independent feature that supports multiple data
paths to a storage device with iSCSI, Fibre Channel, or SAS. Providing multiple
paths that can handle failover increases the availability from a host to the storage
system. Windows 2008 R2 x 64 servers include support for Microsoft MPIO.
IBM Data ONTAP device-specific modules (DSMs) for Windows MPIO help IBM
N series storage systems to integrate with Microsoft MPIO on Windows 2008 R2
server and provides high availability to applications using path failover methods.
It determines all the paths pointing to the same LUN so that MPIO can group
them into the virtual disk that Windows Server 2008 Hyper-V server will mount. It
is also responsible for communicating with MPIO to identify which path to route
I/O. This is especially important in the event of a failover. There can be multiple
active paths and multiple passive paths. If all of the active paths fail, the DSM
automatically switches to the passive paths, maintaining the host's access to
its storage.
For a highly available connection to the storage system, IBM requires installing
the supported version of multipathing software such as the Data ONTAP DSM for
Windows MPIO. For Windows Server 2008 R2 servers, IBM recommends Data
ONTAP DSM 3.2R1 or later. For the currently supported multipathing software
versions and related requirements, see the IBM Interoperability Matrix at:
ftp://service.boulder.ibm.com/storage/nas/nseries/nseries_snapdrive.pdf
Application consistency
Microsoft’s Volume Shadow Copy Service (VSS) was written specifically to
enable third-party backup and recovery solutions to provide
application-consistent backup and recovery for mission-critical Microsoft
SnapManager 1.0 for Hyper-V
37
supported applications. When VSS is properly configured within the Hyper-V
environment, an SMHV initiated Snapshot copy will begin the VSS process.
VSS is designed to produce fast, consistent Snapshot copy-based online
backups by coordinating backup and restore operations among business
applications, file-system services, backup applications, fast-recovery solutions,
and storage hardware. VSS coordinates Snapshot copy-based backup and
restore and includes the following additional components:
򐂰 VSS requestor
The VSS requestor is a backup application, such as the SMHV application or
NTBackup. It initiates VSS backup and restore operations. The requestor also
specifies Snapshot copy attributes for the backups that it initiates.
򐂰 VSS writer
The VSS writer owns and manages the data to be captured in the Snapshot
copy. Microsoft Hyper-V is an example of a VSS writer.
򐂰 VSS provider
The VSS provider is responsible for the creation and management of the
Snapshot copy. A provider can be either a hardware provider or a software
provider. A hardware provider integrates storage array-specific Snapshot
copy and cloning functionality into the VSS framework. The Data ONTAP
VSS hardware provider integrates the SnapDrive service and storage
systems running Data ONTAP into the VSS framework. A software provider
implements Snapshot copy or cloning functionality in software that is running
on the Windows system.
The coordinated backup process includes freezing the data application I/O,
flushing the file system cached I/O to disk, and creating a point-in-time Snapshot
copy of the data state. After the Snapshot copy is created, file system and
application I/O are resumed. The VSS restore process involves placing the data
application into the restore state, passing backup metadata back to the
application whose data is being restored, restoring the actual data, and signaling
the data application to proceed with recovering the data that was restored.
SMHV provides integration with Microsoft Hyper-V VSS writer to quiesce a VM
before creating an application-consistent Snapshot copy of the VM. SMHV is a
VSS requestor and coordinates the backup operation to create a consistent
Snapshot copy, using VSS hardware provider for Data ONTAP. SMHV allows
you to create application-consistent backups of a VM if you have Microsoft
Exchange, Microsoft SQL, or any other VSS aware application running on VHDs
in the VM. The applications that exist in the VM restore to the same state as at
the time of the backup. SMHV restores the VM to its original location.
38
SnapManager 1.0 for Hyper-V
If applications are running on pass-through or direct-attached iSCSI LUNs, these
LUNs are ignored by the VSS framework in the VM, and SMHV will not create a
backup of these LUNs in the VM. To enable backup of application data on
direct-attached iSCSI LUNs or pass-through LUNs in the VM you would need to
configure application backup products in the VM (for example, SnapManager for
Exchange, SnapManager for SQL, and so on).
The Data ONTAP VSS hardware provider is installed automatically as part of
the SnapDrive software installation. To ensure that the Data ONTAP VSS
hardware provider works properly, do not use the VSS software provider on Data
ONTAP LUNs. If you use the VSS software provider to create Snapshot copies
on a Data ONTAP LUN, you will be unable to delete that LUN using the VSS
hardware provider.
VSS requires that the provider initiate a Snapshot copy within 10 seconds. If this
time limit is exceeded, the Data ONTAP VSS hardware provider logs event ID
4364. This limit could be exceeded due to a transient problem. If this event is
logged for a failed backup, retry the backup.
SMHV coordinates with Hyper-V VSS writer to create application-consistent
backups of VMs. Hyper-V writer communicates with integration services
(Hyper-V Volume Shadow Copy requestor service) installed in the VM to quiesce
the applications running in the VM before creating a backup. Data ONTAP VSS
hardware provider installed on the Hyper-V host as part of SnapDrive is used to
create Snapshot copies on the storage system. For details on VM backup, refer
to the following TechNet link:
http://technet.microsoft.com/en-us/library/dd252619(WS.10).aspx
Conclusion
SnapManager 1.0 for Hyper-V provides a rich feature set that allows IT
organizations to take advantage of N series Snapshot and SnapMirror
technologies to provide fast, space-efficient disk-based backups in a Hyper-V
environment with IBM N series storage, while placing minimal overhead on the
associated virtual infrastructure. The recommendations and examples in this
report will help administrators get the most out of SMHV deployments. For more
information about any of the solutions or products covered in this report,
contact IBM.
SnapManager 1.0 for Hyper-V
39
Summary of SnapManager for Hyper-V
recommendations
In this section, we provide a summary of recommendations and helpful tips for
configuring and using SnapManager for Hyper-V.
Deploying Hyper-V on a shared storage
The recommendation while deploying Hyper-V on a shared storage is to have
one VM per LUN configured. All the VHDs relative to a single VM (VM with
multiple drives) can reside on a single LUN provisioned as a shared storage to a
WFC. This is a recommendation for Windows 2008 Server R2 running Hyper-V
deployed on standard shared storage volumes.
SMHV open ports
For SMHV and SDW, make sure that the following ports are kept open:
򐂰 SMHV, port 808
򐂰 SDW, default port 4094
򐂰 If SDW is configured to use HTTP protocol, port 4095
Requirement: When installing SMHV on a cluster, the same port number
must be used across all nodes.
When installing SMHV on a cluster, the same port number must be used across
all nodes.
SnapInfo LUN
Having a SnapInfo LUN on a volume of its own is preferable.
Creating a dataset
When creating a dataset, select all VMs that reside on a particular Data ONTAP
LUN. This enables you to get all backups in one Snapshot copy and to reduce
the space consumption on the storage system.
40
SnapManager 1.0 for Hyper-V
Changing a VM Snapshot copy file location
If you change a VM Snapshot copy file location to a different Data ONTAP LUN
after creating the VM, you must create at least one VM Snapshot copy using
Hyper-V manager before creating a backup using SMHV. If you change the
Snapshot file location and do not create a VM Snapshot copy before creating a
backup, the backup could fail.
Retention policy considerations
The backup frequency, as well as the number of different backups performed
against a data set (for example, one backup running against data set ds_1
weekly and another monthly), must be taken into account when specifying the
retention policy so as not to exceed the maximum number of Snapshot copies
per volume. If the number of Snapshot copies exceed 255 on any given volume,
future backups against that volume will fail.
Choosing a backup retention level
Choose a backup retention level based on your backup creation and verification
schedule. If a Snapshot copy deletion occurs, ensure that a minimum of one
verified backup remains on the volume. Otherwise, you run a higher risk of not
having a usable backup set to restore from in case of a disaster.
Mission-critical VMs
For mission-critical VMs, enable the “Allow Saved state VM backup” option.
VMs actively being migrated
SMHV cannot back up a VM that is actively undergoing migration. If a backup
runs against a dataset that has VMs actively being migrated, an error will be
generated, and those particular VMs will not be backed up. Only migrate VMs
when a significant gain in performance can be achieved. This improves not only
the success rate of the backups, but the overall VM performance as well.
Number of VHDs at the time of backup and restore
If the number of VHDs at the time of backup and of restore are not the same, the
restored VM might have extra/fewer VHDs. If that is the case, manually update
the cluster configuration of the VM and its dependencies.
SnapManager 1.0 for Hyper-V
41
Use of active-active storage controller configuration
Use an active-active storage controller configuration to eliminate any SPOFs.
Use multipath HA with an active-active storage configuration to get better
storage availability and higher performance.
Highly available connection to storage system, multipathing software
For a highly available connection to the storage system, N series requires
installing the supported version of multipathing software, such as the Data
ONTAP DSM for Windows MPIO. For Windows Server 2008 R2 servers, IBM
recommends Data ONTAP DSM 3.2R1 or later. For the currently supported
multipathing software versions and related requirements, see the N series
Interoperability Matrix.
Virtual machine managing itself
If a VM belongs a host that has SMHV installed, and you install SMHV on that
VM to use as a management console, do not use SMHV to manage the host to
which the VM belongs. For example, if VM1 belongs to Host1 (with SMHV
installed), and you install SMHV on VM1, do not use SMHV to manage Host1
from VM1. If you do this and try to restore the VM from itself, the VM will be
deleted or restarted from Hyper-V Manager.
Data ONTAP VSS hardware provider requirement
Data ONTAP VSS hardware provider must be installed for SnapManager to
function properly. Data ONTAP VSS hardware provider integrates the SnapDrive
service and storage systems running Data ONTAP into the VSS framework. The
Data ONTAP VSS hardware provider is now included with SnapDrive 6.0 or later
and does not need to be installed separately.
Viewing installed VSS providers
To view the VSS providers installed on your host, complete these steps:
1. Select Start  Run and enter the cmd command to open a Windows
command prompt.
2. At the prompt, enter the following command:
vssadmin list providers
42
SnapManager 1.0 for Hyper-V
The output will be similar to the following example:
Provider
Provider
Provider
Version:
name: ‘Data ONTAP VSS Hardware Provider’
type: Hardware
Id: {ddd3d232-a96f-4ac5-8f7b-250fd91fd102}
6.2.0.xxxx
Verifying that VSS hardware provider was used successfully
To verify that the Data ONTAP VSS hardware provider was used successfully
after a Snapshot copy was created, navigate to System Tools  Event
Viewer  Application in MMC and look for an event with the values shown in
Figure 19.
Source Event ID Description
The VSS provider has successfully
completed CommitSnapshots for
SnashotSetId id in n milliseconds.
Navsspr 4089
Figure 19 Application Event Viewer values
Information VSS requires that the provider initiate a Snapshot copy within 10
seconds. If this time limit is exceeded, the Data ONTAP VSS hardware provider
logs event ID 4364. This limit could be exceeded due to a transient problem. If
this event is logged for a failed backup, retry the backup.
Virtual machine backups take too long to complete
If a virtual machine contains several direct-attached iSCSI LUNs or pass-through
LUNs, and SnapDrive for Windows is installed on the virtual machine, the virtual
machine backup can take a long time. The Hyper-V writer takes a hardware
snapshot of all the LUNs in the virtual machine using the SnapDrive for Windows
VSS hardware provider. There is a Microsoft hotfix that uses the default system
provider (software provider) in the virtual machine to make the snapshot. As a
result, the Data ONTAP VSS hardware provider is not used for snapshot creation
inside the child OS and the backup speed increases. For more information about
the Microsoft hotfix, see Knowledge Base article 975354 on the Microsoft
support site.
SnapManager 1.0 for Hyper-V
43
The team who wrote this IBM Redpaper
This paper was produced by a team of specialists from around the world working
at the International Technical Support Organization, San Jose Center.
Alex Osuna is a Project Leader at the International Technical Support
Organization, Tucson Center. He writes extensively about all areas of data
storage, both hardware and software. Alex has over 33 years of experience in the
IT industry with the United State government and IBM. Alex has held positions in
service, support, planning, product introduction, sales, and publications mainly
focused on data storage including software and hardware.
Ravi B is a Technical Marketing Engineer for NetApp specializing in Microsoft
Solutions and Engineering.
Kyle Burrell is an IT Specialist in Boulder, Colorado, USA. He has been with IBM
for 18 years. His past seven years have been focused on storage.
Amrita Das is a Product Manager at NetApp. In the past he was a Technical
Marketing Engineer at NetApp and a Systems Engineer at HP. He is a graduate
of the Indian Institute of Management, Bangalore, and Guru Gobin Singh
Indraprastha University.
Luiz Paulo Moreira is an N series System Admin in Brazil. Luiz has 10 years of
experience in IT and four years of experience with N series storage systems. Luiz
holds a degree in Telecommunication Engineer from University of Taubaté Taubaté/Brazil (UNITAU). His areas of experience includes Windows servers
management, Malware defense, backup and recovery, and SAN Management.
Now you can become a published author, too!
Here's an opportunity to spotlight your skills, grow your career, and become a
published author—all at the same time! Join an ITSO residency project and help
write a book in your area of expertise, while honing your experience using
leading-edge technologies. Your efforts will help to increase product acceptance
and customer satisfaction, as you expand your network of technical contacts and
relationships. Residencies run from two to six weeks in length, and you can
participate either in person or as a remote resident working from your home
base.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
44
SnapManager 1.0 for Hyper-V
Stay connected to IBM Redbooks
򐂰 Find us on Facebook:
http://www.facebook.com/IBMRedbooks
򐂰 Follow us on Twitter:
http://twitter.com/ibmredbooks
򐂰 Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
򐂰 Explore new Redbooks publications, residencies, and workshops with the
IBM Redbooks weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
򐂰 Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
SnapManager 1.0 for Hyper-V
45
46
SnapManager 1.0 for Hyper-V
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.
© Copyright International Business Machines Corporation 2011. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
47
This document REDP-4649-00 was created or updated on November 9, 2011.
®
Send us your comments in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an email to:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
Redpaper ™
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. These and other IBM trademarked
terms are marked on their first occurrence in this information with the appropriate symbol (® or ™),
indicating US registered or common law trademarks owned by IBM at the time this information was
published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
IBM®
Redbooks®
Redpaper™
Redbooks (logo)
®
The following terms are trademarks of other companies:
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Snapshot, SnapRestore, SnapMirror, SnapManager, SnapDrive, Data ONTAP, and the NetApp logo are
trademarks or registered trademarks of NetApp, Inc. in the U.S. and other countries.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel
SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
48
SnapManager 1.0 for Hyper-V