December 20, 2024

Are vVols an Easy Way off of vSphere?

I remember when  vVols were introduced over a decade ago. To me, the promise of getting all the array side benefits of native volumes with the flexibility of traditional vSphere provisioning and management was a very revolutionary approach.

Anyone who is familiar with the history of vVols knows that they did a have a rocky start, especially since they were introduced in a similar timeframe as vSAN.

Having worked at VMware during that time, I did see the adoption of vVols rise, especially once storage vendors decided to embrace them and VMware decided to develop replication and SRM support.

With the current climate around the changes since VMware was purchased, I started thinking about it…

For the VMware customers who have decided to implement vVols, the technology might be somewhat of an easy button to move data from vSphere to an alternate hypervisor (or even back to bare metal).

I say this, because the idea of vVols is to present array volumes, with some metadata/mapping to vSphere through the VASA service.

Ultimately a vVol volume is a volume that contains the native file system of the virtual machine it is being presented to.

So… A vVol volume could be copied to another volume and that volume could be presented as a passthrough disk to an alternate hypervisor or bare metal server.

I tried this out recently with a Windows system with the  Hyper-V role and the migration was pretty painless. The HyperV VM had a passthrough disk, but Hyper-V also has a native workflow to convert a passthrough disk to a .vhdx.

And yes, this requires some downtime, but what’s the downtime cost vs other costs?

The process

  1. The VMware VM needs to be deployed to a vVol datastore.
  2. Determine the volume(s) you want to make copies of to present to your alternate hypervisor.
  3. The volumes could be snapped (VM off or running with “crash consistency”)
  4. Present those volumes to your alternate Hypervisor host (as you would an RDM to one or more vSphere hosts)
  5. Create a VM on the alternate hypervisor’s platform and attach the volume as you would a passthrough disk.
  6. Ensure the VM’s configuration (cpu, ram, networking) matches the original VMware VM’s configuration.
  7. Power on the VM.

My experience

Step 1 & 2. I took a VM on a vVol datastore and determined the volume (C: drive here) I needed a copy of

On my system, the C: drive of my Windows VM is a volume named Data-b4d8d085 in the vvol-WINDOWS-4ed98cd0-vg volume group on my array. *Different platforms will have different methods to see this

Step 3. Took a snapshot of the volume (C: drive here)

Using the vSphere tools I have for my platform, I created a snapshot of the C: drive volume. *Different platforms will have different methods for this

Step 4. Copied that snapshot to a new volume

*Different platforms will have different methods for this

Step 5. Attached that new volume to my Hyper-V host

*Different platforms will have different methods for this

My Hyper-V host was already configured to use iSCSI to connect to my array, and it automatically showed up upon being presented.

Step 6. Created a VM on my host with the Hyper-V role


Name and Location

Generation 2 for SCSI disks

Don’t add a disk

Finish

Notice that I did not add a hard disk yet. I’ll add the local volume as a passthrough disk in the next step.

Step 7. Modified the VM’s configuration

Select the Passthrough Disk Disable Checkpoints

Step 8. Powered on the VM.

Some things to consider

  • VMware tools are very hard to remove once a Windows VM has been brought into Hyper-V.
    There are a few mechanisms to remove them afterwards, but removing them before the migration is easiest.
  • The Hyper-V VM is using a passthrough disk. If passthrough disks aren’t desired, you’ll need to determine what the migration process is in your alternate hypervisor. Fortunately Hyper-V makes it easy to migrate a passthrough disk to a vhdx, albeit offline.

 

Summary

This manual process shows that a VMware vSphere VM residing on vVols can be easily migrated to an alternate platform. With a little elbow grease and some time, this could be scripted if the platforms you’re using support automation tools like PowerShell or others.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.