Step-by-Step Migration from Red Hat Virtualization to Proxmox VE
Among enterprise solutions, Red Hat Virtualization (RHV) has long been a trusted platform for managing virtual machines. Today, as RHV approaches its end of life, businesses are also exploring RHV alternatives such as Proxmox VE, an open-source virtualization platform that continues to grow in popularity.
This blog post explains how to migrate from RHV to Proxmox, covering the reasons for migration and the step-by-step workflow. Read on to learn how to execute your RHV to Proxmox migration smoothly.
Why Switch from RHV to Proxmox VE?
There are multiple factors to consider when switching from RHV to Proxmox VE.
- Proxmox works on Debian-based Linux distributions with a friendly apt software repository model. Built-in backup functionality is present and high-availability clustering can be configured using native tools.
- Red Hat Virtualization 4.4 reached end-of-life in August 2024. This means that no additional updates or security patches will be released and official support from Red Hat is also ending. In contrast, Proxmox VE is an actively developed, well-supported alternative.
- Cost and licensing considerations. RHV required a paid Red Hat Enterprise subscription (RHEL, RHV Manager, etc.). Proxmox VE is a free, open-source platform with optional enterprise support available. Thanks to its flexibility and licensing model, it often delivers a lower total cost of ownership, particularly for small to mid-sized businesses and labs.
- Proxmox VE has a simplified architecture. RHV uses multiple components: RHV-M (Manager), oVirt, VDSM, RHEL hosts, etc. Proxmox VE is more monolithic and easier to deploy: Built-in web UI, CLI and API; no external database or complex middleware. Proxmox is lightweight and can run on minimal hardware or scale to large clusters.
- Ease of use and administration. Proxmox VE offers:
- Integrated web-based GUI.
- Out-of-the-box centralized management (no separate management host is required).
- Built-in backup/restore, clustering, High Availability and firewall features.
RHV management can be more complex and relies on external components like PostgreSQL and RHEL subscriptions.
- Storage and networking flexibility. Proxmox supports:
- Ceph, ZFS, LVM, NFS, iSCSI, etc., natively.
- Built-in software-defined networking, VLANs, bridges and bonding via the GUI.
RHV requires more setup for advanced storage networking scenarios.
KVM-based compatibility is provided. Both RHV and Proxmox are based on KVM/QEMU and support containers. VM migration (with some conversion) is possible. Proxmox supports OVF/OVA, raw/qcow2 and other formats.
RHV to Proxmox Migration: Step-by-Step Process
Let’s explain how to prepare for VM migration from RHV to Proxmox VE.
Prerequisites
On the RHV side:
- Ensure VMs are using QCOW2 or RAW disks (no snapshots, export clean base images).
- VMs should be shut down before migration.
- Make sure root or sudo access is available on RHV hosts.
- If using GlusterFS or iSCSI, note your VM storage layout.
On the Proxmox side:
- Set up a Proxmox VE cluster (or single node) with sufficient resources.
- Prepare the storage (ZFS, LVM or a local directory) to which VMs will be imported.
- Recommended: Install virtio drivers if you are importing Windows VMs.
Migration tips:
- Always back up VMs before migration.
- Windows licensing might get triggered after a hardware change.
- RHV NIC MAC addresses may need to be reassigned in Proxmox VE for static IPs.
The workflow of RHV to Proxmox VE migration
Once all the preparation steps are completed and prerequisites are met, you can migrate RHV virtual machines to Proxmox VE. All migration operations can be performed in the command line interface on the Linux hosts running these virtualization platforms.
- Locate the virtual disk(s) of the VM(s) you want to migrate on the RHV host. Connect via SSH into your RHV compute host (not the RHV Manager). You can use an SFTP client to copy files over SSH from an RHV host via the network. For example, the location of the source VM can be:
/rhev/data-center/mnt/10a12345…/images// .qcow2 - Copy virtual disk images from RHV to the Proxmox host. To copy files over the network, the most reliable options are rsync or SCP.
- On the Proxmox node, create a directory for the new VM that will be migrated (use a free VM ID, such as 123 in this example):
mkdir -p /var/lib/vz/images/123/ - The command to copy a file with rsync:
rsync -avz root@rhv-host:/rhev/data-center/mnt/.../disk.qcow2
/var/lib/vz/images/123/vm-123-disk-0.qcow2Where 123 is the VM ID we want to assign in Proxmox. Replace this ID with your custom value. In this example, the VM has one virtual disk.
- The command to copy a file via SCP that you should run on the Proxmox host:
scp username@remote-RHV:/file/to/receive /where/to/put/locallyFor example:
scp username@remote-RHV:
/rhev/data-center/mnt/10a12345.../images// .qcow2
/var/lib/vz/images/123/vm-123-disk-0.qcow2
- On the Proxmox node, create a directory for the new VM that will be migrated (use a free VM ID, such as 123 in this example):
- Create a new empty VM in Proxmox. Run the command on the Proxmox host to create the VM:
qm create 123 --name my-vm-name --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0where 123 is the VM ID.
- Set the virtual disk to attach using the imported virtual disk file copied from the RHV host:
qm importdisk 123 /var/lib/vz/images/123/vm-123-disk-0.qcow2 local-lvm - Attach the virtual disk:
qm set 123 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-123-disk-0You can also use –ide0 or –sata0 if needed, but virtio is preferred for performance.
- Set a boot disk:
qm set 123 --boot order=scsi0 - Check the VM configuration, start the VM and adjust the guest operating system inside the VM. If needed, boot the VM with a live or rescue ISO image.
- Check:
- Network interface renaming (RHV uses ethX, Proxmox may use ensX or enpXsY) if the configuration depends on these parameters.
- Remove RHV-related services and tools, such as oVirt packages.
- Install qemu-guest-agent (optional, for better integration).
- Install virtio drivers (especially for Windows VMs):
- Mount the VirtIO ISO image to the VM in Proxmox VE.
- Boot the VM and install the VirtIO drivers inside Windows.
- Start the VM, boot the guest OS and test whether the VM works fine after migration.
- Start the VM in Proxmox:
qm start 123 - Open the Proxmox web GUI and monitor the migrated VMs and related information.
- Verify the network and disk are working.
- Check logs inside the guest OS for errors.
- Start the VM in Proxmox:
RHV to Proxmox migration using VM templates
Another approach to exporting an RHV virtual machine to Proxmox VE is to export the VM to an OVF/OVA template and then import the VM from the template in Proxmox VE.
- Export the VM from RHV Manager as OVA (if possible) or use the command line:
virt-v2v -ic vddk:///path/to/your/vdsm/storage/domain -of ova -os /path/to/export/directory -n your_vm_name -b /path/to/your/bridge-network - Import the VM to the Proxmox host using the OVA template:
qm importovf 123 vm_name.ova local-lvmWhere local-lvm is a datastore name on the Proxmox host and 123 is the VM ID.
Note: You can create migration scripts to automate the process and run batch migration/conversion.
Post-Migration Configuration and Optimization
It is recommended that you perform post-migration configuration and optimization for VMs in Proxmox VE. This helps to ensure stable operation, maximum performance and optimal integration with Proxmox features.
- You may need to edit the virtual disk controller in the VM storage configuration.
- Adjust network configuration. Connect the virtual network adapters of the migrated VM on the Proxmox host to the appropriate virtual networks (virtual switches).
- Fix the static IP address configuration or update the DHCP configurations if the MAC address changes.
- If Linux is installed on the VM, update /etc/network/interfaces (for Debian) or /etc/netplan/ (for Ubuntu) accordingly. Other Linux distributions may have different network configuration files.
- If a Red Hat-based guest OS is installed on the VM, remove RHV/oVirt-specific Packages with the command:
yum remove vdsm* ovirt* rhvm* -y - Set up QEMU Guest Agent in the guest operating system. This agent provides accurate VM info (IP, hostname) in the Proxmox interface, safe shutdown of VMs and online backups (when the VM is running).
- In Ubuntu, you can install the guest agent from online software repositories with the commands:
apt install qemu-guest-agentsystemctl enable --now qemu-guest-agent - In the Windows guest, mount the VirtIO ISO image to the VM and install qemu-ga-x64.msi from the guest-agent directory (for 64-bit Windows).
- In Ubuntu, you can install the guest agent from online software repositories with the commands:
- Enable QEMU Guest Agent in Proxmox if not enabled yet:
qm set--agent enabled=1 - You may need to update GRUB:
update-grub && reboot - Recheck disk mounts. If the VM uses multiple disks and partitions, ensure that the order of the disks and partitions is correct and that the fstab configuration matches the disk configuration. Check /etc/fstab to ensure the UUIDs or labels are correct after disk import. Edit the configuration if needed.
Ensure Proxmox VM Protection with NAKIVO
Once you have finished migrating virtual machines from Red Hat Virtualization to Proxmox, it is recommended that you configure VM backup. NAKIVO Backup & Replication is a comprehensive data protection solution that supports Proxmox VM backup on the host level via the provided APIs.
This approach ensures high efficiency and reliability for data protection in Proxmox VE. Individual Proxmox hosts and clusters are supported. The NAKIVO solution includes a wide set of features, including:
- Incremental backup allows you to copy only the changed data since the previous backup. This approach speeds up backup operations and saves storage space. Together with backup compression, data backup speed and storage savings are higher.
- Backup encryption protects data against unauthorized access and improves the security of your backup environment. Data can be encrypted at the source, target and during network transfer.
- Backup immutability protects backups against ransomware. You configure the immutability period and data cannot be modified once it is written. Ransomware cannot delete, corrupt or alter immutable backups.
- Fast data recovery. The NAKIVO solution supports full and granular recoveries. You can choose the method that is optimal for you in the current scenario for fast and effective recovery. You can recover data to the original or custom location.
- Multiple backup destinations. You can store backups locally, in file shares, on private or public clouds, on S3-compatible storage and on NAS.
Conclusion
Migrating from RHV to Proxmox VE can seem challenging, but the process becomes much more manageable with proper planning and preparation. As RHV approaches its end of life, organizations are evaluating alternatives, and Proxmox stands out as a flexible, open-source option backed by a strong community. Following a structured migration workflow can minimize risks and ensure continuity for your workloads.