SnapManager for Hyper-V (SMHV) leverages NetApp's Snapshot technology to create backups of virtual machines hosted on Windows 2008 R2 Hyper-V servers. These backups capture point-in-time images of the VMs stored locally on the NetApp storage. The document describes the backup workflow in three levels - high level, low level, and raw, detailing the sequence of actions taken by SMHV, Hyper-V, and the NetApp storage system to back up the VMs using Snapshot technology in a consistent manner.

1. Backup workflow
On
Windows 2008 R2 HYPER-V
SMHV [SnapManager for HYPER-V] leverages NetApp Data ONTAP 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 document focuses only on the 'Backup workflow'. If you need information on SMHV
Install/Admin Guide or Best Practices Guide, please refer to the links provided at the end of
this document; else go to netapp support site or simply google.
What is workflow - Workflow is sometimes described as a series of tasks that produce an
outcome. In the context of NetApp SMHV, this document defines workflow as a sequence of
actions or tasks that work together to accomplish successful backup job.
ashwinwriter@gmail.com
April, 2014

2. There are two basic methods you can use to perform a backup. You can:
 Perform a backup from the server running Hyper-V:
This is the recommend method to perform a full server backup because it captures
more data than the other method. If the backup application is compatible with
Hyper-V and the Hyper-V VSS writer, you can perform a full server backup that helps
protect all of the data required to fully restore the server, except the virtual
networks. The data included in such a backup includes the configuration of virtual
machines, snapshots associated with the virtual machines, and virtual hard disks used
by the virtual machines. As a result, using this method can make it easier to recover
the server if you need to, because you do not have to recreate virtual machines or
reinstall Hyper-V. However, virtual networks are not included in a full server backup.
You will need to reconfigure the virtual networking by recreating the virtual networks
and then reattaching the virtual network adapters in each virtual machine to the
appropriate virtual network. As part of your backup planning, make sure you
document the configuration and all relevant settings of your virtual network if you
want to be able to recreate it.
 Perform a backup from within the guest operating system of a virtual machine:
Use this method when you need to back up data from storage that is not supported by
the Hyper-V VSS writer. When you use this method, you run a backup application from
the guest operating system of the virtual machine [with backup agent inside the VM].
If you need to use this method, you should use it in addition to a full server backup
and not as an alternative to a full server backup. Perform a backup from within the
guest operating system before you perform a full backup of the server running Hyper-
V. For more information about storage considerations, see the following section.
This document covers workflow for SMHV in three levels:
 High level workflow
 Low level workflow
 RAW workflow

3. high level Backup workflow for SMHV
WINDOWS 2008 R2 HYPER-V
1. The NetApp SMHV service [VSS requestor] on the HYPER-V host in coordination with
the Microsoft Hyper-V VSS starts a backup.
2. The NetApp SMHV service on the Hyper-V host sends a request to the HYPER-V VSS on
the host OS to freeze the guest OS.
3. HYPER-V VSS on the host OS sends a request to the Hyper-V writer to freeze the guest
OS.
4. The Hyper-V writer passes the freeze request to VSS on the guest OS through the
Hyper-V 'BIS' [Backup Integration Services].
HANDY TIP: Like Backup Softwares [SMHV, Veeam, Altaro, Symantec etc] are called Volume
Shadow Copy 'Requestor' on the HYPER-V Host [called Parent Partition], similarly the backup
integration service IC is considered Volume Shadow Copy ‘Requestor’ inside the guest
operating system [called Child Partition].
5. VSS on the guest OS sends a request to the VSS application writer to freeze the
application.
6. The VSS application writer freezes the application and flushes data from the guest OS
memory.
7. HYPER-V VSS on the host OS sends a request to the NetApp VSS Hardware Provider to
create a snapshot.
8. The NetApp storage system creates a snapshot.
9. At the completion of the local backup, SMHV updates an existing SnapMirror
relationship on the volume if the SnapMirror option was selected.

4. Low level Backup workflow for SMHV
WINDOWS 2008 R2 HYPER-V
Customized flowchart
Steps numbered in the flowchart are explained in the next page.
Note: The complete workflow shown above does not exist in NetApp SMHV documentation,
though part of it does exist. I have put together this workflow with the help of flow chart and
documentation from other backup vendors [specifically – courtesy: ‘Veeam.com’]. I am hoping
it’s correct and in line with what happens in background during auto-recovery.
[As all backup vendors (requestors) for HYPER-V environment implements standard Microsoft
VSS framework to perform HYPER-V backups]

5. Low level Backup workflow in steps
1. SMHV interacts with the Hyper-V host VSS Service and requests backup of specific VMs.
2. The VSS Writer on the Hyper-V host passes the request to the Hyper-V Integration
Components (HV-IC) installed inside the VM guest OS.
3. The HV-IC, in its turn, acts as a VSS Requestor for the VSS framework inside the VM — it
communicates with the VSS framework installed in the VM guest OS and requests backup of
VSS-aware applications running inside this VM.
4. The VSS Writers within the VSS-aware applications inside the guest OS are instructed to get
the application data to a state suitable for backup.
5. After the applications are quiesced, the VSS inside the VM takes an internal snapshot within
the VM using a VSS software provider in the VM guest OS.
6. After the internal snapshot is taken, the VM returns from the read-only state to the read-
write state and operations inside the VM are resumed. The created snapshot is passed to the
HV-IC.
7. The HV-IC notifies the hypervisor that the VM is ready for backup.
8. The Hyper-V host VSS Hardware provider takes a snapshot of a volume on which the VM is
located (external snapshot).
To make sure the VM data is consistent at the moment of backup, Hyper-V VSS Writer
performs additional processing inside the created external snapshot – this process is also
known as auto-recovery.
a. SnapDrive takes the first snapshot of the LUN where the VM resides.
b. It mounts the LUN inside the snapshot to add AUTORECOVERY information (mounts as
CLONE).
c. The original LUN is renamed as exclude_{GUID}, and the CLONE is renamed as the
original LUN.
d. SnapDrive then takes the second snapshot of the CLONE LUN, and the clone is
destroyed. The LUN is renamed to its original name from exclude_{GUID}.
9. Upon completion of the local backup, SMHV updates an existing SnapMirror relationship on
the volume if the SnapMirror option was selected

6. RAW workflow
[As recorded on the HYPER-V Host – In Windows Application Event log]
1. SnapManager for Hyper-V backup is now started
Dataset Name = Virtual-Machines
Backup id = 6ad83514-21a0-4a99-a774-8bf6e38c281e
Backup Type = Application consistent
2. ONTAP VSS hardware provider service has started.
[Note: The Data ONTAP VSS Hardware Provider ships as part of and is installed with
NetApp SnapDrive for Windows, which is licensed per storage controller, or per physical
Windows Server.]
3. Data ONTAP VSS hardware provider is loaded.
4. Data ONTAP VSS hardware provider is adding a source lun [VendorId=NETAPP,
ProductId=LUN, SerialNo=dnlPWZfVCoVK] to SnapshotSetId {4d6e1978-1b45-4176-
81d6-94ee3d4a5be4}.
5. SnapDrive is ready to create Snapshot copy ({4d6e1978-1b45-4176-81d6-
94ee3d4a5be4}) of LUN(s).
6. Snapshot ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}) of LUN(s) on storage system
(Filer05) volume (vol_clvsh01_csv03|) was successfully created. [As per step 8a in the
Low level workflow]
7. Data ONTAP VSS hardware provider has successfully completed CommitSnapshots for
SnapshotSetId {4d6e1978-1b45-4176-81d6-94ee3d4a5be4} in 203 milliseconds.
8. GetTargetLunInfo succeeded.
Storage System Name = Filer05
lunPath = /vol/vol_clvsh01_csv03/clvsh01_csv03.lun
Snapshot copy Name = {4d6e1978-1b45-4176-81d6-94ee3d4a5be4}
9. CreateTargetLun succeeded.
Storage System Name = Filer05
lunPath = /vol/vol_clvsh01_csv03/clvsh01_csv03.lun
Snapshot copy Name = {4d6e1978-1b45-4176-81d6-94ee3d4a5be4}
10. Data ONTAP VSS hardware provider has successfully mapped a lun [VendorId=NETAPP,
ProductId=LUN, SerialNo=7S-zp$Bb5jSb].
11. Revert operation for volume ?Volume{2cd0fffa-f006-11e0-a76b-002655db9b10} has
begun. Volume is being reverted to the shadow copy with id {927d2780-ce23-4990-
90ac-3df404041dbc}.

7. Operation:
Revert a Shadow Copy
Context:
Execution Context: Coordinator
12. SnapDrive is ready to create Snapshot copy ({4d6e1978-1b45-4176-81d6-
94ee3d4a5be4}_backup) of LUN(s).
13. Snapshot ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}_backup) of LUN(s) on storage
system (Filer05) volume (vol_clvsh01_csv03|) was successfully created. [As per step
8d in the Low level workflow]
14. DeleteTargetLun succeeded.
Storage System Name = Filer05
lunPath = /vol/vol_clvsh01_csv03/{8b0053c1-8cec-4cc6-8400-3220eaa8ecc3}.rws
15. Data ONTAP VSS hardware provider has successfully unmapped and deleted a lun
[VendorId=NETAPP, ProductId=LUN, SerialNo=7S-zp$Bb5jSb].
16. The Snapshot copy ({4d6e1978-1b45-4176-81d6-94ee3d4a5be4}_backup) of the LUN
was renamed to (Virtual-Machines_clvsh01_CNVSH05_03-21-2014_22.00.00_backup).
LUN Name = clvsh01_csv03.lun
Storage Path = /vol/vol_clvsh01_csv03
Protocol Type =
Storage System Name = Filer05
17. SnapManager for Hyper-V backup operation completed successfully
Backup of the Dataset Name: Virtual-Machines
Backup id: 6ad83514-21a0-4a99-a774-8bf6e38c281e succeeded
18. The Snapshot copy (@snapmir@{91F05093-39B1-421E-8BF7-8C3A0526F253}) of the LUN
(C:ClusterStorageVolume3) on storage system (Filer05) volume (vol_clvsh01_csv03)
was deleted
19. SnapDrive is ready to create Snapshot copy (@snapmir@{0C5AB7A3-182E-455C-919E-
E787EBDFD589}) of LUN(s).
20. Snapshot (@snapmir@{0C5AB7A3-182E-455C-919E-E787EBDFD589}) of LUN(s) on
storage system (Filer05) volume (vol_clvsh01_csv03) was successfully created.
21. A SnapMirror update request from source (Filer05:vol_clvsh01_csv03) to destination
(filer06:vol_clvsh01_csv03) was successfully sent.
22. The VSS service is shutting down due to idle timeout.
23. Data ONTAP VSS hardware provider is unloaded.
24. Data ONTAP VSS hardware provider service has stopped.

8. 25. SnapDrive is ready to create Snapshot copy (smhv_snapinfo_clvsh01_03-21-
2014_22.00.00.1.24) of LUN(s).
26. Snapshot (smhv_snapinfo_clvsh01_03-21-2014_22.00.00.1.24) of LUN(s) on storage
system (Filer05) volume (vol_clvsh01_snapinfo) was successfully created.
27. The Snapshot copy (smhv_snapinfo_clvsh01_12-10-2013_22.00.00.398.18) of the LUN
(S) on storage system (Filer05) volume (vol_clvsh01_snapinfo) was deleted
28. The Snapshot copy (@snapmir@{66C85B3D-4B9B-42A9-BAB2-B6C5784FB0A0}) of the
LUN (?Volume{32776c92-5309-4361-8d99-cdf419374bef}) on storage system
(Filer05) volume (vol_clvsh01_snapinfo) was deleted
29. SnapDrive is ready to create Snapshot copy (@snapmir@{8D8B23C3-6577-4D13-8D19-
5DC0A7DED8C6}) of LUN(s).
30. Snapshot (@snapmir@{8D8B23C3-6577-4D13-8D19-5DC0A7DED8C6}) of LUN(s) on
storage system (Filer05) volume (vol_clvsh01_snapinfo) was successfully created.
31. A SnapMirror update request from source (Filer05:vol_clvsh01_snapinfo) to destination
(filer06:vol_clvsh01_snapinfo) was successfully sent.
Note: In the workflow described above, Filer05 is the production NetApp FAS/filer & Filer06 is
the replication DR partner.
DRAWBACK in WINOWS 2008 R2 HYPER-V
The same process continues for Host2, Host 3 & so on depending upon the number of hosts in
the cluster hosting the VMs, and the backup is then complete from the VSS requestor's
perspective. This makes the Hyper-V backup complex for CSV. Performance is big issue since
multiple VSS initializations/backup complete are done on each node in the cluster. This type
of solution is hard to scale as the number of nodes and VMs in a cluster increases like in
WS2012.

9. Types of snapshots created by SMHV during HYPER-V Backup
NetApp SMHV creates three types of snapshots as part of the HYPERV Backup.
First two snapshots are located under the respective CSV volume snapshot in NetApp Systems
Manager
1. DatasetName-Virtual-Machines-25-2014_22.00.00
2. DatasetName-Virtual-Machines-25-2014_22.00.00_Backup
Third snapshot is located under the snapinfo volume in NetApp Systems Manager
3. smhv_snapinfo_clvsh01_04-25-2014_22.00.00.818.21
Do I need to keep all three backups?
Yes, all the three backups are required for successful restore.
1. "_backup" volume snapshot
2. Base snapshot (the one without _backup suffix).
2. 'snapshot' of SnapInfo LUN [This snapshot captures the backup metadata. SnapManager for
Hyper-V makes a Snapshot copy of the SnapInfo LUN at the end of the dataset backup]
operation.
Why this is needed - This is the catalog information [Like any other Backup Software, we need
catalog information to restore data]. Please note SMHV cannot restore a VM from backup if
corresponding backup metadata is not available.
More info on 'snapinfo'
The SnapInfo LUN stores the dataset backup metadata. NetApp recommends having the
SnapInfo LUN on a volume of its own. SMHV records the snapshot name in the metadata
[snapinfo] of the backup. So if the snapshot name is renamed in the storage system volume
after the backup is taken then the restore operation for that backup will fail. This is because
SMHV checks to make sure that the snapshot name in the backup metadata does exists in the
filer and if the same name snapshot is not found the restore operation will fail.

10. Good News
Microsoft has re-architected Cluster Shared Volume and has introduced 'Distributed CSV
Application consistent backup' feature in WINDOWS 2012 to address this problem.
Watch this video to get detailed information on the 're-born' architecture.
Cluster Shared Volumes Reborn in Windows Server 2012: Deep Dive
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WSV430
FAQ
 Why autorecovery is required?
In short, auto-recovery is required b'cos virtual machine and storage system snapshots may
not be in a consistent state due to a time lag between the two [child VM snapshot & Storage
system snapshot] snapshots.
 What is auto-recovery?
Auto-recovery is a process in which 'shadow copy' created by the 'VSS Hardware provider' is
temporarily made available as a read-write volume so that VSS and one or more applications
can alter the contents of the shadow copy before the shadow copy is finished.
After VSS and the applications [SMHV] make their alterations, the shadow copy is made read-
only. This phase is called Auto-recovery, and it is used to undo any file-system or application
transactions on the shadow copy volume that were not completed before the shadow copy
was created.
 Why does HYPER-V host does not support backing up pass-through & iSCSI disk in the
child partitioned VM?
It is b'cos the Pass-through and iSCSI disks are not visible to the host operating system and
therefore not backed up by the Hyper-V VSS writer. Backups of these volumes must be done
entirely within the VM.
 Major benefits of CSV over traditional cluster disk:
 CSV can fail over quickly without requiring a change in drive ownership
 The failover will not require a dismount or remount of the CSV Volume
 It helps simplify management
 Scale-out File Server can use an CSV
 CSV supports Bitlocker
 CSV supports Storage spaces
 CSV supports backup
 CSV supports Anti-Virus

11.  How CSV disks are viewed in the HYPER-V Host?
Disks in CSV are identified with a path name. Each path appears to be on the system drive of
the node as a numbered volume under the ClusterStorage folder. This path is the same when
viewed from any node in the cluster. You can rename the volumes if needed.
To use CSV, your nodes must meet the following requirements:
 Drive letter of system disk. On all nodes, the drive letter for the system disk must be
the same.
 Authentication protocol. The NTLM protocol must be enabled on all nodes. This is
enabled by default.
 Which are the Conditions when SMHV will backup virtual machines using 'save-state':
 Virtual machines that do not have Integration Services installed will be put in a saved
state while the VSS snapshot is created.
 Virtual machines that are running operating systems that do not support VSS, such as
Microsoft Windows 2000 or Windows XP, will be put in a saved state while the VSS
snapshot is created.
 Virtual machines that contain dynamic disks (not dynamically expanding) must be
backed up offline.
 How many Virtual Machines can be placed on the single CSV volume?
There are no limitations for the number of virtual machines that can be supported on a single
CSV volume. However, you should consider the number of virtual machines that you plan to
have in the cluster and the workload (I/O operations per second) for each virtual machine.
Consider the following examples:
 One organization is deploying virtual machines that will support a virtual desktop
infrastructure (VDI), which is a relatively light workload. The cluster uses high-
performance storage. The cluster administrator, after consulting with the storage
vendor, decides to place a relatively large number of virtual machines per CSV
volume.
 Another organization is deploying a large number of virtual machines that will support
a heavily used database application, which is a heavier workload. The cluster uses
lower-performing storage. The cluster administrator, after consulting with the storage
vendor, decides to place a relatively small number of virtual machines per CSV
volume.
 Is there a recommendation for creating VMs on CSV volume?
There is no hard & fast recommendation but, follow arrangement is recommended.
System files, including a page file, in a VHD file on one CSV Data files in a VHD file on another
CSV

12. What is VSS?
Volume Shadow Copy Service (VSS) is a feature of Microsoft Windows Server that coordinates
dataservers, backup applications, and storage management software to support the creation
and management of consistent backups.
VSS coordinates Snapshot copy-based backup and restore operations and includes these
components:
VSS Requestor:
The VSS requestor is a backup application, such as SnapManager for Hyper-V or Netbackup. It
initiates VSS backup and restore operations. The requestor also specifies Snapshot copy
attributes for backups it initiates.
VSS Writer:
The VSS writer owns and manages the data to be captured in the Snapshot copy. Microsoft
Hyper-V VSS Writer is an example of a VSS writer.
VSS provider:
The VSS provider is responsible for creating and managing the Snapshot copy. A provider can
be either a hardware provider or a software provider:
 What is a hardware provider?
A hardware provider integrates storage array-specific Snapshot copy and cloning functionality
into the VSS framework.
Note: 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 cannot delete that LUN by using the VSS Hardware
Provider.
 Why hardware provider is called hardware?
A provider that manages shadow copies at the hardware level by working in conjunction with
a hardware storage adapter or controller.
 Why software provider is called software?
A provider that intercepts I/O requests at the software level between the file system and the
volume manager.
 What is freeze during shadow copy creation?
Freeze is a period of time during the shadow copy creation process when all writers have
flushed their writes to the volumes and are not initiating additional writes.
 What is the purpose of hardware provider?
The Data ONTAP VSS Hardware Provider integrates the SnapDrive service and storage systems
running Data ONTAP into the VSS framework. This is required for VMs running on SANstorage.

13.  Do I need to download and the install hardware provider separately [NetApp
Specific]?
No! The Data ONTAP VSS Hardware Provider is installed automatically as part of the SnapDrive
software installation.
 How do I find out, if NetApp VSS Hardware provider installed?
On the HYPER-V host, where you have installed 'snapdrive', go to command prompt:
type –
c:>vssadmin list providers
The output should be similar to the following:
Provider name: ‘Data ONTAP VSS Hardware Provider’
Provider type: Hardware
Provider ID: {ddd3d232-a96f-4ac5-8f7b-250fd91fd102}
Version: 6.4.1.xxxx
 Is there a time limit for commiting a snapshot by provider in the VSS
framework?
VSS framework requires that the provider commit 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.
 What are the different types of VSS Hardware providers?
Tested hardware VSS providers table is provided in this link.
http://blogs.technet.com/b/dpm/archive/2010/02/05/tested-hardware-vss-provider-
table.aspx
 How to choose a backup vendor for HYPER-V?
When looking for backup software, make sure it states it supports Cluster Shared Volumes;
such as System Centre Data Protection Manager 2010, NetApp, Veeam & Altaro. Also, to
ensure the best performance backup, if you have hardware that supports Volume Shadow
Copy Service (VSS), make sure you have the VSS hardware provider installed on all nodes in
the cluster.
 In SMHV [SnapManager for HYPER-V], what is application-consistent backup?
Application-consistent backup jobs are thorough, reliable, and resource intensive. They are
performed in coordination with Microsoft Volume Shadow CopyService (VSS) to ensure that
each application running on the VM is quiesced before making a Snapshot copy. This backup
method guarantees application data consistency.
 In SMHV [SnapManager for HYPER-V], what is Crash-consistent backup?
Crash-consistent backup jobs are quick Snapshot copies of all the LUNs used by VMs involved
in a dataset. The resulting backup copies are similar to the data captures of VMs that crash or
are otherwise abruptly powered off. Crashconsistent backup jobs provide a quick way to
capture data, but the VMs must be present to be restored from a crash-consistent backup.
Crash-consistent backup jobs are not intended to replace application-consistent backup jobs.
A crash-consistent backup job makes only one Snapshot copy, always. It does not provide VSS
integration.

14. Cluster shared volume
CSV is a feature of failover clustering that was introduced in Windows Server 2008 R2. CSV
allows you to store multiple virtual machines running on multiple hosts in a cluster on a single
storage volume. A CSV is a shared single disk that contains an NTFS volume. Multiple virtual
machines can be stored on a CSV, and the CSV can be accessed by multiple Hyper-V host
servers installed on failover cluster nodes. You can have multiple CSVs in a Hyper-V cluster.
Typically, all of the virtual hard disks (VHDs) of virtual machines in the cluster are stored on a
common CSV, so that any node in the cluster can access the VHDs.
Note: CSV isn't referenced by a drive letter; it's a redirect point from
%SystemPartition%ClusterStorageVolumeX
As 'C: ' is used as the system drive most of the time, it basically translates to
C:ClusterStorageVolumeX
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.
Deploying Cluster Shared Volumes (CSV) in Windows Server 2008 R2 Failover Clustering:
http://blogs.msdn.com/b/clustering/archive/2009/02/19/9433146.aspx
Typical CSV diagram
CSV [Introduced in Windows 2008R2] Vs Physical disk resource [Used in Windows 2008]
http://blogs.msdn.com/b/clustering/archive/2009/03/02/9453288.aspx

15. What is Direct and Redirect I/O?
Each Hyper-V host has a direct path (direct I/O) to the CSV storage Logical Unit Number
(LUN). However, in Windows Server 2008 R2 there are a couple of limitations:
For some actions, such as backup, snapshot, de-frag [any low-level fileystem task] the CSV
coordinator takes control of the volume and uses redirected instead of direct I/O. With
redirection, storage operations are no longer through a host’s direct SAN connection, but are
instead routed through the CSV coordinator. This has a direct impact on performance.
CSV backup is serialized, so that only one virtual machine on a CSV is backed up at a time,
but this is only true if you are using VSS software provider. When using a hardware VSS backup
the volume only stays in redirected mode for a short period, i.e. during snapshot.
When a backup is initiated on a CSV volume, the volume is placed in Redirected Access mode.
The type of backup being executed determines how long a CSV volume stays in redirected
mode. If a software backup is being executed, the CSV volume remains in redirected mode
until the backup completes. If hardware snapshots are being used as part of the backup
process, the amount of time a CSV volume stays in redirected mode will be very short.
In Windows Server 2012, these limitations were removed: I/ORedirection is no longer used.

16. USEFUL LINKS
Overview of Processing a Backup under VSS
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384589(v=vs.85).aspx
Volume Shadow Copy Service
http://technet.microsoft.com/en-us/library/ee923636(v=ws.10).aspx
Cluster Shared Volumes in a Failover Cluster
http://technet.microsoft.com/en-us/library/jj612868.aspx
Cluster Shared Volume (CSV) Inside Out [Windows 2012]
http://blogs.msdn.com/b/clustering/archive/2013/12/02/10473247.aspx
What's New in Failover Clustering in Windows Server 2012
http://technet.microsoft.com/en-us/library/hh831414.aspx
SMHV: Virtual Machine backups take a long time to complete
Microsoft has released a hotfix to correct this issue and allow the Hyper-V Backup Integration
Services to utilize the native software provider for VSS.
http://support.microsoft.com/kb/975354
Note: This hotfix is also included in Windows 2008 R2 Service Pack 1
TR-4234: NetApp SnapManager 2.0 for Hyper-V on Data ONTAP Operating in 7-Mode Best
Practices Guide
https://fieldportal.netapp.com/Core/DownloadDoc.aspxdocumentID=107024&contentID=1694
44
NetApp Storage Best Practices for Microsoft Virtualization and NetApp SnapManagerfor HyperV
http://www.netapp.com/us/system/pdf-reader.aspx?m=tr-3702.pdf&cc=us
Cluster Shared Volumes
http://en.wikipedia.org/wiki/Cluster_Shared_Volumes
John Savill, Introduction to Cluster Shared Volumes
http://windowsitpro.com/windows-server-2008/q-i-am-using-cluster-shared-volumes-my-
windows-2008-r2-hyper-v-environment-how-s
Unable to access ClusterStorage folder on a passive node in a server 2008 R2 cluster:
http://support.microsoft.com/kb/2008795
MIGRATING VMWARE TO HYPER-V
https://gilgrossblog.wordpress.com/2014/02/19/migrating-vmware-to-hyper-v/

17. Good News on Veeam & NetApp collaboration [April, 2014]:
Veeam Software is collaborating with NetApp to create a new data protection solution for the
modern data centre to enable always-on business. [I am assuming this will allow Veeam to use
NetApp VSS Hardware Provider for storage snapshot].
This integration, according to the company, will bring together the low RPO enabled by
NetApp Snapshot, which lets enterprise IT back up the production environment to other
storage options every 15 minutes with no impact on performance, and the low recovery time
objective (RTO) capability enabled by Veeam Backup & Replication, whose Explorer for
Storage Snapshots provides quick and convenient item-level recovery from NetApp Snapshot,
SnapMirror and SnapVault.
For more info, go to this link:
http://go.veeam.com/v8-netapp
Courtesy: Veeam Backup & Replication for HYPER-V
http://helpcenter.veeam.com/backup/70/hyperv/backup_process.html
Courtesy: NetApp SnapManager for HYPER-V
Courtesy: Microsoft
Courtesy: http://en.wikipedia.org/
ashwinwriter@gmail.com
April, 2014