Tech Tap

Recently, I was surprised to learn that you cannot create a Veeam replication job to VMware Virtual Volumes (VVols). This highlights that we always need to be thorough when performing one of the most difficult tasks in the design process. That task is confirming the compatibility of all components in a virtualized infrastructure.

In these times of “get it done quickly” IT, people tend to have a ready–shoot – aim methodology. Following a proper methodology, including assessment and design, will keep you out of trouble in these situations.

Because of the surprise with Veeam, I did a little digging to see what is and is not compatible with VVols. This was not an easy task.

VMware Compatibility

VMware provides a FAQ knowledge-base article around interoperability. The KB is a little confusing because it calls out ESXi 6.0.x and not 6.5 (https://kb.vmware.com/kb/2112039), however, this appears to be the most current FAQ. As of this post, several significant items appear to be not compatible with VVols, such as fault tolerance, NFS v4.1, and raw device mappings (RDMs).

VMware heralded that replication is now supported in VVols under vSphere 6.5. This is true in the mind of the marketing department. When you dig into the details, array-based replication and vSphere replication are certainly supported using VVols. Even VMware Site Recovery Manager (SRM) 6.5 supports VVols, which was also heralded by VMware. However, SRM is only supported when using vSphere replication (https://storagehub.vmware.com/#!/virtual-volumes-5/vsphere-virtual-volumes-technical-overview/interoperability). After further digging, we find that vSphere Replication does not support VSS quiescing on Virtual Volumes (https://www.vmware.com/support/vsphere-replication/doc/vsphere-replication-60-release-notes.html#caveats). The lack of VSS quiescing means you get a crash-consistent backup, which may or may not be important to you.

VMware’s site includes links to documents published in 2015 and I really couldn’t find anything referencing version 6.5 specifically. The Storage Hub site, referenced above, seemed to provide the most up-to-date information, but I am not sure if it the “official” document ton show supportability.

Clear as mud.

Veeam Compatibility

In a nutshell, Veeam uses snapshots when restoring replicated files. This method is considered a layering violation and throws and error on many VVol storage devices. This is documented in the latest VDDK release notes (http://pubs.vmware.com/Release_Notes/en/developer/vddk/65/vsphere-vddk-65-release-notes.html)

“Avoid creating snapshots for restore on VVol datastores. Due to Virtual Volume (VVol) implementation in the vSphere 6.0 release, VMware recommends against creating a snapshot (then reverting and deleting it) when restoring files on a VVol datastore. This is because writing to a non-leaf disk (such as a snapshot backing file) is considered a layering violation and throws an error on many VVol storage devices. Writing to the leaf disk of the snapshot is not a layering violation. The restore snapshot remains mandatory for SAN transport, which is not supported on VVol datastores anyway.”

Veeam published a knowledge base article in January 2017 stating that replication jobs to VVols are no longer supported (https://www.veeam.com/kb2022).

A Google search for Veeam and VVols also delivers a Veeam blog post about backing up virtual machines with storage policy-based management (SPBM) (https://www.veeam.com/blog/vsan-vvols-storage-backup-policy-management.html). Since this post was made in July 2016, it may or may not still be true.

Zerto Compatibility

According to the latest Zerto Virtual Replication Interoperability Matrix, VVols are not supported (http://s3.amazonaws.com/zertodownload_docs/Latest/Zerto%20Virtual%20Replication%20Operability%20Matrix.pdf).

RecoverPoint Compatibility

According to the EMC Simple Support Matrix for RecoverPoint for Virtual Machines, VVols are supported for user volumes only (https://support.emc.com/docu79521_RecoverPoint-for-Virtual-Machines-5.0-Simple-Support-Matrix.pdf?language=en_US).

According to the EMC Simple Support Matrix for RecoverPoint Classic, VVols are NOT listed as being supported (https://support.emc.com/docu79520_RecoverPoint-Classic-5.0-Simple-Support-Matrix.pdf?language=en_US). It doesn’t say they are not supported, they are just not mentioned.

Conclusion

Back when I spent time convincing people that vMotion was not voodoo magic, VMware had a published methodology called the VMware Virtual Infrastructure Methodology (VIM) (https://www.scribd.com/document/211737222/Vim-DatasheeT). The steps were simple: Assess, Plan, Build, and Manage. It was even on the old VMware Certified Professional (VCP) exam as I recall. You need to start there. More recently, VMware has started following the Zachman Framework  (https://en.wikipedia.org/wiki/Zachman_Framework). The bottom line is that you need to follow a methodology when it comes to deploying the environment that will house your business-critical applications and avoid the ready – shoot – aim methodology.

The assess and design stages are where you decide your requirements and constraints for your environment. This is the time to decide which features you wish to use and document the justification to use or not use those features. If it is too late, and you are stuck in that ready – shoot – aim situation, you still must decide which features are most desired, but you may also need to roll back a production implementation in the process.

There’s probably no fun in that.