V2V Migration to OpenStack — From Any Source
Migrate VMware, Citrix Hypervisor, and XCP-ng workloads to OpenStack using the backups you already run. No separate migration appliance, no in-guest agents, no coverage gap — the platform that protects your VMs today carries them across and keeps protecting them after.
Key Highlights
One platform, two jobs
Backup and migration run from the same platform. Your existing restore points are the migration source — no point tool to license, learn, or maintain.
Agentless at the source
Migration runs through hypervisor APIs. Nothing is installed inside the guest on VMware, Citrix Hypervisor, or XCP-ng.
No protection gap
Workloads stay protected before, during, and after the move. Migration is a restore, not a leap of faith — if validation fails, the source is untouched.
One universal license
Source and target are covered under a single SKU. No per-VM migration fees, no separate migration product, no feature tier to unlock.
Powerful V2V Migration Capabilities
Backup-driven migration engine
VMware, Citrix Hypervisor, and XCP-ng backups are restored directly into OpenStack. No intermediary conversion appliance, no manual virt-v2v/qemu-img pipeline to stand up and babysit.
Built-in disk format conversion
Source disks (VMDK / VHD / XVA) are converted to QCOW2 or RAW during the restore, with guest driver injection and resource mapping — handled inside the workflow, not as a separate manual step.
Guided migration wizard
General, Storage, Networking, and Advanced mapping in one flow: destination project and cluster, per-disk storage mapping, target network, instance flavor, and access key.
Full and incremental backups with CBT
Change block tracking keeps the migration source current without re-reading whole VMs, so cutover batches move on fresh data.
Continued protection after cutover
Once workloads land in OpenStack, the same policy-driven protection applies: immutability (Object Lock, Retention Lock), IsoLayer air-gap, and Recovery Plans — no re-architecture, no second tool.
Broad guest OS coverage
RHEL 8/9, CentOS Stream 8/9, openSUSE Leap 15.2–15.6, Fedora Server 41, Ubuntu 22.04/24.04, Debian 11/12, and Windows 10/11 Pro plus Server 2019/2022.
Technology partners
See V2V migration in action
Watch a VMware-to-OpenStack migration run end to end in Storware Backup and Recovery — selecting a backup as the migration source, disk conversion and driver injection, resource mapping, and validation in OpenStack.
V2V migration platform support
Storware protects the workloads after you migrate them with platform-native tooling. One platform still protects both sides of that move.
VMware vSphere / ESXi → OpenStack
The most common trigger today. Broadcom-era licensing changes are pushing organizations to a stable, open target — with protection continuity intact.
VMware to OpenStack migrationCitrix Hypervisor → OpenStack
Added in v7.5. For organizations facing Citrix licensing changes and end-of-life timelines on certain versions.
XCP-ng → OpenStack
Added in v7.5. Open-source Xen source environments move to OpenStack through the same backup-driven workflow.
How V2V migration works
IT teams today manage sprawling environments across virtualization, containers, cloud, and storage. Each demands its own backup approach. The complexity grows faster than the solutions.
1. Back up the source
Run agentless full and incremental backups of your VMware, Citrix Hypervisor, or XCP-ng VMs, with change block tracking.
2. Select the OpenStack target
In the migration wizard, choose the destination project, cluster, per-disk storage mapping, network, and instance flavor.
3. Restore into OpenStack
Storware converts the disks (VMDK/VHD/XVA → QCOW2/RAW), injects guest drivers, maps resources, and restores the VM directly into the target project.
4. Validate and keep protecting
Verify the workload in OpenStack, then continue protecting it under the same platform and the same policies. No tool change, no retraining.
What is V2V migration in Storware?
It’s backup-driven cross-hypervisor migration. Storware restores an existing VM backup directly into OpenStack, converting disk formats and injecting drivers as part of the restore — so the backup platform you already run becomes the migration engine. There’s no separate migration appliance.
Which source and target platforms are supported?
Sources: VMware vSphere/ESXi (since v7.1), Citrix Hypervisor, and XCP-ng (both since v7.5). The target is OpenStack, including major distributions and community deployments. Other destination hypervisors for V2V are planned for future releases.
Do I need a separate migration tool or appliance?
No. Backup/recovery and V2V migration are handled in one platform, and your existing backups are the migration source. There’s no dedicated migration product to license or maintain.
Do I need to install agents on my VMs?
No. Backups and migrations run through hypervisor APIs on the source, and at the API level on the OpenStack target — nothing is installed inside the guest.
What happens to data protection during the migration?
There’s no gap. The source stays protected before and during the move, and the same platform continues protecting the workloads once they’re running in OpenStack — same policies, same immutability and air-gap options.
Which guest operating systems are supported, and are there limitations?
Supported guests include RHEL 8/9, CentOS Stream 8/9, openSUSE Leap 15.2–15.6, Fedora Server 41, Ubuntu 22.04/24.04, Debian 11/12, and Windows 10/11 Pro and Server 2019/2022. Windows VMs must be powered off for the backup used as the V2V source. Instances with encrypted system drives, TPM, or multi-boot configurations aren’t supported.
Can I use V2V migration to move VMs to Proxmox, Nutanix AHV, or Hyper-V?
Not with V2V — the V2V target is OpenStack. For those platforms, you migrate with platform-native tooling and Storware protects the workloads on the target as a backup and recovery source. One platform still covers both the VMware side and the destination.
Does V2V migration require extra licensing?
No. Storware uses a universal license that covers all supported sources and targets under one SKU — no per-VM migration fees and no separate migration license.