Migrate from Red Hat Virtualization to Proxmox VE: what moves and what needs rework
If your RHV 4.4 estate reaches the end of its Extended Life Phase in August 2026, or a renewal or residency requirement is forcing the decision, know this first: the move is mostly disk and guest work, plus network and identity re-mapping, not a database-style migration. The VM disks, guest operating systems and virtual NICs move across, while the RHV engine, its storage domain metadata and its role model are replaced by Proxmox VE's own cluster configuration and user management. Most estates are handled by an internal platform team, with an implementation partner typically brought in for a pilot cluster and for the cutover window. Effort and risk scale with the number of VMs, their disk sizes, whether they carry snapshots, and how many guests depend on hard-coded network or service identities. Ask your partner for a written scope that lists each VM class and its cutover method before agreeing a timeline.
Proxmox VE is free and open-source software published under the GNU AGPL v3, and it can be run without a subscription. The paid subscription is optional support: it buys access to the enterprise repository and support tickets with defined response times, and all features are the same in every tier. That changes the cost conversation. Your recurring line items are the support tier you choose for production nodes, the staff time for migration and operations, and any partner retainer. Ask for the subscription cost for your socket count from the Proxmox VE pricing page, and confirm whether your security policy accepts the no-subscription repository for non-production clusters only.
Plan for three kinds of rework that no import tool removes. First, guest drivers and agents: Windows and Linux guests carry RHV-specific virtio and guest tools, so confirm that the virtio drivers and QEMU guest agent are installed and working on Proxmox VE before you retire the old tools. Second, networking: bridge names, VLAN tags and bonding configuration must be recreated on each Proxmox node, and any IP or DNS dependency must be checked. Third, identity: RHV's admin and user roles do not carry over, so map your administrators and service accounts to Proxmox VE user management early. Sequence the move cluster by cluster, starting with a low-impact cluster, and keep a rollback path to the RHV source until each VM has passed its acceptance checks.
Which RHV capabilities map to Proxmox VE, and which need rework
This table maps the RHV capabilities most estates depend on to their Proxmox VE counterparts and marks each row as clean, needs rework, or gap. Read it as a starting inventory: confirm every RHV feature you actually use against your own environment, because engine-specific objects and integrations rarely map one to one. The main takeaway is that compute, clustering, networking and backup map cleanly, while storage domain design and engine-driven workflows need planning before any VM moves.
| RHV capability | Proxmox VE equivalent | Migration note |
|---|---|---|
| KVM hypervisor and VM lifecycle | KVM virtual machines managed from the web interface and API | Clean: guests run on KVM, but confirm virtual hardware, machine types and guest drivers before cutover |
| Multi-master clustering and configuration replication | Multi-master cluster with the Proxmox Cluster File System replicating configuration to all nodes | Clean: rebuild clusters on Proxmox VE rather than joining hosts to the RHV engine |
| Local storage on LVM, directories and ZFS | Local storage on LVM, directories and ZFS | Needs rework: map each RHV storage domain to a Proxmox storage definition and re-check sizing and redundancy |
| Network storage on iSCSI, NFS and CIFS | iSCSI, NFS and CIFS storage definitions | Needs rework: recreate LUN and export access for the new hosts before copying disks |
| Ceph RBD and CephFS storage | Ceph RBD and CephFS storage integrated with Proxmox VE | Needs rework: Ceph must be deployed and sized for Proxmox VE; confirm your current Ceph release and pool layout |
| High availability with three or more nodes and watchdog fencing | HA manager with quorum, shared storage and watchdog-based fencing | Needs rework: a three-node minimum and shared guest storage must be in place before HA is enabled |
| Management web interface and API | Web interface and REST API for management and automation | Gap: engine-specific workflows, roles and automation scripts need to be rewritten against the Proxmox VE API |
| Engine storage domain model and data center concepts | No direct equivalent; storage is defined per node or cluster | Gap: confirm which storage domain behaviors you depend on and design the replacement layout before migration |
| Backup through a backup product | Proxmox Backup Server for VM backup and restore | Needs rework: confirm backup schedules, retention and restore tests against your current backup tool |
Which data and integrations move, and which must be rebuilt
A move from Red Hat Virtualization to Proxmox VE carries disks, configuration and some identity data, but several pieces are rebuilt by hand. Each card below names one item, the documented Proxmox path for it, and what to confirm before committing a cluster to that path.
VM disks from storage domains
Disks sit in RHV storage domains and must be exported in a format Proxmox can read. The documented paths are qm disk import for VMDK files and OVF import with qm importovf. Proxmox's integrated import wizard is documented for VMware ESXi and vCenter, not RHV, so treat RHV disk export as a separate, tested step. Confirm the RHV export format and version against the Proxmox migration wiki before choosing a path. Test one VM per disk type first.
VM configuration and OVF metadata
CPU, memory, boot order and disk layout live in RHV's engine database and do not transfer as a Proxmox VM definition by default. OVF import with qm importovf can carry part of this metadata, but CPU model, firmware type and device settings often need manual review. Plan to recreate each VM's hardware profile and check it against the original before cutover.
Templates and golden images
RHV templates are stored as storage-domain objects and are not directly usable as Proxmox templates. Convert each one to a disk image, import it, and mark it as a template in Proxmox. Confirm the guest operating systems in each template still boot on the virtio drivers Proxmox presents, and rebuild any template that depends on RHV-specific guest tools.
Networks and VLAN mappings
RHV logical networks and their VLAN tags must be mapped to Proxmox bridges and VLAN-aware configuration on each node. Every node in a cluster needs matching bridge names, or migrated VMs will start without connectivity. Document each RHV network, its VLAN ID and its Proxmox bridge name in one table, and verify it on a test VM before moving production workloads.
Users, roles and directory integration
RHV authorization relies on its directory integration and its role model. Proxmox uses its own user and role management, and directory realms must be configured again. Map each RHV role to a Proxmox role and path, then check that the same people have the same rights. Treat this as a rebuild, and confirm the Proxmox user management documentation for the realm types your directory supports.
Backup jobs, retention and automation hooks
RHV backup jobs, retention policies and any scripts that call the RHV REST API do not carry over. Backups should be recreated in Proxmox Backup Server or another supported target, with retention set explicitly. Any monitoring, ticketing or automation tool that calls the RHV API must be rewritten against the Proxmox API, and each hook should be tested against a staging cluster.
What changes inside the guests and the network after the move
Guests keep their disk contents, but their virtual hardware changes, so each Windows and Linux VM needs a check before cutover. The VirtIO drivers and the QEMU guest agent are the first items to verify. Confirm which VirtIO driver package each Windows guest needs for its operating system, and check driver versions against your guest OS support matrix and the Proxmox VE documentation for your release. Linux guests usually pick up the storage and network devices at boot, but confirm that initramfs and fstab entries refer to UUIDs or labels rather than device names, because disk and NIC names can change when the virtual controller changes. Plan to install or enable the guest agent so the Proxmox VE console and shutdown functions behave correctly.
Network device models and interface names may change after import, which breaks static configuration tied to old names such as eth0 on Linux or specific adapter names in Windows. Re-map IP addresses, VLAN tags and bond definitions on the Proxmox VE bridges you create on each node, and record the RHV logical network to Proxmox VE bridge mapping in your cutover runbook before the first VM moves. Test each VM's VLAN membership and bond behavior in a non-production bridge first. Your network team should confirm that switch ports, MTU and any firewall rules match the new bridge layout on every host in the cluster.
Snapshots deserve early attention. Proxmox documents that VMs with snapshots import more slowly in its ESXi import tests, so remove or consolidate snapshots on each VM before export. Confirm the equivalent effect for RHV exports in your own test migration, since the Proxmox documentation tests cover ESXi sources. Finally, test boot order and console access on every VM after import, because firmware type, disk ordering and display devices can differ from the source. Check that each VM boots from the intended disk and that the Proxmox VE console opens for administrators, and keep the original RHV VM available until these checks pass.
How to sequence the migration cluster by cluster
The sequence moves RHV workloads in waves, proves the process on non-critical VMs, and keeps RHV available as a fallback until each wave is verified on Proxmox VE.
Build the inventory and dependency map
Your team, with DeployOpen if engaged, lists every VM in each RHV cluster with its operating system, vCPU and memory, disk sizes, storage domain, attached networks and any HA, backup or replication dependencies. Flag VMs with snapshots, since Proxmox documents that they import more slowly, and VMs on storage that the Proxmox import path cannot read. The step is done when every VM is assigned to a wave and each wave has a named owner and a rollback contact. Ask the storage team to confirm which disks sit on storage the import path supports before any wave is scheduled.
Stand up the Proxmox VE test node
Install Proxmox VE on a spare node and enable the no-subscription repository for testing only, following the package repository guidance. Connect it to a storage target that matches the chosen destination layout, such as NFS, iSCSI, ZFS or Ceph. Confirm that the node can reach the RHV engine and hosts over the migration network. The step is done when the node is patched, reachable and has the storage and bridge layout the pilot needs. Do not run production workloads on this node.
Pilot a small set of non-critical VMs
Export three to five non-critical VMs from RHV storage domains as OVF with their disks, then import them with qm importovf or qm disk import, using the Proxmox wiki as the reference for each path. Check that disks attach, network interfaces map to the right bridges, and the guest boots. Replace the guest agent and drivers as needed, then test application behavior, logins, backups and restores. The step is done when each pilot VM passes a written test script and the team has recorded the exact commands and any manual fixes. These notes become the runbook for later waves.
Build the production cluster before waves arrive
Build the production Proxmox VE cluster with its enterprise subscriptions in place, so production nodes receive updates from the enterprise repository. Plan for at least three nodes for reliable quorum, shared storage for guests, redundant hardware, and watchdog-based fencing if high availability is required. Test a node failure in a non-production window to confirm that a failed node is fenced before its guests restart elsewhere. The step is done when quorum, shared storage, backups and fencing have all been tested and signed off. Confirm subscription tiers and per-socket counts with Proxmox before purchase.
Run parallel waves with rollback available
Migrate production waves in order of lowest business risk first, while the remaining production clusters continue running on RHV. For each wave, take a verified backup, export and import the VMs, validate networking and application function, and record the result. Keep the source VMs on RHV powered off but intact, not deleted, so a rollback path exists. The step is done when a wave has passed its acceptance checks and the business owner has signed off in writing. Do not start the next wave until the previous one is accepted.
Cut over each VM or wave
Switch traffic for each VM or wave to its Proxmox VE copy during an agreed change window, using DNS, load balancer or application configuration changes as needed. Monitor performance, logs and backups for the agreed observation period. If acceptance fails, switch traffic back to the RHV copy, which was kept available for that purpose. The step is done when the wave runs on Proxmox VE, the rollback path has been closed by the owner, and the monitoring baseline is recorded.
Decommission RHV after verified retention
After backups of the migrated VMs have been restored successfully in a test, retire the RHV copies according to a retention period that your compliance and records policies set. Record which storage domains are released, which licenses or support contracts end, and where the final backup set is held. Confirm with your auditors which evidence they expect, since DeployOpen prepares evidence but does not issue audit reports. The step is done when the RHV environment is removed, the retention period has ended, and the decommission record is filed.
What drives the cost and duration of the move
This table lists the factors that change how long the move takes and what it costs, and how to keep each one under control. Read it before you scope a cluster, because the drivers interact: a large disk estate on a single cluster costs more to move in one window than the same estate split into smaller waves. The Proxmox VE subscription row shows the only software price in this table, and it is a recurring support choice rather than a licence fee.
| Cost or duration driver | Why it matters | How to keep it down |
|---|---|---|
| Number of VMs and total disk volume | Copy and conversion time grows with the data moved, and the import path runs per disk, so VM count sets the number of work items. | Inventory every VM and disk in RHV before scoping. Group small, low-risk VMs into early waves and move the largest disks in their own windows. |
| Snapshot count | The Proxmox ESXi import is documented as slower for VMs with snapshots, and RHV snapshot chains can add conversion work on top of that. | Consolidate or remove stale snapshots in RHV before export. Confirm the snapshot state of each VM in the inventory. |
| Storage used today by the VMs | vSAN-backed disks cannot be imported, so any VM on a backend that Proxmox cannot read needs another path. Storage domain type (NFS, iSCSI, FC) changes how exports are made. | Map each storage domain to a Proxmox target (LVM, ZFS, NFS, iSCSI or Ceph) early. Confirm which disks need a manual export path and budget that work separately. |
| Guest OS mix and driver work | Windows guests need VirtIO drivers and guest agent changes, and older or unusual Linux kernels may need driver or initramfs adjustments before first boot. | Sort guests by OS and version. Pilot one VM per OS family and record the driver steps so later waves repeat them without rework. |
| Number of networks and VLAN mappings | Each RHV logical network must map to a Proxmox bridge or VLAN configuration, and mismatches cause guests to boot with no connectivity. | Document every RHV network and its VLAN ID in one mapping sheet. Build the Proxmox bridges before the first import and test reachability per VLAN. |
| HA and fencing hardware | Proxmox HA needs at least three nodes, shared storage for guests, redundant hardware and watchdog-based fencing. Missing hardware pushes the design back to planning and delays cutover. | Confirm node count, watchdog support and shared storage before the migration plan is approved. Check this against the Proxmox HA documentation for your hardware. |
| Number of clusters moved in sequence | Each cluster needs its own network, storage and rollback plan, and dependencies between clusters extend the total window. | Move one cluster at a time, starting with the least critical. Use the first cluster as the reference runbook for the rest. |
| Test cycles required | Each wave needs boot, application and network tests, and failed tests repeat import and driver work, which often costs more than the copy itself. | Agree acceptance tests per application before the first wave. Keep a fixed number of rehearsal runs and record time spent on each step. |
| Proxmox VE subscription (Community, Basic, Standard, Premium) | Priced per occupied CPU socket per year: Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, per the Proxmox VE pricing page. All tiers have the same features, and they differ in support tickets, response times and enterprise repository access. The software can run without a subscription, so this is a recurring support decision. | Count sockets per node, not cores. Choose the tier by the support response you need in production, and confirm current prices on the Proxmox pricing page before you budget. |
What usually goes wrong in an RHV to Proxmox VE move, and how to prevent it
Most failed RHV to Proxmox VE moves fail in predictable places: slow disk paths, guests that boot differently on new virtual hardware, and clusters that were never tested for failure. The cards below name each risk and the check that prevents it, so the cutover plan for each cluster can be reviewed before any VM moves.
Storage path too slow or blocked
Disks leave RHV storage domains through a path you must measure before you commit to a schedule. Proxmox documents that VMs with snapshots import more slowly and that vSAN-backed disks cannot be imported at all, so a VM sitting on an unsupported backend has no direct path. Test the export of one large disk from each storage domain, record throughput, and confirm the import route (qm disk import for VMDK files or OVF import) before you plan any window.
Guests fail to boot after conversion
Moving from RHV to KVM on Proxmox VE keeps the hypervisor family but changes the virtual hardware, disk controller and network device names that the guest sees. A VM with a boot entry or driver tied to the old device model can stop at boot. Before cutover, test each guest class on a copy: confirm the disk controller type, install or enable the QEMU guest agent, and check that the NIC mapping gives the expected interface name and address.
Cutover without a tested rollback
A VM moved in place with its old copy deleted leaves no way back if the new host misbehaves. Keep the RHV disk and VM definition untouched until the Proxmox VE copy has passed application checks, and write down the exact steps to start the source VM again. Ask each application owner to sign off on the test result, and time the rollback procedure on a non-production VM before the first production window.
HA built on two nodes or without fencing
Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage for the guests, and watchdog-based fencing so a failed node is reset before its guests restart elsewhere. A two-node cluster or one without working fencing can start a guest on two hosts at once, which corrupts its disk. Verify quorum loss and fencing in a lab cluster that mirrors the production layout before you tell application teams that HA is in place.
Production on the no-subscription repository
The enterprise repository requires a valid subscription key and is the recommended repository for production, while the no-subscription repository is suited to testing and non-production use. Clusters moved into production but left on the no-subscription repository receive updates on a different path and cannot open support tickets under a subscription. Set the enterprise or no-subscription repository per node during build, and record the subscription tier per CPU socket in your asset register.
Building on a release nearing end of life
Proxmox VE versions are supported at least as long as the matching Debian release has security support, roughly 3 years. Proxmox VE 8 on Debian 12 reaches end of life in August 2026, so a new build started on it now would need an upgrade within months. Start new clusters on the current release, Proxmox VE 9.2 (released May 21, 2026, on Debian 13), and confirm the upgrade path and support dates with Proxmox before you set the cluster's maintenance calendar.
How the move differs by estate size and starting point
A single RHV cluster with a modest number of VMs usually moves in one wave. The sequence is short: inventory the guests, build a small Proxmox VE cluster, prove the import path on a few non-critical VMs, then move the rest in change windows. Because there is little interdependence between hosts, the decisions are mostly about cutover timing and how much rollback capacity to keep until the old cluster is switched off.
- Import path: For ESXi-style workflows, Proxmox documents the import wizard, but RHV exports still rely on OVF or qm disk import for VMDK files. Test one VM of each guest OS type first.
- Cluster size: A single node or two nodes can run the workload, but high availability needs at least three nodes with shared storage and watchdog fencing. Decide early whether HA is in scope.
- Guest drivers: Remove RHV guest tools and install the QEMU guest agent and VirtIO drivers before the first production cutover.
- Backups: Confirm that backup jobs point at the new storage and that a restore test has run on the target.
- Rollback: Keep the RHV source disks until the workload has run cleanly through its first full cycle.
Before starting, confirm the number of guests, their disk sizes and whether any use snapshots, since the Proxmox wiki notes that snapshot-bearing VMs import more slowly.
An estate with several RHV clusters and mixed storage (NFS, iSCSI, Fibre Channel or local) needs a migration order set by dependency, not by cluster size. The target design usually includes Ceph RBD for shared block storage, which changes how disks are placed and how migration traffic flows. Each cluster becomes its own wave, and the first wave is used to validate the Ceph layout under real load.
- Storage mapping: Map each RHV storage domain to a Proxmox storage type (Ceph RBD, NFS, iSCSI or ZFS) before moving any VM. Note which domains will be retired.
- Wave order: Move lower-risk clusters first and leave shared services, such as directory or DNS guests, for a later wave with a defined rollback point.
- Network capacity: Size the migration network separately from guest traffic, because disk copies between clusters compete with production I/O.
- Ceph readiness: Confirm failure domains, replication settings and recovery behavior with the storage team before the first production move.
- Mixed targets: Decide whether some clusters stay on oVirt or move to OpenStack, so Proxmox VE is not forced onto workloads that need a different model.
Ask the storage and network teams to document the current RHV storage domain layout and which clusters share LUNs or NFS exports.
When RHV is managed through Red Hat Satellite for content and host registration, or through Ansible playbooks for VM builds and configuration, the migration includes rebuilding that automation. Proxmox VE does not read RHV inventory, so the host provisioning, patch baselines and VM configuration logic must be rewritten or re-pointed. The sequence therefore starts with automation inventory, not with VM exports.
- Automation inventory: List every playbook, inventory source, dynamic inventory plugin and Satellite content view that touches RHV hosts or guests.
- Rebuild order: Build the Proxmox API or CLI targets and test one playbook end to end before moving production VMs, since the Proxmox API replaces RHV's engine API for these tasks.
- Patch sources: Decide how Proxmox hosts receive updates, including which repository subscription applies, and how guests keep their Red Hat subscriptions or move to a different content source.
- Configuration drift: Compare the running guest configuration with the playbook definition, because hand-made changes often exist only in RHV.
- Dual running: Keep RHV automation active for the old cluster until the new pipeline has produced at least one verified change.
Decide who owns the rebuilt automation, and confirm which Red Hat subscriptions remain needed for guests after the hypervisor changes.
In a regulated environment, each change must be traceable to an approved record, and the evidence that the move preserved controls must be retained. The migration does not change the audit obligation; it changes what evidence exists. The sequence adds approval gates, pre- and post-change checks and evidence capture to every wave, and it treats the decommissioning of RHV hosts as a controlled change of its own.
- Change records: Raise one change per wave with the VM list, the source and target storage, the rollback plan and the named approvers.
- Evidence: Capture before-and-after configuration exports, checksums of disks where practical, backup restore results and access review records for the target cluster.
- Access model: Recreate RHV roles and permissions in Proxmox VE user management before workloads move, so no VM is administered by an unmapped account.
- Decommissioning: Treat wiping RHV hosts and storage as a separate change with media and data destruction records.
- Assessor scope: Ask the assessor or compliance lead which controls they expect to see evidence for, since DeployOpen prepares evidence but independent auditors and certification bodies decide whether it is sufficient.
Before the first change, agree with the compliance owner what evidence format and retention period their policy requires.
Questions buyers ask before they migrate from RHV to Proxmox VE
How much does moving from RHV to Proxmox VE cost?
The software cost depends mainly on the subscription, and the migration cost depends on the work around it. Proxmox VE is free and open-source under the GNU AGPL v3, and the software can be used without a subscription. Paid subscriptions are priced per occupied physical CPU socket per year, with Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, according to the Proxmox VE pricing page, and all tiers include the same features. Migration cost has several parts: planning and inventory, host installation, storage and network design, VM conversion and testing, cutover, and staff training. Some of these are one-time and some recur, such as support and patching. Ask for a quote that lists each component separately and states which items are one-time and which are annual.
How long does an RHV to Proxmox VE migration take?
Duration depends on the number of VMs, the disk sizes, the storage design and how many clusters move at once. No fixed timeline applies to every estate, so treat any duration you hear as unverified until it is tied to your own inventory. Snapshot-heavy VMs import more slowly, and vSAN-backed disks cannot be imported, according to the Proxmox wiki page Migrate to Proxmox VE, so VMs on those datastores need a different path. Plan time for pilot VMs, for the first cluster, and for rollback testing before the next cluster starts. Ask your vendor or implementation partner for a schedule based on a written inventory of VMs, disks, networks and dependencies.
Can our team migrate RHV to Proxmox VE without outside help?
Yes, a capable Linux and virtualization team can do the migration in-house, provided it has time and a test environment. The work involves Proxmox installation, cluster and storage configuration, disk conversion, guest driver and agent changes, and network mapping, all documented on the Proxmox wiki. Teams without recent hypervisor migration experience often find the first cluster slow, and production outages usually come from untested dependencies such as DNS, backup jobs or licensing tied to hardware. An outside partner can plan, implement and document the move under a fixed-scope written agreement, and can support later upgrades under a retainer. Decide based on your staff's current workload and skills.
What does our staff need to provide during the migration?
Your staff must supply knowledge of the applications, not only the infrastructure. They need to confirm which VMs are business critical, which ones depend on specific IP addresses, licenses or hardware IDs, and which maintenance windows are acceptable. Storage and network administrators must document existing RHV storage domains, VLANs, bonding and firewall rules, and the target design for Proxmox VE. Application owners should approve test plans and sign off on each cutover. Backup and security teams must confirm that backups, monitoring and access controls work on the new platform before old copies are retired. Agree these responsibilities in writing before the work starts.
Can Proxmox VE import VMs directly from RHV?
Not through a documented direct RHV import wizard, so plan for an export and import path. Proxmox VE 8.2 added an import wizard for VMware ESXi and vCenter, according to the Proxmox press release, but the RHV route is different. Typical approaches export VMs or disks from RHV storage domains, then import them with qm importovf for OVF exports or qm disk import for VMDK files, as described on the Proxmox wiki. Check each option against your RHV version and storage type, and test a sample VM from every guest operating system before you commit. Confirm the exact export method with a pilot in your own environment.
Do we have to buy a Proxmox subscription?
No. The software can be used without a subscription, and Proxmox VE is free and open-source software. A subscription provides access to the enterprise repository, which the vendor recommends for production, and support ticket entitlements that differ by tier. The Community tier includes no support tickets, while Premium includes unlimited tickets with a 2-hour response, according to the Proxmox VE pricing page. Without a subscription you use the no-subscription repository, which Proxmox describes as suited to testing and non-production use. Many regulated organizations choose a subscription for support and repository access, so weigh that against your own risk tolerance.
Is it practical to run RHV and Proxmox VE in parallel?
Yes, running both platforms side by side is common during a phased move, but it has costs. You need hardware or spare capacity for both environments, network paths between them, and separate backup and monitoring for each. Plan the sequence cluster by cluster, moving low-risk VMs first and keeping RHV as the rollback target until each application passes its tests. Watch for shared dependencies such as DNS, directory services and firewall rules, which must work across both platforms during the overlap. Set a retirement date for RHV in writing, because the Extended Life Phase end date is a fixed external deadline. Confirm your capacity and network design with a pilot before committing.
Can Proxmox VE replace RHV high availability?
Proxmox VE can provide high availability, but only when the cluster is designed for it. Its HA needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware, and watchdog-based fencing, so a failed node is reset before its guests restart elsewhere, according to the Proxmox VE High Availability wiki. Two-node clusters and local-only storage do not meet that design. Test failure scenarios such as a node loss, a storage path failure and a network partition, and document the recovery times you observe. Compare the results against your RHV HA behavior and your recovery objectives before you cut over production workloads.
How DeployOpen scopes, runs and supports an RHV to Proxmox VE migration
DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and migrations follow the same pattern. Work starts with a written, fixed scope that covers the RHV estate, the Proxmox VE target and the cutover sequence, then moves through build, testing and handover.
How we scope
- Inventory of RHV clusters, storage domains, VMs, disks and snapshots to classify each VM by migration path
- Written scope listing which clusters move, in what order, and which VMs are excluded or retired
- Confirmation of guest OS, driver and guest agent requirements for each workload group before cutover planning
How we build
- Proxmox VE cluster design, storage and network mapping built inside your data center or cloud accounts
- Export and import runbooks using qm importovf, qm disk import or the import wizard, tested on representative VMs first
- Guest agent, driver and network configuration changes applied and verified for each migrated VM class
How we hand over
- Documented runbooks for each cluster move, including rollback steps and validation checks for every VM
- Test results, configuration records and a cutover log delivered to your team at the end of each phase
- Operator handover sessions so your staff can run daily tasks, updates and backups on Proxmox VE
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Post-migration review of performance, backups and high availability settings against your written scope
- Confirm with your own team which Proxmox VE subscription tier and support entitlements you need before go-live
