“Migrating off Virtuozzo” is three different projects wearing one name. Get the product right before anyone estimates anything, and note that Virtuozzo renamed all three in 2026, so your own documentation and every search result you find will mix the old and new names.
Pairs with: Ænix Public Cloud Platform if you resell Virtuozzo capacity to customers, which is the majority case — the product is sold largely through regional hosting providers who rebrand it; Ænix Private Cloud Platform if it runs internal workloads. Model the money first with the Virtuozzo vs Cozystack five-year TCO.
Identify which product you have
| Current name | Formerly | What it is | Exit character |
|---|---|---|---|
| Virtuozzo Infrastructure | Virtuozzo Hybrid Infrastructure | IaaS: VMs, volumes, S3, a Kubernetes service, self-service portal | OpenStack-shaped. Standard tooling applies. |
| Virtuozzo Application Management | Virtuozzo Application Platform, originally Jelastic | PaaS: application environments from a topology wizard, automatic scaling | Re-platform. There is no disk-level exit. |
| Virtuozzo Server | Virtuozzo Hybrid Server | Bare-metal host running system containers and KVM guests side by side | Split. KVM guests move mechanically, containers do not. |
| Virtuozzo Cloud Management | — | Multi-tenant billing and provisioning layer above the other two | Re-point, like any billing integration. |
Many providers run two of these together — Application Management installed on hosts that are themselves Virtuozzo Server, or on top of a Virtuozzo Infrastructure cluster. Scope each separately. One blended estimate across a PaaS and an IaaS is how these projects end up at double their number.
One dependency worth surfacing early: Application Management’s hardware hosts have to provide the system-container runtime, which means Virtuozzo 7, CentOS 7 or RHEL 7 underneath. A PaaS estate therefore inherits the Virtuozzo Server problem described below, even when nobody thinks of themselves as running Virtuozzo Server.
The real deadline is the missing upgrade path
Virtuozzo’s published lifecycle table puts Virtuozzo Server 7 at general availability in July 2016 and end of maintenance in July 2024 — already passed. The end-of-life date on that table carries a footnote stating it is subject to change and will be set at least one year after a release of Virtuozzo Infrastructure that introduces a direct upgrade path from Virtuozzo Server 7.
Read that footnote carefully, because it says two things at once: the vendor’s intended destination for the container product is its own IaaS, and that upgrade path does not exist yet.
The second signal is stronger. Virtuozzo Server 9 is not the successor to Virtuozzo Server 7 — it is a different lineage, descending from the OnApp cloud management platform, and its documented upgrade path is from Virtuozzo OnApp 7. Its release notes state that system containers are not implemented in the release, including the vzctl and vzpkg tools, and that in-place upgrade from Virtuozzo Server 7.x is not supported.
So an operator on Virtuozzo Server 7 today is past maintenance, on a product whose container capability has no announced successor, with no vendor-provided forward path. That is a stronger planning input than any date, and it is the reason most Virtuozzo migrations arrive as an obligation rather than an optimisation.
For completeness: the lifecycle policy publishes no end-of-life dates at all for Virtuozzo Infrastructure or Application Management, and Virtuozzo Infrastructure is actively developed. Neither of those products is being sunset. This section is about the container line specifically.
Path 1 — Virtuozzo Infrastructure
The most tractable of the three, because this is not an OpenStack lookalike. It is OpenStack.
The evidence is operational rather than promotional: administrators reconfigure it by editing nova.conf, cinder.conf and neutron.conf under /etc/kolla/config and running Kolla-Ansible, the documented projects include Nova, Cinder, Neutron, Glance, Keystone, Octavia and Magnum, and Virtuozzo’s own documentation tells you to point the stock openstack client at Keystone v3 on port 5000. Compute runs a QEMU/KVM hypervisor; storage is Virtuozzo’s own software-defined layer with metadata and chunk services.
What follows:
- Compute and images. Both sides are KVM, so guest disks import into KubeVirt without a guest rebuild. Konveyor Forklift, which ships in the Ænix platform, has an OpenStack source provider, and that is the candidate path — tested in the assessment, not assumed. Two reasons to test rather than promise: Forklift documents OpenStack 16.1 or later in Red Hat OpenStack Platform version terms and Virtuozzo does not publish which upstream release it tracks, and Forklift’s OpenStack path snapshots the attached image, which needs Glance and Cinder to behave conventionally on the Virtuozzo storage backend. Note also that from OpenStack, Forklift performs cold migration only — every instance needs a genuine power-off window.
- The fallback that always works. Virtuozzo documents a volume-to-image export: snapshot the volume, register it as an image, and run
vinfra service compute image save --file <name>.qcow2 <id>. That produces an ordinary qcow2 file, which KubeVirt CDI imports as a DataVolume from HTTP, S3, a registry or a PVC. It is slower to orchestrate than a Forklift plan and has no unknowns in it. Any credible programme plan carries both routes and picks after the pilot. - Storage. Virtuozzo Storage does not come with you. It is replaced by LINSTOR/DRBD, or Ceph if you prefer a distributed cluster. This is a data move and it sizes the programme more than compute does.
- Networking and tenancy. The same redesign as any OpenStack exit: tenant networks, floating addresses and security groups become Cilium policy, LB IPAM and BGP or L2 announcements; the project model becomes the Tenant CRD. The OpenStack migration hub covers this service by service and applies directly here.
- S3. Object endpoints are customer-facing and long-lived. Plan them as their own workstream with their own cutover.
Path 2 — Virtuozzo Server
One host, two kinds of workload, and they behave nothing alike.
KVM guests move like any other KVM guest, once the disk is in a portable format.
System containers are the problem. An OpenVZ-derived container runs a full init system and multiple processes, shares the host kernel, and is managed as a machine. It is not an OCI image and no converter produces one. Virtuozzo’s own documentation concedes the mismatch, noting that applications may have problems moving to application containers because of statelessness and single-process expectations, and that this is especially relevant for orchestrators such as Kubernetes.
Two honest options, chosen per workload rather than per estate:
- Wrap it as a VM. The container’s filesystem becomes a disk image running as a KubeVirt VM. The multi-process guest is preserved exactly, the work is bounded and predictable, and you pay in density — a full virtual machine where a container used to be. For undocumented workloads, applications nobody owns, and anything where identical behaviour is contractual, this is the right answer and not a failure.
- Rebuild it as a container image. Take the application out and build an image around it. Cleaner, denser, cheaper to run afterwards, but per-workload effort. What breaks in a naive
taranddocker import: systemd as PID 1, multi-process assumptions,/etc/fstab, venet networking, and anything relying on the shared kernel.
Most estates split: a long tail of near-identical containers gets rebuilt from one common base image, and the handful of unusual ones become VMs. The assessment draws that line against your real inventory.
The disk-level reality, and a tooling correction. Container and VM disks use the ploop .hdd layout — a directory containing DiskDescriptor.xml and the image data, not a single file. There is no supported format conversion: prl_disk_tool offers compact, merge and resize, and nothing else. The working route is to mount the image read-only (ploop mount -m /mnt/x -r .../DiskDescriptor.xml) and copy the filesystem out. Two tool names in circulation are wrong and will waste a day: vzdump is a Proxmox VE tool, not a Virtuozzo one, and vzmigrate is not the current command — prlctl migrate is, and it moves guests between Virtuozzo hosts, not out of Virtuozzo. Native backups are a proprietary format under /vz/vmprivate/backups that third-party tools cannot open.
Path 3 — Virtuozzo Application Management (formerly Jelastic)
The important fact first, because it changes every estimate: the environment export produces a JSON file, and the vendor’s own instruction is that it be migrated to a platform installation of the same or higher version. It is a portability feature inside the product family, not a way out of it. There is no disk-level exit and no tool that makes one.
Three specific limits to plan against rather than discover:
- Export requires port 7979 open on the source platform, and Virtuozzo names partner installations where import to other platforms does not work at all.
- Export omits data from Elastic VPS, Maven, Docker and Windows-based containers. Those layers come across as empty shells with the topology preserved and nothing inside.
- Virtuozzo’s own pages contradict each other on whether private data is exported at all — the export page offers a Private Data option while the migration overview says only topology is exported and the target is created from scratch. The conservative planning assumption is topology only.
Which makes the export useful as an inventory, not a migration. Real data comes out through the ordinary channels: SSH and rsync via the platform’s SSH gate, FTP where the node type supports it, and native database dumps. There is a REST API and a platform CLI covering environment lifecycle, which is what you automate the extraction with.
The architecture is worth stating plainly because it explains the constraint. Workloads run in system containers — the Virtuozzo implementation, the same lineage as Virtuozzo Server. Docker is nested inside those system containers: a custom image’s filesystem is unpacked into the system container runtime rather than run as an OCI container, and only an allow-list of base operating systems is supported. So “we already use Docker here” makes the rebuild easier, because you have an image to start from, but it does not mean the workload is already portable.
The mapping to Kubernetes:
| Application Management | Destination |
|---|---|
| Environment | Namespace or tenant, topology expressed as a Helm release |
| Application server layer (Java, PHP, Node.js, Python, Ruby, .NET, Go) | Deployment plus Service, built from the same artifact you deploy today |
| Database layer (MySQL, PostgreSQL, MongoDB) | Managed database instance in the tenant catalogue; data moves by logical dump or replica |
| Load balancer layer (NGINX, HAProxy, Varnish) | Ingress, or a Service of type LoadBalancer |
| Shared storage (NFSv4) node | ReadWriteMany volume |
| Custom Docker images, Docker Engine layer, built-in Kubernetes cluster | You already have images. Easiest cohort, and the natural pilot. |
| Cloudlet resource model | Requests and limits, plus the horizontal autoscaler |
| Vertical auto-scaling of a live container | No equivalent. Horizontal scaling plus honest sizing — see below. |
What makes this cheaper than it sounds. What you hand the platform is already an artifact — a WAR or JAR, PHP source, a Node application, a Docker image. That is exactly what a container build consumes. The work is packaging and wiring, not rewriting application code.
What makes it non-trivial anyway. Three platform behaviours have to be designed around rather than ported:
- Automatic vertical scaling. The platform grows a running container’s CPU and memory in place. Kubernetes scales out, not up. For steady web tiers that is an improvement; for a single large stateful process it is a real sizing exercise, per application.
- The cloudlet as a billing unit. A cloudlet is 128 MiB of RAM and 400 MHz of CPU, and billing takes the greater of peak-RAM or average-CPU cloudlets rather than the sum. If you resell, your entire price list is denominated in a unit that does not exist on the destination. The migration is also a repricing, with its own commercial timeline.
- The topology wizard. Support provisions environments by clicking. Replacing it with a service catalogue is a product decision and a retraining cost, and it belongs in the plan from week one.
Tooling, stated plainly
Konveyor Forklift ships in the Ænix platform and does the VM transfer work on the sources it supports: VMware vSphere, oVirt/RHV, OpenStack, OVA files created by vSphere, and remote KubeVirt clusters, with Hyper-V and AWS EC2 in technology preview. There is no Virtuozzo source provider, and the OVA route is closed twice over — Forklift accepts only vSphere-created OVAs, and Virtuozzo has no OVA export.
- On Virtuozzo Infrastructure, the OpenStack provider is the lever, tested rather than assumed, with qcow2 export into CDI as the guaranteed fallback.
- On Virtuozzo Server and Application Management, Ænix engineering builds the export and conversion path as part of the engagement. We would rather say that than imply a generic tool covers a case it does not.
How Ænix engages
- Platform Readiness Assessment — inventory split by product; container-by-container triage into wrap or rebuild; Forklift’s OpenStack provider tested against your actual Virtuozzo Infrastructure version with the qcow2 fallback proven alongside it; tenant and address design; and for Application Management a repricing model next to the technical plan.
- Pilot cohort — the easiest real workload first. On Application Management estates that is the Docker and Kubernetes environments, where images already exist.
- Rolling migration — cohort by cohort with parallel-run validation, Virtuozzo hosts rebuilt into the target cluster as they free up.
- Operations — your team with Cozystack enterprise support behind it, or operated by Ænix.
Model the cost side before committing: the Virtuozzo vs Cozystack five-year TCO compares at 50, 200 and 1,000 VMs, with Virtuozzo licensing at $100 per core per year list and around $75 typical negotiated.
Ænix is the team behind Cozystack (CNCF project, Apache 2.0).