One of the most strategic benefits of Virtual Volumes is how it opens up your data mobility. Because there is no more VMDK encapsulation, VVols are just block volumes with whatever file system your guest OS in the VM puts on it. So a VVol is really just a volume hosting NTFS, or XFS or whatever. So if a target can read that file system, it can use that VVol. It does not have to be a VMware VM.
Let me start out with: YES our VVols deployment will be GA VERY soon. I am sorry (but not really) for continuing to tease VVols here.
This is one of the reasons we do not treat VVols on the FlashArray any differently than any other volume–because they aren’t different! So there is no reason you can’t move the data around. So why block it??
Some possibilities this function opens us:
- Take a RDM and make it a VVol
- Take a VVol and present it to an older VMware environment as a RDM
- Take a VVol and present it, or a copy of it, to a physical server.
- On the FlashArray we are also introducing something called CloudSnap, which will let you take snapshots of volumes (aka VVols) and send them to NFS, or S3 to be brought up as a EBS volume for an EC2 instance.
So much more. A lot of cool possibilities. So let’s dig into one now.
Virtual to physical.
There are still unfortunately some situations where vendors require customers to re-create issues on physical hardware if it is running on a hypervisor. Or sometimes, due to licensing reasons some parts of environments are virtual, some are physical. Etc.
Sharing data between physical and virtual is not always a easy process. Usually you have to use RDMs, which means you lose all of the benefits of VMware; cloning, Storage vMotion, ease of provisioning, built-in VMware snapshots, etc.
This is not a trade-off you have to make with VVols. Since each virtual disk is a volume on the array, you can literally take that virtual disk (the array volume) and present it to a physical server. Or copy it on the array and present it to a physical server. This allows you to copy, or share data between virtual and physical without the penalty of using RDMs, but still get all of the benefits of virtual disks PLUS all of the benefits of VVols. See this post for more benefits:
Simply copying a data volume is easy, but what about booting? Can I literally take my data VVol that holds my OS in a VM on a VVol and boot it up on a physical server?
Yes! Let’s prove it out.
The process will be:
- Take a VM on VMFS and Storage vMotion it to VVols
- Clone the data VVol of the VM and present it to a physical server as a regular LUN
- Boot up the physical server
Let’s use Windows as an example.
I have a VM running on VMFS:
And just do something simple like create a text file on the desktop. Add some text:Now I can either shut this down and present it to my physical server, or I can copy it and present a copy. Let’s do that latter here. Since it is a VVol, I can use vSphere to create the array snapshot, so click on the VM and take a snapshot.And take the snapshot:
The snapshot is an array-based snapshot of my data VVol:
Then create a new copy. On the FlashArray this is just a 100% deduped meta data copy, so there is no capacity hit and it takes less than a second to copy.Now to connect it to my UCS blade. My blade is configured to connect to LUN 1 for boot, so I will make sure that is the case. The first volume connected defaults to that, so it will be good.
Now depending on your server vendor and OS, you might need to load drivers for the HBAs. For Windows and UCS, I had to. For Ubuntu (for instance) and UCS, I did not have to load any special drivers. So if it fails to boot, that is the problem.
See a video demo of the process here: