Which to choose: vSphere, oVirt, or Proxmox VE and OpenStack instead
If your renewal under Broadcom's subscription-only model has pushed you toward a KVM successor, oVirt is a fit only for a narrow profile: a team already fluent in KVM and oVirt's engine, an estate that already runs on Red Hat-style platforms, and a willingness to host the self-hosted engine as a virtual machine on your own hosts. For most other teams, Proxmox VE is the simpler like-for-like move, and OpenStack is the better path when you need self-service private cloud rather than a cluster manager. Keep vSphere where the subscription cost is justified by workloads that depend on its ecosystem and where your renewal timing gives you room to plan. Keep vSphere in place when your VMs depend on vSAN, NSX or Site Recovery Manager features that have no direct equivalent in your team's skill set, or when a migration window cannot be scheduled before your support lapses. Under Broadcom's model, perpetual hosts keep running after support expires, but patches and major upgrades need an active contract, so confirm your exact entitlement with Broadcom before you set a deadline. Choose oVirt only if your operators already know KVM, libvirt and the oVirt engine, and if you accept that the engine runs as a VM on the cluster you manage. Check the oVirt download page for supported host platforms, and confirm release activity on the ovirt-engine tags before you commit. Choose Proxmox VE when a small or mid-sized team wants a single web interface, built-in import from ESXi and vCenter, and no separate engine to maintain. Choose OpenStack when tenants, projects and APIs matter more than a hypervisor cluster. The decision turns on four checks: the release activity of the community project you pick, the host operating systems your vendor or distribution supports, the in-house skills that will run the platform after go-live, and the migration tooling that fits your VM inventory, including whether vSAN-backed disks or snapshots will block direct import.
Which platform fits which scenario
This table matches common situations against the platform that usually fits best, with the reason tied to management model, host operating system and day-to-day effort. Read each row as a starting point: the right choice depends on your hardware, skills and whether you need multi-tenancy, and each row names what to confirm before deciding.
| Scenario | Better fit | Reason |
|---|---|---|
| Small cluster, team already skilled in KVM and libvirt | oVirt or Proxmox VE | oVirt adds a central engine and web console on top of KVM hosts; Proxmox VE ships a single web interface with KVM and LXC, so choose by whether a separate engine VM is acceptable to operate. |
| Red Hat-aligned shop running RHEL or CentOS Stream | oVirt | oVirt runs on RHEL 9 and 10 or CentOS Stream 9 and 10 for both engine and hosts, and it is the upstream project where features are developed before Red Hat productizes them. Confirm your Red Hat support path before committing. |
| Team wanting a built-in import wizard from ESXi | Proxmox VE | Proxmox VE 8.2 added an import wizard for ESXi and vCenter sources, tested from ESXi 6.5 to 8.0. oVirt has no equivalent built-in wizard for VMware sources, so plan a conversion path with virt-v2v or disk import. |
| Multi-tenant self-service with quotas and projects | OpenStack or Apache CloudStack | oVirt is organized around one datacenter and cluster model rather than tenant accounts, so self-service portals and usage accounting need a cloud layer. Confirm the tenancy features you need against each project's documentation. |
| No existing oVirt footprint and no Red Hat requirement | Proxmox VE or XCP-ng | Starting fresh on oVirt means learning the engine, self-hosted engine setup and host OS lifecycle with little local experience. Proxmox VE or XCP-ng usually take less operating effort for a new VMware exit. |
| Community project activity is a board-level concern | Proxmox VE or XCP-ng | The most recent oVirt tag, ovirt-engine-4.5.7, is dated December 17, 2025, after 4.5.6 in February 2024. Ask oVirt maintainers or your vendor about the release plan, and compare with the active release cadence of the alternatives. |
How the oVirt engine and vCenter manage hosts differently
The core difference is where the management plane lives. In oVirt, the engine is a separate management service that controls KVM hosts, and the self-hosted setup can run that engine as a virtual machine on one of the hosts it manages. The engine is installed from the command line, so the operations team must be comfortable with Linux administration before it touches the cluster. vCenter, by contrast, is a separate appliance that runs on ESXi infrastructure and is administered through its own lifecycle tools. In both cases the manager is a single point you must protect, but in a self-hosted oVirt design the engine's availability depends partly on the hosts it is managing, which changes how you plan recovery.
The day-to-day skill shift is upgrades and monitoring. Plan engine upgrades and host node upgrades as separate tracks, and rehearse both on a test cluster before production. Confirm how the self-hosted engine behaves during a host failure and where its backups are stored, because restoring a management VM is a different task from restoring a vCenter appliance. Your monitoring must check the engine's own health, its database, and its reachability from each host, not only the state of the virtual machines it runs. Ask your DeployOpen or internal team to write this as a runbook with named owners.
Before committing, decide which release line you will run. oVirt features are developed upstream first and reach Red Hat's supported product later, so the community release you choose and any supported offering may differ in what they include and how long they are maintained. Check the current ovirt-engine tags and the platforms listed on the oVirt download page against your host operating system standard. If you need a vendor-backed support path, confirm it in writing before you migrate, and compare that with the lifecycle of Proxmox VE or OpenStack if predictable support matters more than the oVirt model.
Is oVirt still actively released, and which hosts does it support?
oVirt's release activity and host platforms decide whether it can be a long-term home for VMs leaving vSphere. The cards below set out the latest tags, the project model, the supported platforms and the questions to settle with the project before committing.
Latest engine tag
The most recent ovirt-engine tag is ovirt-engine-4.5.7, dated December 17, 2025. Read the tag date as the start of your own diligence, not as a support commitment. Check the project's release notes and the tag list before you plan a deployment, and record the date you checked so your architecture decision has a clear reference point.
Previous release gap
The tag before 4.5.7 is ovirt-engine-4.5.6, dated February 12, 2024. That gap of nearly two years matters for a team that wants steady security fixes. Ask the project how it plans future engine releases, and compare that cadence with the patch timing your security team requires for hypervisors and management planes.
Community-driven development model
oVirt describes itself as community-driven and open to pull requests, with KVM, OVN networking, high availability and Ansible automation as its core components. Upstream features are developed here before they reach Red Hat's supported product. Assess whether your team can maintain patches, testing and upgrades without a commercial vendor, or whether you will need a third-party support contract.
Supported platforms for 4.5.7
The 4.5.7 download page lists Red Hat Enterprise Linux 9 and 10, or similar, and CentOS Stream 9 and 10 as supported platforms for both the Engine and hosts. Confirm the exact operating system versions, kernel and hardware compatibility with your server models before buying hardware, and check whether the list changes between minor releases.
oVirt Node 4.5 host image
oVirt Node is a minimal host operating system based on CentOS Stream 9, and its current stable release is oVirt Node 4.5. Teams that want an appliance-style host should test driver support, storage multipath, and how patches are applied to nodes in a running cluster. Confirm the lifecycle of CentOS Stream 9 against your own patch plan, since the host image inherits it.
Support window and upgrade path
Before committing, ask the oVirt project in writing how long 4.5 receives fixes, what the upgrade path to a later major line looks like, and whether self-hosted engine upgrades can be tested in your environment. Compare the answers with Proxmox VE, which is updated on a published roadmap, or OpenStack, if the destination is a larger private cloud. Record these answers as part of the migration risk register.
Data control and hosting: what changes on-premises, in a private cloud or air-gapped
In your own data center, every component of an oVirt deployment sits on hardware and networks you already control. The engine can run as a virtual machine on a host through the self-hosted engine setup, so the management plane lives on the same racks as the workloads it manages. Your team holds the keys for disks, backup repositories and the engine's internal certificates, and no vendor has standing access unless you grant it. Evidence is yours to generate: you decide where engine and host logs are shipped, how long they are kept, and how changes to clusters, networks and storage domains are recorded.
- Engine location: the self-hosted engine runs as a VM on a host, so plan a separate network path and a recovery procedure for the case where the engine itself is down.
- Key custody: your staff own the certificate authority, SSH keys and backup encryption keys, which needs a documented rotation schedule.
- Logs and backups: engine logs, host logs and backup catalogs should go to storage that is outside the failure domain of the cluster they describe.
- Identity integration: connect the engine to your directory service so that administrator actions map to named accounts rather than shared credentials.
- Change records: keep a dated log of cluster, network and storage changes, since oVirt does not replace your change management system.
Confirm with your own environment which hardware and host operating systems your change control accepts before you commit to a design.
In a private cloud or colocation facility, the hardware is shared or hosted by a third party, but the software stack and the keys can stay in your hands. Your team still operates the engine and hosts, and the provider typically supplies power, racks, network uplinks and physical access controls. Contracts decide what the provider can see, who can enter the cage or hall, and how quickly they respond to a hardware failure. Backups and logs often move to a second site, which changes data residency and transfer obligations, so confirm where each copy physically sits.
- Shared responsibility: write down which party handles physical access logs, hardware replacement and remote hands, and which party handles hypervisor patching.
- Key custody: keep encryption keys and engine administrator credentials under your control, and confirm that the provider cannot retrieve them from managed services.
- Off-site backups: choose the second site with the same residency rules as the primary, and test restores from it, not only the backup job status.
- Access logs: route bastion, console and engine access logs to a store that the colocation provider cannot alter.
- Compliance evidence: the provider's own reports cover their controls only. Ask for their documentation scope in writing before you rely on it.
Confirm with the facility operator which controls and reports they can share under your contract.
On an isolated or air-gapped network, the engine, hosts, backup targets and log collectors have no route to the internet. Packages, host images and any updates must arrive through an approved transfer process and be verified before installation. Identity integration usually means a directory service inside the isolated zone, and time synchronization must come from an internal source. Evidence becomes more important here because external reviewers often rely on exported logs and signed change records rather than live system access.
- Software supply: mirror the required oVirt, CentOS Stream or RHEL, and oVirt Node packages into the isolated zone, and verify checksums before each import.
- Local identity: run the directory and certificate authority inside the zone, and document how break-glass accounts are controlled.
- Log export: define a one-way export path for engine and host logs, with hashes recorded at export time.
- Backup media: keep backups on storage inside the zone or on removable media with a documented custody record.
- Evidence packages: prepare change tickets, access reviews and patch records as dated exports that an assessor can read without network access.
Confirm with your security team which transfer and verification steps they will approve, and which oVirt and host operating system versions your mirror will carry.
Identity, compliance and data residency under each model
Moving from vSphere to oVirt changes who holds the keys, who patches the stack and who produces the evidence. The cards below set out what to decide and check under each hosting model before the assessor asks.
Data location and sovereignty
With self-run oVirt, VM disks, engine database backups and logs stay in the data centers you choose, which simplifies residency statements. Vendor-supported and partner-run options add personnel and remote access paths that may touch those systems. Ask every provider where support staff sit, whether they can view tenant data during tickets, and where backup copies are stored. Confirm the answers in writing before the migration plan is signed.
Hosting model and responsibility split
Vendor-supported, self-run and partner-run models divide patching, engine upgrades, host OS maintenance and on-call duties differently. In a self-run model, your team owns the engine VM, KVM hosts and the upgrade path, and the Red Hat and community release timelines set your windows. A partner-run model shifts day-to-day work but not accountability for your controls. Write the split into a responsibility matrix that names an owner for each control.
Identity integration and access
Administrative access to the oVirt engine, its admin portal and host consoles should flow through your directory and multi-factor controls, not local accounts shared by the team. Confirm how the engine authenticates users, which roles map to your privileged groups and how service accounts for automation are scoped and rotated. Test a joiner, mover and leaver scenario on a lab engine before relying on it for production evidence.
Audit logging and retention
Engine events, API calls and host activity must reach a central log store that you control, with retention long enough for your assessment window. vSphere customers often rely on vCenter event and task history, so map each event class to its oVirt equivalent and check that it is exported. Define who may read and alter the logs, and test that a deleted or altered VM record still leaves a traceable entry.
Patch and vulnerability handling
The ovirt-engine repository is licensed under Apache 2.0 and its most recent tag, ovirt-engine-4.5.7, is dated December 17, 2025, so check the release cadence against your patch policy before committing. Supported host platforms for oVirt 4.5.7 include Red Hat Enterprise Linux and CentOS Stream, and oVirt Node is based on CentOS Stream 9. Ask whether vulnerability feeds, emergency fixes and host image rebuilds are handled by your team, a vendor or a partner, and how fast each path can deliver them.
Evidence for regulated assessments
Your controls are only as credible as the records behind them. Keep configuration baselines, change records, access reviews and patch evidence in a system the assessor can inspect. Independent auditors and certification bodies issue audit reports and certifications, while DeployOpen prepares systems, controls and evidence for those assessments. Confirm with your assessor which evidence formats and sampling periods they require before designing the collection.
What a move from vSphere to oVirt involves
The sequence turns a vSphere estate into an oVirt cluster in controlled waves, with each step ending in a check that the next one can rely on. Because no built-in vSphere-to-oVirt wizard is covered by the supplied facts, the conversion tooling is confirmed during the pilot rather than assumed at the start.
Inventory VMs and their dependencies
The infrastructure team lists every VM with its operating system, disks, network adapters, snapshots, backup jobs, licensed software and the services that depend on it. Application owners confirm which VMs need downtime windows and which can move live. The output is a single inventory sheet that assigns each VM to a candidate wave. The step is done when every VM has an owner, a wave and a rollback point recorded.
Confirm host operating systems and hardware
The platform team checks the current oVirt download page for the supported Engine and host platforms, which list Red Hat Enterprise Linux and CentOS Stream releases, and compares them with the hardware it plans to reuse. It also confirms the oVirt Node option, which is based on CentOS Stream 9, against its own standards for patching and kernel management. Storage, CPU generation and NIC driver compatibility are verified on each host model. The step is done when a written compatibility matrix is signed off by the infrastructure lead.
Stand up the engine and a pilot cluster
The team installs the oVirt Engine from the command line, using the self-hosted engine option if it wants the Engine to run as a virtual machine on the cluster it manages. It adds two or more hosts, configures the data center, storage domains, logical networks and high availability settings, and tests host maintenance and failover. Backups of the Engine database are configured and restore-tested before any production VM arrives. The step is done when a test VM survives a host failure and the Engine restore has been demonstrated.
Test VM conversion from VMware
Because the supplied facts do not describe a built-in vSphere-to-oVirt import wizard, the team selects and confirms its conversion path, such as an export to OVA or VMDK followed by conversion on the oVirt side, or a third-party tool. It confirms with the tool's vendor or documentation which VMware versions, disk formats and guest operating systems are supported. The pilot VMs are converted, booted, and checked for drivers, guest tools and network identity. The step is done when each conversion path has a documented runbook and a successful test boot.
Map networks and storage for each wave
The network team maps vSphere port groups and VLANs to oVirt logical networks and confirms that the same IP addressing, firewall rules and load balancer pools work on the new side. Storage owners map datastores to oVirt storage domains and confirm capacity for the converted disks plus temporary space for conversion. Any VM depending on features outside the pilot, such as shared disks or specialized devices, is flagged for a separate decision. The step is done when a mapping table is reviewed for each wave and a connectivity test passes for representative VMs.
Pilot a wave with warm or cold moves
The team moves a small, low-risk wave of VMs, choosing a cold move for systems where a short outage is acceptable and testing any warm migration approach only after confirming how the chosen tool handles changed blocks and snapshots. Application owners run their own acceptance tests and the operations team checks monitoring, backups and access. Lessons learned update the runbook before the next wave. The step is done when the pilot wave has passed acceptance and the runbook has been revised.
Cut over production waves
Each production wave follows the same runbook: freeze changes, take a verified backup, convert and move the VMs, validate services, and confirm monitoring and backup jobs on the oVirt side. Rollback steps are rehearsed so the source VM can be restarted if acceptance fails. Change records capture who approved each wave and when services were restored. The step is done when every wave has an acceptance record and the change log is complete.
Decommission vSphere and retain evidence
Once the last wave is accepted, the team retires the ESXi hosts and vCenter after keeping source backups and exported configurations for an agreed retention period set by the organization's own policy. It removes licenses and support contracts only after the retention decision is recorded, and updates the asset register and disaster recovery documentation. The security team keeps evidence of the decommissioning, such as wipe records for storage and access removal logs. The step is done when the asset register shows no active vSphere workloads and the retention record is signed.
Common questions before choosing oVirt or an alternative
Is oVirt still maintained and how often does it release?
oVirt is still maintained, but its release pace is slow and you should judge it against your own risk tolerance. The most recent ovirt-engine tag is ovirt-engine-4.5.7, dated December 17, 2025, following ovirt-engine-4.5.6 on February 12, 2024. The project describes itself as community-driven and open for pull requests, so activity depends on contributors. Before committing, review the oVirt tags list and the project's mailing list, and ask any vendor offering support to confirm which releases they cover and for how long.
What skills does a team need to run oVirt itself?
Your team needs Linux administration, KVM and networking knowledge, and experience operating a clustered hypervisor with shared storage. oVirt is installed from the command line, and its self-hosted engine runs the Engine as a virtual machine on one of the hosts, so operators must understand that recovery path. Hosts can run oVirt Node, a minimal operating system based on CentOS Stream 9, and the supported platforms for both Engine and hosts include Red Hat Enterprise Linux and CentOS Stream releases. Confirm these operating system lines against the oVirt download page before you standardize on them.
How long does a migration from vSphere take?
The duration depends on the number of VMs, their disk sizes, the storage path, network changes and how many cutover waves you run, and no researched figure is available for oVirt in this context. Ask any implementation partner for a timeline built from a written scope that lists these inputs. Also confirm how your VMs will be moved, since snapshots, large disks and the number of hosts each change the work. Test the process on a non-production set of VMs first so the schedule reflects real throughput in your environment.
What does a partner do and what stays with our team?
A partner typically plans the target design, installs and hardens the platform, builds the migration runbooks, documents the result and prepares evidence for your compliance reviews. Your team usually owns business approval of cutover windows, application owners' testing, access decisions and the data governance around the move. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under fixed-scope agreements, and it offers retainers for ongoing support and upgrades. Ask for the division of responsibilities in writing as part of the scope.
When is Proxmox VE or OpenStack a better fit than oVirt?
Choose Proxmox VE when you want a single product that combines KVM virtual machines, containers, clustering, high availability and software-defined storage with one web interface and a clear support tier model. Choose OpenStack when you need a self-service private cloud with multi-tenant projects and APIs, and your team can run a larger operations stack. oVirt fits best when you want a management model close to vCenter on KVM and are comfortable with its release pace. Compare the three against your VM count, tenancy needs and staffing before you decide.
How does licensing compare with per-core VVF or VCF subscriptions?
oVirt itself is licensed under Apache 2.0, so the software carries no license fee, and your recurring costs are hardware, support contracts if you buy them, and staff time. VMware vSphere is now sold as per-core subscriptions in VMware vSphere Foundation or VMware Cloud Foundation, so your VMware cost recurs on each renewal. Proxmox VE, by contrast, is free software with subscriptions priced per occupied physical CPU socket per year. Request quotes that separate one-time migration work from recurring support and staff costs so the comparison is like for like.
Can the import tooling handle snapshots, vSAN disks and encrypted VMs?
Import tooling varies by target, so confirm each case before planning waves. For Proxmox VE, its ESXi import wizard was tested from ESXi 6.5 to 8.0, cannot import vSAN-backed disks, and imports VMs with snapshots more slowly, with OVF import and VMDK disk import as alternative paths. For oVirt, the community project does not publish a current ESXi import tool in the material reviewed here, so confirm with the project or your implementation partner how snapshots, vSAN-backed disks and encrypted VMs will be moved. Run a pilot on representative VMs from each category before you commit to a method.
When Proxmox VE or OpenStack serves the team better than oVirt
Choose Proxmox VE over oVirt when the team is small and wants one web interface to manage KVM virtual machines, LXC containers, clustering, high availability and software-defined storage and networking. Proxmox VE is free and open-source software under the GNU AGPL v3, and its subscriptions are priced per occupied physical CPU socket per year, with all features available in every tier. That matters for a team that wants to know exactly which features it pays for. The import path also differs: Proxmox VE 8.2 added an integrated import wizard that pulls VMs directly from ESXi and vCenter and maps most of the original configuration. Before committing, check the documented limits in the Proxmox migration guide: the ESXi import was tested from ESXi 6.5 to 8.0, vSAN-backed disks cannot be imported, and VMs with snapshots import more slowly. Confirm your ESXi build against that range before scheduling a wave.
Choose OpenStack when the requirement is a private cloud rather than a like-for-like virtualization cluster. OpenStack fits when several internal teams need self-service projects, quotas and APIs with tenant isolation, and when the organization is prepared to staff an operations team that can run controllers, networking and storage over the long term. Its storage is commonly backed by Ceph, which suits larger estates that want to scale capacity independently of compute. A useful test is to ask who will own upgrades, Neutron networking and Ceph health on day two. If the answer is a small platform group, a cluster manager such as oVirt or Proxmox VE is usually the smaller commitment. The migration guide for OpenStack covers image conversion and tenant design in more detail.
Deciding between oVirt, Proxmox VE and OpenStack
This sequence turns the oVirt comparison into a go or no-go decision for your estate, using your team's skills, your host operating system constraints, a single-VM import test and your management and backup requirements. It ends with a named target platform and the evidence behind it.
Inventory your KVM and Linux skills
Your platform engineers list who can operate KVM, libvirt, the host operating system, software-defined storage and networking, and who would hold the on-call rotation for the target platform. Ask each person to describe a recent incident they resolved on a Linux hypervisor host, then compare the answers against the skills each candidate platform demands. oVirt expects Red Hat-family hosts and Ansible-driven operations, Proxmox VE expects Debian-based administration through its own web interface, and OpenStack expects a larger operations team with its own service model. The output is a skills matrix with named gaps and a decision on whether training or hiring is needed before any pilot starts.
Confirm the supported host operating system and release line
Check which operating system your hardware, drivers and security tooling are certified to run, then match that against the platforms your team is considering. For oVirt, the download page lists Red Hat Enterprise Linux 9 and 10 and CentOS Stream 9 and 10 for both the Engine and hosts, and oVirt Node is based on CentOS Stream 9. Confirm with your hardware vendor and your Red Hat contract whether these versions are supported in your environment. Record the exact release line you intend to deploy and the date you expect to need its next upgrade. Proceed only when every host model and driver stack has a written confirmation for the chosen operating system.
Check the project activity and governance
Review the release history of the oVirt Engine repository and the Proxmox VE roadmap, and compare how each project is governed. The most recent ovirt-engine tag is ovirt-engine-4.5.7, dated December 17, 2025, following 4.5.6 in February 2024, so ask whether the cadence meets your patching requirements. oVirt describes itself as community-driven and as the upstream where Red Hat's features are first developed, which means product support depends on whether your organization has a commercial agreement. Proxmox VE 9.2 was released May 21, 2026, based on Debian 13. Write down which projects your support and security teams can monitor, and who owns that monitoring.
Test the import path on one representative VM
Pick one non-critical VM that represents your typical estate, such as a Linux application server with a standard disk layout and no vSAN-backed disks. Export or import it into the candidate platform using that platform's documented path, then boot it, check its network and storage mappings and confirm that the guest tools behave correctly. For oVirt, the Forklift project documents warm migration with changed-block tracking from oVirt to KubeVirt, so confirm whether Forklift or another route fits your source versions. Note every manual step and its elapsed effort. The test is complete when the VM runs on the target with its data verified against the source and you have a written list of the remaining manual changes.
Compare management, backup and automation needs
List the operational features your estate depends on today, including high availability, live migration, role-based access, templates, API automation and backup jobs with retention rules. Map each one to the candidate platform and mark it as native, add-on, partner-supplied or missing. oVirt provides high availability, OVN networking and Ansible automation, and its self-hosted engine runs as a virtual machine on a host. Proxmox VE combines a web interface with clustering, high availability and Proxmox Backup Server. OpenStack needs additional services for multi-tenant self-service. Ask each vendor or community contact to confirm specific features in writing, because capability maps can change between releases. The output is a feature gap register with an owner for each unresolved item.
Estimate the total cost of ownership by component
Build a cost model with separate lines for software subscriptions or support contracts, hardware, storage, backup, staff time, training and migration work. For oVirt, the open-source Engine and hosts carry no license fee, but commercial support comes through a Red Hat relationship that you must price directly. For Proxmox VE, the subscription is priced per occupied physical CPU socket per year, with tiers of 120, 370, 550 and 1,100 euros, all with Enterprise Repository access and all features in every tier, according to the Proxmox VE pricing page. Mark each line as one-time or recurring, and list the variables that will raise or lower it, such as socket count, support hours and the number of hosts in each cluster. Request written quotes for any support you intend to buy before you compare totals.
Select the target and record the decision
Score the candidates against the evidence from the earlier steps: skills, supported operating system, project activity, the single-VM test, feature gaps and total cost. Choose oVirt when your team has strong Red Hat-family KVM skills, your hosts run a supported release and you accept the upstream community model or have a Red Hat contract. Choose Proxmox VE when you want a single web interface, Debian-based hosts and a per-socket subscription with the Enterprise Repository. Choose OpenStack when you need multi-tenant self-service and have the operations team to run it. Write the decision with its reasons, the rejected options and the conditions that would reopen the choice. The step is complete when the sponsor signs the record and the migration planning team has a named target platform.
How DeployOpen helps evaluate, implement or migrate
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including oVirt where it fits your estate. We start with a written, fixed scope so that the choice between oVirt, Proxmox VE and OpenStack is made on your workloads, support position and staffing rather than on assumptions.
How we scope
- Inventory of hosts, clusters, VM counts and storage types, including any vSAN-backed disks
- Written check of the oVirt release, host operating system and Engine version you would run
- Comparison of management model, self-hosted engine needs and high availability requirements
- Agreed deliverables, timelines and exclusions in writing before any work starts
How we build
- Proof-of-concept cluster with a self-hosted Engine on representative hardware and networks
- Test migrations of sample VMs from vCenter, with conversion, driver and network mapping checked
- Configuration of storage, network, backup and access controls aligned with your policies
- Security testing of the management plane and hosts before any production wave
How we hand over
- Runbooks for installation, host onboarding, patching, cutover and rollback in your environment
- Documented evidence of configuration, backup restores and failover tests for your internal reviewers
- Knowledge transfer sessions for your administrators so they operate the platform without us
- Control mapping that prepares evidence for your auditors, without any audit opinion from us
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer
- Upgrade planning that tracks the oVirt release line and your host operating system support dates
- Ask for the retainer scope, response expectations and exclusions in the written quote
- Quotes follow from the written scope, and DeployOpen does not publish a price list
