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 cryptographically signed parity report (ed25519) 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. Download it any time from your customer portal.
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 never moves a byte itself; 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.
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, and no cherry-picking: a table of successes cannot be told apart from one where the failures were quietly dropped, so we publish the whole matrix.
Real inventory in, real rebuild out, parity assessed and signed. The remaining 82 are target-limited: the substitute test target could not host a package the plan correctly named — recorded separately so a limit of our test bed is never read as a defect in your migration.
The Index asserts 710 source→target pairs. For 214 of them no cold root filesystem exists at any price — Red Hat Linux 9 and Fedora Core 3 pre-date containers by a decade. Each is named with its reason rather than folded into a pending count.
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, modern Fedora, SUSE and Amazon Linux alongside the whole Enterprise-Linux and Debian/Ubuntu families — and sources old enough to predate containers, rebuilt from their own published archives. See the proven conversions →
The client runs entirely inside your network and does all the analysis on your own image. It asks our hosted API for one thing — what each package maps to on the target. 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. Nothing about your machine is 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 — 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 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.)
Monitoring already re-checks a migrated instance against its signed baseline. The next step is to check that same package inventory against vendor security advisories — naming which CVEs a workload is exposed to, and emitting the patch set as a runbook the same way a migration is emitted. This is on the roadmap, not yet available: the advisory schema exists in the Index, and no advisory data, detection or patching ships today.
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.