Backing Up Virtual Volumes (vVols)

As the end of general support for vSphere 5.5 approaches and customers plan their migrations, the amount of customer vVols conversations I’m having has significantly increased.  As a fair portion of these conversations involves data protection, I thought it would be appropriate to update my previous post on Backing up vVols.

Does migrating to vVols affect my backup and recovery design? That depends. In many cases no, however, depending on the VMware transport mode used (more on that later), you may or may not have to redesign your backup architecture. Backup software using VADP is for the most part unaffected. Virtual Volumes are modeled in vSphere exactly as today’s virtual disks. The VADP APIs used by backup vendors are fully supported on vVols just as they are on vmdk files on a LUN. Snapshots created by backup software using VADP will look the same to both vSphere and the backup software as non-vVols based snapshots, however, on-array the snapshots are actually vVol objects.

How vVols enhances snapshots.

It’s no secret that historically, VM snapshots have left a lot to be desired. So much so, that GSS best practices for VM snapshots as per KB article 1025279 recommends having no more than 2-3 snapshots in a chain (even though the maximum is 32) and not to use a snapshot for more than 24-72 hours.

With vVols, several things change.  vVols mitigate these restrictions significantly, not just because snapshots can be offloaded to the array, but also in the way “consolidate” and “revert” operations are implemented. For starters, the base VMDK is always the base VMDK.  It is always the write target. Instead of writing to the redo log, the snapshots are now read-only reference files that do not exist within a chain. Because of this, when the snap is reverted or deleted, there’s nothing to ingest back into the base VMDK, because it already has everything.  This change alone has significantly enhanced the performance and usability of VMware snapshots. See Cormac Hogan’s detailed explanation of how vVols presents A new way of doing snapshots

Since both “managed-snapshots”  (VMware snapshots with a 32 snapshots-in-a-chain limit) and “unmanaged-snapshots” (array snapshots with vendor-specific limits) are offloaded to the array, there is no longer a reason not to utilize the full 32 managed-snapshots.

Change Block Tracking

When a VM residing on a vVol datastore is migrated using vMotion by either DRS or manually and the VM has Change Block Tracking (CBT) enabled, you may experience a corruption of data/backups/replicas and/or performance degradation. This issue has been resolved and the fix will be available in all VMware vSphere 6.0.x, 6.5.x and 6.7.x future releases. To work around this issue, disable DRS for VMs residing on a vVols datastore. Whenever a manual vMotion is necessary, after the vMotion, reset CBT and do a full backup. See KB55800 for more detail.

VMware vStorage APIs for Data Protection

vVols supports backup software that uses vSphere APIs for Data Protection (VADP). Originally introduced in vSphere 4.0, VADP enables backup products to do centralized, efficient, off-host LAN free backup of vSphere virtual machines.

A backup product using VADP can backup vSphere virtual machines from a central backup server or virtual machine without requiring backup agents or requiring backup processing to be done inside each guest virtual machine on the ESXi host. This offloads backup processing from the ESXi hosts and reduces costs by allowing each ESXi host to run more virtual machines.

VADP leverages the snapshot capabilities of VMware vSphere to enable backup across SAN without requiring downtime for virtual machines. As a result, backups can be performed non-disruptively at any time of the day without requiring extended backup windows and the downtime to applications and users associated with backup windows.

Supported VMware Transport Modes

A VMware Backup Host can access Virtual Machine data from datastores using four different methods – SAN, LAN(NBD), HotAdd and NBDSSL. These methods are referred to as VMware Transport modes.

• SCSI HotAdd: Supported with vVols

When running VMware Backup Host on a Virtual Machine, vStorage APIs can take advantage of the SCSI Hot-add capability of the ESXi server to attach the VMDKs of a Virtual Machine being backed up to the VMware Backup Host. This is referred to as HotAdd transport mode. With vVols, the backup proxy is a VM, and the snapshots that are to be backed up are attached in something of a “read-only” mode* to the backup proxy as a virtual scsi disk. 

* It is not exactly read-only mode, it is attached as an independent nonpersistent disk, which means that any writes to this “read-only” vVol object are redirected to a temporary object that gets destroyed when the VM is powered off or the disk is removed.

• Network Block Device (NBD): Supported with vVols

In this mode, the ESX/ESXi host reads data from storage and sends it across a network to the VMware Backup Host. As its name implies, this transport mode is not LAN‐free, unlike SAN transport. This method is not as efficient as it uses the network stack instead of the storage stack.

• NBDSSL: Supported with vVols

NBDSSL is the same as NBD, except that NBDSSL uses SSL to encrypt all data passed over the TCP/IP connection.

• SAN Transport Mode: Not Supported with vVols

For today’s VMFS disks, SAN transport mode relies on a proxy VM to tell the backup appliance which blocks it should read (since the Windows OS on the backup system can’t directly mount a VMFS disk). vVols uses the VASA API to establish a “binding” between the ESXi host and the VASA provider, which not only instructs the VASA provider to “construct” a data path for the vVol for the ESXi host, but also provides the requisite information needed by the ESX host to construct the data path on the ESXi side.  Because physical backup proxies cannot be VASA clients, currently, it is impossible to construct a “direct” data path between the vVols storage and the Physical Backup Proxy.

What backup software vendors support vVols?

Note: This is not an exhaustive list, rather just a collection of vendors that I am aware of.  If you know of others please share and I will update the post. Always check with your backup vendor for the latest details on versions and support.

*IBM “Tivoli Storage Manager” was renamed at 7.1.3 to “Spectrum Protect”, the last TSM version being 7.1.2. Spectrum Protect is the same product and SP 7.1.3-8.1.6 does support vVols.

Protecting the VASA Provider

The VASA Provider (VP) is a software component that manages all aspects of vVols storage. It makes vCenter aware of the vVols objects and their capabilities. It also communicates VM storage requirements to the underlying storage in the form of VM Storage Policies. For many storage vendors, the VP is integrated into the OS of the array, however, there are some that deploy the VP in a VM as a virtual appliance.

So what does it mean when a backup software product supports vVols? In addition to backing up vVols objects, the VP, when deployed in a vApp, should also be protected. This, of course, does not apply to VPs integrated into the array’s OS.

What happens if the VASA Provider disappears? The VP database contains information about all the storage capability profiles that have been established and the mappings for the storage container. In the event that either the vCenter server or the VP is unavailable, the data still resides natively on the array and VMs continue to run but there will be no management. More importantly, without the VP the vVols structure would be lost.

The good news is most vendors using vApps for the VP have incorporated some disaster recovery and\or High Availability to prevent such a catastrophe.  There is a subtle difference from “VP HA” and “vSphere HA”.  VP HA is where multiple instances of the VP are up and running, possibly coordinating with each other as changes are made.  That lets vCenter then switch from one VP to another VP instance without losing manageability.  vSphere HA triggers a restart of the VP VM on another host, which requires the same VM disks to be available and doesn’t help in case of corruption of any internal databases. Be sure to check with your storage vendor for details on their VASA Provider.

For more information on Virtual Volumes please refer to the following resources:

• vVol enhancements in vSphere 6.7
• vVols support for Windows Server Failover Cluster (WSFC)
• VMware vSphere Virtual Volumes FAQs
• Getting Started with vVols
• Benefits of Virtual Volumes
• More vVols Snapshot Goodness
• vVols for Database Backup and Recovery

In summary, the list of backup vendors supporting vVols is growing, and since the VADP APIs used by backup vendors are fully supported, backing up vVols is business as usual. In addition, the enhancement of Snapshots makes vVols even more compelling.