vSphere 6, VVOLs and 3PAR

I have done several posts recently which have touched on VMware Virtual Volumes (VVOLs). Now that the dust has settled, I wanted to do a more detailed post to put all the pieces together and answer all the questions you may have about VVOLs and its function with 3PAR.

 

vSphere Storage Today

Today we take a LUN centric approach to storing VM’s in vSphere. On a 3PAR system you would create a virtual volume, then export this to your ESX hosts as a VLUN, this VLUN would then be formatted within vSphere with a VMFS file system to form a datastore. The diagram below represents the present situation, with a single LUN formatted as an VMFS datastore containing multiple VM’s.

The Need for Change

This is the way we have been working for years so what’s the challenges with this LUN centric approach.

  • Physical limitations – vSphere can only recognise up to 256 LUN’s per host
  • Disconnect between storage and VM admin. Storage guy talks LUN’s while the VM admin talks datastores
  • Lengthy provisioning cycles – First the LUN must be designed to meet needs of all VM’s, be provisioned in 3PAR, finally the VM admin needs to configure in VMware
  • Lack of granularity – LUN’s and datastore characteristics have to be designed to meet a broad range of requirements to suit all VM’s
  • Overprovisoning – As lots of VM’s are in the same container you have to over specify the space requirement for safety
  • Storage operations not offloaded – so operations such as snapshots and clones are performed by vSphere at the VM level. This approach does not optimise performance

In summary today we are bound by physical limitations, management complexity and a broad approach that’s defined by the storage characteristics

 

vSphere6

So what we need is something more granular, that workers closer with the storage to expose its capabilities and allows the VM’s to define their storage requirements in a policy driven manner. Well, with the launch of vSphere 6 and VVOLs, that’s exactly what we have got.

 

VVOL Architecture

As this is a completely new way of working with storage, let’s first understand the architecture and terminology of VVOLs. In vSphere 6 when provisioning a VM there is no need to first present the backend storage from 3PAR, just create the VM in vSphere which will then communicate utilising the VASA provider to create the necessary storage on 3PAR. VASA stands for vStorage APIs for Storage Awareness and allows the capabilities of the storage to be exposed to vSphere. When there is a storage request VASA acts as a broker between the storage and vSphere, for example when a VM says ”I want a snapshot”, the storage replies “hey take the weight off your feet good sir, allow me.”

 

The VVOLs created on the 3PAR have a one to one relationship with the disks created in the VM, so for example if you create a VM with 2 VMDK disks, two VVOLs will be created on the 3PAR to represent these. These VMDK VVOL’s are called data VVOLs. On top of this you also have Config, MEM, Other, and SWAP VVOL types to represent the other files that make up a VM. The diagram below shows the one to one mapping between VVOLs and VM’s.

VVOL storage

This one to one relationship between VVOLs and backend storage does away with the need for a VMFS system, with the VMDK effectively sitting directly on the storage. The building block within which all VVOLs must sit is called a storage container. A storage container is a logical construct on the storage system in which VVOLs with similar characteristics are placed. A minimum of one storage container is required and as initially the 3PAR only supports one storage container there are no great decisions to be made here.

Protocol end points are the logical access points that enable data path communication between the storage system and vSphere.  All communications to VVOLs will not be direct to the VVOLs themselves but via the protocol end point.

 

Summary

To summarise a separate container is created for each file type that makes up the VM direct on the storage as a VVOL, the VVOLs are grouped together in a storage container, communications to the VVOL is via the storage end point and the capabilities of the array are exposed via VASA.

VVOL Advantages

  • More granular approach – since each VMDK exists on its own virtual volume, availability and performance requirements can be very granular. Also reduces the need to over provision storage
  • No LUN limitations – The 256 limit imposed by LUN’s is banished
  • Quick provisioning cycle  Can all be handled by a single person from within the vSphere console
  • Offloading to storage – VVOLs let the storage do what its best at, so snapshots clones etc. are performed by the storage on behalf of vSphere
  • Common language – the VM admin can talk direct to the storage admin about VVOLs without having to translate datastores to LUNs
  • Policy driven – When creating the VM administrators can choose the class of service they require from the storage for each disk.  For example a VM disk housing a database could be set to use flash disk that supported replication and snapshots whilst a disk from the same VM only used for backups could sit on NL disk with no additional features.

 

All of these features allow us to overcome the challenges we identified earlier to allow a more granular, policy driven approach with the grunt work offloaded to the storage

VVOL and 3PAR

The good news for 3PAR owners is that HP have been working with VMware on VVOLs since day 1, the 3PAR was actually the reference device for Fibre Channel and VVOLs, so has undergone extensive testing. Whilst some vendors will require additional installs to accommodate VVOLs 3PAR has it baked into the code and will be available to all those running the 7000 and 10,000 systems with 3PAR OS 3.2.1 MU2. VVOLs are included with vSphere 6 which is expected in quarter one of 2015. To read more about how 3PAR and VVOLs will work together check this post and also this post which deals with requirements for VVOls.

 

The only thing I think HP will have to review is their naming convention for LUN’s. I think they are going to have to admit defeat with both themselves and now VMware using the term virtual volumes.

 

To stay in touch with more 3PAR news and tips connect with me on LinkedIn and Twitter.

 

Further Resources

3ParDude 3PAR VVOL Requirements

3ParDude VMware VVOLs and HP 3PAR Part Deux

Calvin Zito 3PAR and VVOLs Video Demo

Bart Heungens VMware vSphere 6.0 VVols available on HP 3PAR

Eric Siebert VMware VVOLs is coming. Will your storage be ready for it? HP 3PAR StoreServ will be!

Eric Siebert Got VVOLs? If you have 3PAR StoreServ you do

Published by

15 thoughts on “vSphere 6, VVOLs and 3PAR

  1. Hi, I assume another advantage with vVOLs, is that you don’t have to shutdown your VM to extend a vmdk which is above 2TB as the limitation is now determinded by the storage array and not VMware. Is this correct?

  2. 3Pardude – correct me if I am wrong, but the one thing that NO ONE has said or talked about yet that I’ve seen in regards to 3Par and VVols (including HP), is virtual machine snapshots. If I’m not mistaken, vSphere 6 when used in conjunction with VVols offloads all VM snapshots to the 3Par to handle as array based snapshots. The last time I checked, array based snapshots are not part of the the base 3Par Operating System Software Suite license. Therefore, while you can enable VVols with vSphere 6 and 3Par, unless you have a Virtual Copy license, you lose the ability to take VM snapshots with vSphere 6, 3Par, and VVols. This will be a show stopper in my opinion in the adoption of VVols if my licensing assumptions are correct.

    1. The max number of VM’s on a 3PAR 7400 is 1500. Currently you can only create one container hence the max per container is effectively 1500 VM’s

  3. Any hints you can give to troubleshoot the PE not being present from host side?

    The VASA part is online but the host dies not see the PE.

    Running Cisco UCS, adapter firmware 4.0(8) with esx driver 1.6.0.17a

  4. I just came across another missing feature of VVol’s. You cannot migrate a VM from one storage policy to another with VMWare. Say you want to migrate the VM from NL to FC disks, you cannot do this without migrating back to a VMFS volume first and then into the new storage policy. Not sure if this is a 3Par feature or VMWare…or both I guess…

  5. I am trying to find out how vvols work in conjunction with AO. In VMware I am asked to create my 3 tiers of storage via storage policy. This seems to work against AO. Am I missing something?

  6. I did play around with this a few months ago, and I was running the latest version of the 3par OS at the time. And the basic answer I got at the time was that it supported AO, but in a weird way. ie. It wouldn’t actually report on it, which they were fixing. And that it didn’t support RemoteCopy (which kills it for me, till they get it fixed)
    It was a little disconcerting that I couldn’t see the container via the mgmt console at the time as well (granted I could see if via the cli) I think they’ve fixed this in the newer mgmt consoles but from what I heard the reporting isn’t fully there yet. It’d be nice if HP/vmware posted the limitations that certain vvol implementations had. It took me digging all over the place to get a straight answer and even then it was best guesses.

Leave a Reply

Your email address will not be published. Required fields are marked *