Move the workload off the dying platform. Hand the auditor proof it still matches. vrtmv reads your Linux workload on a supported source platform — a VM image, a live running system, or a bare-metal server — reconstructs what it actually runs, and rebuilds it as a virtual machine on a modern, supported platform by way of Ansible or Terraform. Every migration ships with a parity report as the audit trail — and lets you re-check the instance for drift against that baseline any time after it lands.
CentOS Linux is end-of-life, and the post-acquisition VMware price shock — with the same calculus now hitting Nutanix — is pushing fleets off their hypervisors at the same time. Both force the same hard question: can you move the workload and prove the replacement is equivalent?
A VM image, a live host, or a bare-metal server — vrtmv captures its true state and reasons from it, then rebuilds the workload as a virtual machine via Ansible or Terraform.
Mounts a cold VM image (VMDK / qcow2 / raw) read-only at the block layer — LVM roots activated, partitions inspected — or captures a live host or bare-metal server. Either way it reads the real package database (rpm BDB/ndb/sqlite or dpkg) and on-disk config. Nothing is installed; the workload is never disrupted.
Every package, service, repository, account and MAC-policy is resolved against the curated Translation Index to its equivalent on the target distribution — with confidence graded and on-disk conditions evaluated locally, so host state never leaves the box.
Outputs an Ansible role — or Terraform, with --format terraform — that rebuilds the workload as a virtual machine on the target OS, and a signed parity attestation: what mapped cleanly, what carried caveats, and what couldn't be resolved — stated honestly, ready for an auditor. Both are written to your output directory.
vrtmv carries the whole workload across — the platform it runs on, the data it holds, and the judgment calls in between.
The cold-image probe reads the disk directly — VMDK, qcow2, OVA, raw — so it doesn't depend on the source platform's tooling. Pull a VM straight out of VMware or Nutanix AHV and rebuild it wherever you're headed, with no vendor exporter in the loop.
Rebuilding the OS is half the job. vrtmv finds the data no package owns and emits an attested byte-copy runbook — with a sha256 manifest that proves the copy is byte-identical — while routing databases to a proper export/import (their files can't be raw-copied). It plans and hashes locally and moves no byte until you run that runbook, or ask vrtmv run --copy to; data migration is part of the plan, not a separate project.
Every migration surfaces a punchlist — the calls only a human can make, called out instead of buried. For each, you can query the Index for community field notes: anecdotes from operators who've made the move, collected and presented as input, never as guidance.
100+ Linux releases across 16 distribution families, back to the year 2000 — 8,700+ package mappings and 46,000+ cross-distro translations, each harvested from the real distro archives, not guessed. The migrations that hurt most are the oldest ones, so the Index reaches all the way back: the legacy hosts other tools abandoned still have a path forward.
A migration is a moment; parity is a state. Any time after cutover — before an audit, after a change — vrtmv re-checks a migrated instance for drift against its signed baseline: packages, services, config, accounts. The attestation stays something you can re-verify, not a one-day snapshot. Monitoring is the ongoing half of what vrtmv sells.
vrtmv verify --sign the report is signed when the vrtmv signing service answers, and verify says so when it cannot sign. It is reproducible — the same image yields the same attestation.Every claim below was produced by migrating a real source root filesystem, translating it through the live Index, applying the generated Ansible to a real target, and having vrtmv verify reach an independent verdict. No simulation: a conversion counts only when that verdict says it is proven.
Real inventory in, real rebuild out, parity assessed by a tool that can say no. A distribution or release appears on our supported list only when these runs have proven it.
A pair we have not run is reported UNTESTED, never assumed to work. That is the same discipline as the parity report’s inconclusive verdict: absence of evidence is reported as absence of evidence.
Breadth as well as depth: sources now include Gentoo, VMware Photon OS and SUSE alongside the Enterprise-Linux and Debian/Ubuntu families — and sources old enough to predate containers, rebuilt from their own published archives. See the supported distributions →
The client runs entirely inside your network and does all the analysis on your own image. It asks our hosted API what each package maps to on the target, and its usage reports carry two one-way hashes, a VM fingerprint and a host hint, never the values they are made from. We handle the mapping intelligence; your configs, inventory, and secrets stay home.
A single self-contained CLI that runs wherever your workload lives — on-prem, air-gapped edge, or a migration jump host. It reads the image, builds the inventory, and renders the plan locally. The image, its configs and the inventory are not uploaded.
A curated knowledge base of cross-distribution mappings — packages, services, repos, accounts, MAC policy — each row with verifiable provenance and an honest confidence grade. You get expert mapping intelligence without curating it yourself.
The client sends package names to look up and gets answers back, and reports usage under one-way hashes — never your data. The API is authenticated and metered, so your account is private and accountable, and the workload itself never crosses the boundary.
The same signed baseline that proves the migration also keeps the instance honest afterwards. vrtmv checks the workload’s installed packages against vendor security advisories, tells you which CVEs it is genuinely still exposed to, and turns that into a fix you review before it runs. Shipping today.
vrtmv cve-scan matches the installed packages against vendor advisories for the detected release and narrows to the CVEs still genuinely unpatched — installed version below the vendor-fixed version, not just “an advisory mentions this package”. With --sign the report is Ed25519-signed the same way the parity attestation is, so it is audit-grade evidence. A release we hold no advisory feed for is reported unmeasured, never as clean.
vrtmv cve-scan-fleet runs the same check across many hosts from a manifest and rolls it into one report — which machines carry unpatched CVEs, and which CVEs hit the most of them. It is triage, not attestation: per-VM findings are not individually signed. Run the single-VM scan with --sign when you need a signed proof for a specific host.
vrtmv patch turns a scan into a version-pinned Ansible role that bumps exactly the vulnerable packages to their vendor-fixed version. It renders by default — a runbook you review, nothing touched. --apply is opt-in and runs only against a live host you point it at over SSH, alongside a generated rollback role, then re-scans to confirm what is actually fixed. An operator action on one host at a time — never automatic fleet patching.
The rebuilt virtual machine doesn't have to stop at an Ansible role or a Terraform plan. vrtmv is adding automated tooling to hand the migrated VM straight to Red Hat OpenShift Virtualization — provisioning it as an OpenShift VM, with the same parity attestation travelling alongside as the deployment record.
VM image, live host, or bare metal → reconstructed as a VM via Ansible → deployed to OpenShift Virtualization — each step attested. (In development.)
Longer reads for the team doing the move: the choices, what tends to break, and what to keep for the audit. All of them are in the blog.
Why in-place converters bite, how to pick a target, and how to show an auditor the rebuild is equivalent. The short version is on the CentOS 7 migration page.
Where the VMs go next, and the OS migration hiding inside the hypervisor migration. See also the VMware exit page.
Where the two RHEL rebuilds really differ, and how to pick without overthinking it. Common questions are answered in the FAQ.
The live demo runs the actual engine against a real CentOS 7 package database, translates it through the Index over the live API, and shows you the Ansible role and the signed parity report it produces.
Create a free account and run vrtmv on one Linux workload: the VM image or host you would least like to move. The engine is read-only and agentless, and your data stays in your environment. Then send us the parity report it writes. It holds package, service and config names with their mappings, not their data, and sharing it is your choice. Within 2 business days of the report we hold a 30-minute review call and send a short written summary: what maps cleanly, the caveats and gaps, the decisions left to your operators, and an estimate of the cost and effort of moving that class of host across your estate. It is free and uses one of your ten free migrations.