The Pure Good Foundation was established in late 2015 with the mission to accelerate positive change by harnessing the power of people, technology, and community to uplift communities ...
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:
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:
Let’s use Windows as an example.
I have a VM running on VMFS:
Choose storage migration:
The VMFS to VVol conversion is super fast, as it is on the same array, so it uses XCOPY.
The VM is now made of VVols as it is on a VVol datastore:
If we look on the array, the VM is now made of VVols, a config VVol, a data VVol (only have one virtual disk, so just one data VVol) and a swap VVol.
Now let’s look at the VM in the console.
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:
Now the snapshot is created in VMware:
But since it is a VVol, it is actually an array snapshot of that virtual disk. So let’s go to the array.
The snapshot is an array-based snapshot of my data VVol:
My physical host is a UCS M series blade, with boot from SAN configured. I currently have no volume connected to it.
Let’s take that snapshot and create a volume out of it and present it to my UCS server.
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 search for my volume called “windowsBoot” and select it and click Connect.
Now I will go over to my KVM and boot up the UCS blade.
Now wait for the boot process.
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.
And the file is there!
I also have a Linux VM that is VVol-based. If I copy the data VVol and overwrite the windowsBoot volume that I am booting from:
The UCS blade is now Ubuntu!
This is just a simple example of how VVols open up data mobility. Stay tuned to my blog for many more, much cooler examples of how this characteristic of VVols can be leveraged even further.
See a video demo of the process here: