Paul Morrissey

Hitachi and VMware Virtual Volumes - Part 3

Blog Post created by Paul Morrissey Employee on Mar 27, 2015

This is a the third and final part in a series of blog posts where I've addressed the many questions that have arisen (so far) with respect to Virtual Volumes and Hitachi implementation in delivering VMware vSphere Virtual Volumes (VVol)  and the Storage Policy Based Management (SPBM) framework.  Part 1 of this blog series is here and part 2 is here


Ok, Let's check the outstanding questions..

  • You mentioned the storage capabilities that Hitachi will support. How do I as a storage admin define those

Below is a screenshot of the interface within Hitachi Command Suite (HCS) dedicated to Storage Container/SPBM aspects. You (as part of storage or infrastructure team) can leverage this interface to define the capabilities on the individual storage resources within the storage container(s). In the example below, the storage admin has identified that his storage resource can advertise that it will support  maximum of Tier 2 performance class and Tier 2 availability class , minimum cost of 500 etc. The system auto determines the other capabilities such as encryption and RAID level if VM admin wants to leverage in their VM storage policies


cap profile.png

  • As a VM admin, how do I access these capabilities

Below is a screenshot of the vSphere web client where VM admins can create VM storage policies. In the example (pulled from the video below), the VM admin has decided to create a standard VM storage policy that all production Oracle databases for example being deployed must leverage this policy. The policy states that VMs get Tier 1 performance, and either Tier 1 or Tier 2 availability with no restriction in the cost of the storage resource being allocated.

storage policy.png

  • How many Virtual Volumes will be created for a VM?

At least three and potentially more depending on VM configuration. There is a Virtual Volume for every virtual disk, one Virtual Volume for swap if needed, and one Virtual Volume per disk snapshot and one per memory snapshot. The minimum is typically three Virtual Volumes/VMs (one config, one data, one swap). Each VM snapshot would add one virtual disk and one memory snapshot (if requested)

  • Will VMFS cease to exist after introduction on VVol?

For VVol, there is no concept of VMFS as you know it today as a hypervisor based shared filesystem. With VVol, vCenter is communicating with VMDK storage and previous operations that used to occur in the hypervisor/VMFS (such as snapshot), are now handled by the storage array. Obviously, VMFS will continue to co-exist with VVol to continue to support traditional VMFS datastores.


  • If the VP dies, do we just lose the ability to do  provisioning etc. or do we lose access to existing VMs

If VP is unavailable, only storage management operations will be impacted (create, clone, snapshot, power off). HDS will be deploying VP in N+1 model for higher availability. VP down situation does not impact VM as data I/O flows through PE(s)

  • When will VVol get SRM support?

VMware has stated that SRM support is not in initial release with premise that it will be delivered in subsequent release. An important point:- This does not mean that replication is not supported as some incorrectly make the leap. i.e Existing Hitachi replication technologies such as HUR, True Copy (TC) and/or FileObject Replication still provides offsite DR backup for VVol between Hitachi platforms. Customers will have to wait for VMware to update SRM to add the orchestration layer for those who use that offering for orchestration.


  • Will VVol have different way of handling VM snapshot/backup/restore history during vMotion event?

Yes, VVol will preserve and move associated snapshots even with Storage vMotion events. This is another benefit of having VMDK based storage


  • Will your backup and recovery solution Virtual Infrastructure Integrator (V2I) support VVol objects?

V2I in addition to HDID will be key differentiator for HDS , allowing customers to benefit from specified data protection as part of the provisioning process while benefiting from enhanced automated backup and recovery of VMs in granular manner. This is one area I'm particularly intrigued with as we will eliminate the challenges that VMware environments have experienced with hypervisor based snapshots and subsequent disk consolidation of delta snapshots which can cause havoc.  Now, vCenter initiated snapshot and clone operations offloaded natively to Hitachi arrays in the initial release. The actual V2I managed integration will be in subsequent release after the initial release.

v2i and vvol.png


  • We touched on Storage Policy Based Management (SPBM) in Part 2 of blog and made reference to demo video of Hitachi VVol with SPBM? Is that available

Yes, we have a couple of video but here is the most recent video which I recommend viewing. The actual demo starts around 2:45 but initial part of video is refresher on implementation



  • What is the Hitachi Data Systems plan  for supporting VVol in its arrays?

HDS will support VVol with both HNAS and VSP G1000 systems in 1H2015 and Gx00 in 2H2015. Expect to see GA announcements starting in April time-frame. We are currently in early access phase so if you would like to be put on the list, see below

  • What licensing is required in getting VVol support in arrays?

VVol management framework will be offered as no charge item. (i.e No licensing fee for Hitachi VASA provider). Customer needs to ensure they have the appropriate Hitachi platform that supports VVol (i.e VSP G1000 class systems and/or HNAS Gateway) For other or older Hitachi Storage platforms (HUS VM, VSP, HUS 100 series) or indeed 3rd party storage, we provide option to virtualize with VSP G1000 or virtualize with HNAS 4000 Cluster gateway to surface VVol support

  • My interest is piqued. I would like to be among the first and/or get more information

         Pop your name and relevant information here. Put VVol as part of description


Thank you for reading.  I look forward to seeing how this journey towards VMDK storage and the all important gracefully managed mapping of data services and capabilities via storage policy based management framework helps customers move towards to their goal of an efficient reliable automated cloud infrastructure, be it deployed with Hitachi or otherwise. Keep the great questions coming