Migrate from VMware vSphere to OpenNebula

The total has three parts: the OpenNebula subscription, the target hardware or cloud capacity, and the people and services that move the workloads. The Apache 2.0 code is free to download, but the Enterprise Edition is an annual subscription priced per hypervisor host, with no limits on cores, VMs or memory. OpenNebula publishes no prices and asks buyers to request a proposal. Your current VCF or VVF renewal, the number of target hosts, storage, backup tooling and staff time all change the total. Ask the vendor for a written quote by host count and support tier. Ask the implementation partner for a fixed-scope estimate that lists each migration wave, the conversion work and what your team must provide. Keep the subscription and services lines separate so you can compare them with your current renewal.

The pace depends on the number of VMs, their size and dependencies, the storage they use, and how many change windows the business allows. No duration applies across all estates, so confirm the timeline against your own inventory. Snapshot-heavy VMs, large disks and workloads that need a long outage slow each wave. Unusual configurations and storage backends need checking before their wave starts. Plan in waves: pilot a few non-critical VMs, prove the OneSwap mode and rollback steps, then move production groups. The timeline should also cover building the target cluster, networking, backup jobs and user acceptance testing. Ask for milestones for each wave in the written scope rather than a single end date.

Four groups of people and access need to be in place before work starts:

• vCenter access and an inventory of VMs, networks, datastores and their dependencies
• The snapshot and SSH access that OneSwap requires, checked against the prerequisites for your release
• KVM hosts, storage and networks in the target zone, with staff who can operate them
• Application owners who sign off on test results, cutover timing and rollback

Your operations staff also need to learn Sunstone, the CLI and the API, because they will own patching, backup and capacity after go-live. Name one owner for each group in the project plan so that decisions do not wait for a meeting.

Yes, a team with Linux, KVM, networking and storage skills can run OneSwap in-house if it has time to test each wave. The harder work is usually not the copy itself. It is the target design, the rollback plan, the application test evidence and the day-two runbooks. A partner is useful when the internal team has little cloud management experience, when the estate is large, or when evidence for an assessment must be ready by a fixed date. DeployOpen plans, implements, integrates, documents and supports self-hosted platforms inside the client's own infrastructure, usually on a fixed scope agreed in writing before work starts. Compare an in-house plan with a scoped proposal, and check that skills, time and change windows are covered either way.

The subscription gives access to regular maintenance releases, long-term support versions, security patches, enterprise drivers and automated upgrade tools. OpenNebula's subscriptions page says certain enterprise-grade releases are available only to subscribers. Enterprise drivers include Veeam backup and NetApp and Pure Storage integrations, so confirm that your backup and storage platforms are covered. Support comes in two plans. Standard offers 9x5 coverage with 2 named accounts, and Premium offers 24x7 coverage with 4 named accounts. Both include unlimited tickets, CPUs, cores and VMs. Subscribers also keep a perpetual license that remains usable after the subscription ends. Confirm response targets, service level wording and the drivers your hardware needs in writing before you buy. OpenNebula subscriptions lists the current terms.

Yes. Broadcom's knowledge base states that ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires. What stops is access to new patches and major version upgrades, which require an active support contract. This affects a migration plan in two ways. Hosts kept for a transition period will not receive new releases without a contract, and the gap in patching grows the longer they stay in service. Plan the wave order so the most exposed workloads leave first, and record which hosts and patch levels remain in production. Confirm your entitlements with Broadcom or your reseller before you set a decommissioning date. Broadcom's knowledge base explains the rules for perpetual licenses.

A written scope should name the following items:

• The vCenter versions, clusters, VM inventory and any workloads excluded from the move
• The OpenNebula edition, support plan, target hosts, storage and networks
• The OneSwap mode chosen for each wave, with the reason and the prerequisites checked
• The conversion hosts used and their supported versions, confirmed against current documentation
• Cutover, rollback, backup and acceptance criteria for each wave
• Deliverables, documentation, training, client responsibilities and milestones
• The pricing basis and what triggers a change request

Ask for each deliverable to be listed separately so you can see what is included and what would need an added change request.

The choice depends on how much downtime a workload can tolerate and how often its disks change during the move. OneSwap offers regular, clone and delta modes, and each one balances copy time against the outage at cutover. In general, delta-style approaches copy most of the disk first and then transfer only the changes, which shortens the final stop. A full copy is simpler to reason about but usually keeps the VM stopped for longer. Test each mode on a non-production VM that matches the production profile, measure the cutover window and record the result. Confirm the exact behavior, supported source versions and prerequisites for each mode in the OneSwap documentation for your OpenNebula release before you assign modes to waves.