New VVOL Commands

I found this post lurking my drafts area, I probably should have renamed it newish commands now but the information is still relevant.

3PAR OS 3.2.1 MU2 saw the introduction of VVOLs support for 3PAR, this meant a number of additional commands were also added to the CLI:

setvasa – Set the VASA Provider server properties.

startvasa – Start the VASA Provider server to service HTTPS requests.

stopvasa – Stop the VASA Provider server from servicing HTTPS requests.

showvasa – Show properties of the VASA web service provider.

showvvolvm – Show information about virtual machines (VVol-based) in the system.

You can read more about VVOLs in my previous post and HP’s white paper.

3PAR VVOL Requirements

I had a great question in the comments last week asking what would happen in a situation where VVOLs was implemented on a system with no snapshot (virtual copy) facility licenced.  This prompted me to think it was worth while putting together a quick post around what the requirements for 3PAR and VVOLs are.

VVOLs were introduced with vSphere 6 and provide offloading of the grunt work to the storage device and a one to one relationship between VM’s and their storage.  If you need a reminder on what VVOLs are all about check out my previous post.

HP 3PAR support VMware support
OS requirements HP 3PAR OS 3.2.1 MU2Patch 12 vSphere 6.0, vCenter Server 6.0
GUI versions HP 3PAR MC 4.6.x vSphere Web Client 6.0
CLI HP 3PAR 3.2.1 CLI esxcli (vSphere 6.0)
Licensing HP 3PAR Virtual Copy vSphere Standard license
HP 3PAR Thin Provisioning vCenter Server Standard

The above table summarises the requirements.  First and most obviously you need vSphere 6 and this needs to be licenced at vSphere Standard level. From the 3PAR side of things you need to be running 3PAR OS 3.2.1 MU2 or above, this effectively means that VVOLs are only available on the 7000 and 10,000 series models. Patch 12 for 3.2.1 is also a mandatory requirement for VVOLs, this patch ensures the consistency of the VM’s, read more in the official release notes

The 3PAR also needs to be licenced for both Virtual Copy and Thin Provisioning (part of the base OS on current models).  So going back to the original question I was asked, VVOLs will not work without a snapshot licence.


You will also need to be mindfully that currently the following features are not supported with VVOLs

  • vSphere Metro Storage Cluster
  • Array-based replication is not supported i.e. in the case of 3PAR Remote Copy is not supported
  • No support for SRM

It’s worth noting that VVOLs and traditional VMFS datastores can co-exist on the same system.  So if for example the requirement for replication was only on some VM’s these could be kept on VMFS datastores allowing others without the requirement to be moved to VVOLs.

You can read more in-depth about 3PAR and VVOLs in the white paper –  Implementing VMware Virtual Volumes on HP 3PAR StoreServ



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



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.



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


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