I’ve been collecting VVols information and links to add to my VVols link page and ran across some interesting items that I thought I would share. Let’s start with events:
- Taneja is doing a deep dive webinar with Dell into their implementation on VVols on May 14th at 9:00am PST as a follow-up to the other VVols webinars that they have done with a group of partners as a panel and with VMware. Look for me to be participating in one as well soon representing HP.
- Tintri is doing a VVol webinar this week entitled “Top 5 VVOLs Myths and Misconceptions”, I don’t know that there are many myths about VVols floating around but I am sure there are some misconceptions so you might check it out. As Tintri touts their storage as being able to work at the VM level without VVols I’m sure the myths might be tied to that in an effort to promote their implementation. This one is also on May 14th at 9:00am PST so you’ll have to pick which one you want to watch live.
- NexGen is doing a series of events in various cities from May 19th – June 24th with storage veteran Howard Marks entitled “Putting VVols to work – Storage Best Practices for vSphere 6 and Beyond”. If Howard is doing these they have to be good so be sure and attend if it comes to a city near you, right now they have listed Dallas, San Diego, New York, Atlanta, Seattle, Santa Clara and Denver.
Now for some other VVol info:
- VMware has just published a new KB article detailing interoperability between VAAI offloads and VVols storage. It’s a bit short as it summarizes it, you can find a much more detailed version of it in this blog post from Rawlinson at VMware.
- VMware has published another KB article that details how UNMAP works with VVols, however it might not be what you think. With VVols there is no longer the need to perform UNMAP operations as was necessary with VMFS using the vmkfstools and esxcli commands as the storage array sees VMs as objects and knows when they are deleted or moved so it can automatically reclaim that space. This KB article covers UNMAP from within the guest OS which is now possible as UNMAP commands initiated by a guest OS that supports UNMAP are passed back to the storage array to be reclaimed. I asked Cormac Hogan at VMware about this about a year ago and he confirmed this would work but know we have confirmation of it. In addition this apparently works with VMFS as well now in vSphere 6 as Cormac details in this blog post.
- Veeam announced that they now fully support vSphere 6 and VVols with their new Update 2, so naturally I was curious and tried to find out more detail around their VVol support. They have listed as a new feature “Quick Migration to VVol datastores”, right now the only migration path from VMFS to VVols is using Storage vMotion so it sounds like they are doing something similar to copy a VM from VMFS to VVols. The Veeam Quick Migration feature is not a live migration like a Storage vMotion so there is a brief disruption as they pause the VM after it is copied and then resume it. I’m guessing they are using the vSphere 6 VDDK which now supports VVols to be able to do this as I don’t think they can have a backup appliance connect directly to a storage array using a Protocol Endpoint similar to the Direct to SAN method in VADP. I’ve reached out to Rick Vanover to clarify their support for VVols and how it impact’s their Direct to SAN backup method.
- Still only 7 vendors listed in the VMware HCG for VVols support, I wonder when EMC, Dell, Pure and others will finally join the VVol support club.
That’s all for now, read lots more about VVols in my ever growing VVols link page.
Update from Rick Vanover at Veeam:
1) Does this mean you support the Direct to SAN method to backup a VM that is in a VVol storage container? If so are you establishing a protocol endpoint from your backup appliance/VM to the storage device?
>> Hot Add and NBD only. This is due to the VDDK capabilities.
2) What’s your quick migration method from VMFS to VVols? As it stands Storage vMotion is the only way to move a VM to VVols, are you simply doing a backup/restore or something else? Is this cold or hot?
>> VVols or VMFS makes no difference as VDDK abstracts that for us, so our prior logic still applies. In short, we create a new VM and stuff its virtual disks with data from the source VM (same as our replication jobs do). Migration “temperature” will depend on migration scenario and engine used: hot for VMotion, “warm” for Smart Switch, cold in other cases.