VVol Data Mobility: Data from Virtual to Physical

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:

1. Take a RDM and make it a VVol
2. Take a VVol and present it to an older VMware environment as a RDM
3. Take a VVol and present it, or a copy of it, to a physical server.
4. 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:

Comparing VVols to VMDKs and RDMs

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:

Then I Storage vMotion it to a VVol datastore, this turns it into a VVol VM:Choose storage migration:

Choose a VVol datastore: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.

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:

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.

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 search for my volume called “windowsBoot” and select it and click Connect.

Now it is connected, and as LUN 1 too.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.

Booted!

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: