Replacing vSphere in an air-gapped data center without losing patch control
For an isolated site running vSphere on perpetual licenses, the core problem is not that hosts stop working when support lapses. Broadcom's knowledge base confirms that ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, but downloads of new patches and major version upgrades require an active support contract. The replacement therefore has to close one gap: a patch and upgrade path that does not depend on internet access. Proxmox VE and OpenStack are the main self-hosted options that can run offline, while XCP-ng, Harvester, OpenNebula and Apache CloudStack are narrower fits that depend more on your existing hardware, skills and workloads.
Treat patch control as a process you own before you choose a platform. Proxmox VE is distributed under the GNU AGPL v3, and its enterprise repository requires a valid subscription key, so an air-gapped site needs a plan for mirroring the repositories it uses and for verifying each package before it crosses the boundary. Ask each vendor, in writing, which repositories they publish, whether the release and security advisories can be consumed offline, and what the release lifecycle looks like for the Debian base. For Proxmox VE, the lifecycle follows the matching Debian security window, which the Proxmox VE FAQ describes as roughly three years per release.
The control question matters for the audit file as well. NERC CIP-013-2, which is used as a reference model in many critical infrastructure programs, expects supply chain procurement processes to address verification of software integrity and authenticity for vendor software and patches. Document the hashes, signatures and approval records for every offline bundle, and assign a named owner for each wave. Plan a test cluster inside the isolated network that receives every patch set before production, and keep a dated record of what was installed on which host. Confirm with your assessor which evidence format they expect before the first patch cycle.
What an air-gapped constraint requires from the platform
An isolated data center changes what a virtualization platform must do before the first VM moves. Each requirement below is a control the team must design, test and evidence, and they depend on one another: an install without verified media, or a patch with no verified path across the boundary, undermines the rest.
Offline installation media
The platform must install from media that can be built, checked and carried into the enclosure without a live connection. Confirm which installer images, firmware and driver bundles the platform needs, and whether the install completes with the network cable removed. For Proxmox VE, the ISO and its packages should be staged as one reviewed set, and the team should test a full reinstall from that set in a lab before relying on it. Ask the vendor or integrator to document every step that normally reaches the internet.
Mirrored package repository
Updates arrive through a repository the team controls, not through the public internet. A local mirror of the Proxmox VE enterprise or no-subscription repository, or the OS repositories beneath it, must be synchronized on a schedule and retained with a known snapshot date. Decide which repository is the production source and record it in configuration, because the enterprise repository requires a valid subscription key. Test that hosts resolve only the internal mirror.
Verified package signatures
Each package or image that crosses the boundary should be checked against the publisher's signing keys before it enters the mirror and again before it is installed. Keep the trusted keys in a documented, change-controlled location and log every verification result. This is the practical form of the software integrity control in NERC CIP-013-2, where a utility's procurement process addresses verifying software and patch authenticity. Teams outside the energy sector should map the same check to their own supplier and change-management requirements.
Offline migration of VM disks
Moving disks from ESXi into an enclosure with no network path requires a transfer medium and a conversion step that runs locally. Proxmox documents OVF import, qm disk import for VMDK files and Clonezilla as alternative paths, and the built-in ESXi import wizard needs a live connection to the source. Confirm that vSAN-backed disks cannot be imported directly, and plan a checksum for each disk before and after transfer. Snapshots slow the import, so consolidate them first.
Patch path across the boundary
A patch process must move each update through the same verification steps as the initial install, on a fixed cadence and with a rollback plan. Define who approves a package, how the mirror snapshot is tagged, and how the change is tested on a non-production cluster first. Broadcom's knowledge base notes that after SnS expires, perpetual ESXi and vCenter hosts keep running, but new patch downloads need an active contract, so an air-gapped team must budget for patch handling on the open-source side as well. Ask the integrator how the process is documented for auditors.
Remote access into the enclosure
Vendor and integrator sessions into an isolated network are a common regulatory focus. Where the team operates grid or similar high-impact systems, NERC CIP-005-7 requires interactive remote access to pass through an intermediate system with encryption and multi-factor authentication, and requires methods to detect and disable active vendor sessions. Plan the jump host, session recording and the procedure for revoking access before any support engagement starts. This is an example of what regulators ask, not a compliance determination for your environment.
Where vSphere support lapses and what keeps running
Hosts and vCenter keep running after Support and Subscription expires, according to Broadcom's knowledge base on perpetual license functionality. For an air-gapped site, the practical risk is not a sudden outage. It is a slow decay in patch level. The hypervisors and management plane continue to boot and serve workloads, but the vendor no longer lets you download new patches or major version upgrades without an active contract. Each month the gap between the installed build and the current security fixes grows, and the gap is easy to miss because nothing visibly breaks.
Confirm three things before you plan around the lapse: the exact entitlement on each perpetual license, the date your Support and Subscription term ends, and whether your existing contract still allows downloads of patch bundles for the versions you run. Record the ESXi and vCenter build numbers on every host and appliance now, and keep a dated inventory of what was downloaded and when. That record is the evidence an assessor or auditor will ask for when they want to know how patches reached an isolated network.
Broadcom now sells vSphere Enterprise Plus, vSAN, NSX and related products only inside VMware Cloud Foundation or VMware vSphere Foundation, so a renewal path does exist. Treat it as a subscription decision with its own cost and term, not as a fix for the air gap. A subscription restores access to downloads, but the offline site still needs a controlled process to move each patch across the boundary. Whatever you decide, the cost of carrying patches into an isolated network stays with you.
Which open-source platforms can run without internet access
This table compares six open-source virtualization platforms on how they fit an isolated network: the install and update path, the VM import route from vSphere, and the support or release trade-offs. Read each row as a question to confirm with the vendor and in your own test lab, since no platform here is cleared for air-gapped use by this table alone. The main takeaway is that the offline install and repository mirroring path must be proven for each candidate before selection.
| Platform | Offline install and patch path | VM import from vSphere | Trade-offs to weigh |
|---|---|---|---|
| Proxmox VE | Enterprise and no-subscription repositories are documented; confirm how to mirror both to an isolated network and sign off each package set | Built-in ESXi import wizard tested from ESXi 6.5 to 8.0; vSAN-backed disks cannot be imported; snapshots slow the import | Free software with per-socket support tiers; Enterprise repository needs a valid subscription key; the no-subscription repository suits non-production |
| OpenStack (Kolla-Ansible or OpenStack-Ansible) | 2026.1 deployment guides cover both tools; confirm container image and package mirroring for your registry and repositories | No single built-in importer; migration is handled through image conversion and project-specific tooling, so plan it as a separate workstream | Stable branches run about 18 months, then only SLURP releases stay in an unmaintained phase; the operations team is larger than for a hypervisor cluster |
| XCP-ng with Xen Orchestra | XCP-ng 8.3 LTS is the current release; confirm how Xen Orchestra and XCP-ng update packages reach a disconnected pool | Xen Orchestra V2V warm-migrates VMs from ESXi 7 and later, reading VMFS, NFS or vSAN datastores | Xen Orchestra is AGPL-3.0; Vates per-host support plans are optional; confirm the V2V path works without outbound access to the source hosts |
| Harvester | Apache-2.0 and built on Kubernetes, KubeVirt and Longhorn; confirm how container images and OS updates are mirrored into the isolated cluster | vm-import-controller add-on imports VMs from VMware and OpenStack; confirm connectivity between the add-on and the vCenter or ESXi source | Kubernetes skills are required; production hardware minimums apply; SUSE support carries a separate Longhorn entitlement |
| OpenNebula | Apache-2.0 core; confirm repository mirroring for the Community Edition and how Enterprise Edition packages are delivered offline | OneSwap migrates from vCenter 7, 8 and 9 with regular, clone and delta modes; snapshot and SSH prerequisites apply | Maintenance packs and LTS releases come with the annual subscription; the Community Edition is the free path with fewer lifecycle guarantees |
| Apache CloudStack | Apache-2.0 orchestration layer; confirm how KVM hosts and management servers receive packages inside the isolated zone | No direct import; VMware-to-KVM conversion uses virt-v2v on each destination host, so confirm the conversion tooling can be mirrored | Runs vSphere and KVM side by side for a phased exit; LTS releases carry 18 months of fixes; operations skills differ from vCenter |
How to deploy and patch Proxmox VE or OpenStack offline
This sequence takes an isolated data center from a staging network with a package mirror to a verified Proxmox VE cluster that receives patches from internal repositories and migrates workloads in controlled waves. The result is a platform the team can install, update and audit without internet access.
Build the staging network and package mirror
Before the isolated network is cut off, the platform team builds a staging segment with internet access and sets up an internal mirror for the Proxmox VE and Debian package repositories that the cluster will need. Your team, or DeployOpen under a written scope, decides which repositories, mirror tooling and storage size apply. Confirm which Proxmox VE subscription tier your team will hold, because the enterprise repository requires a valid subscription key, while the no-subscription repository is suited to testing and non-production use. The step is done when the mirror serves the required package sets to a test client in staging.
Pull and verify release media and packages
Download the Proxmox VE installation ISO, the package set and any OpenStack deployment artifacts through the staging network, then record checksums and verify the signatures published by each project before anything is carried across the boundary. This is the control that addresses software integrity and authenticity of vendor software and patches, which NERC CIP-013-2 asks utilities to address in procurement. Keep a signed manifest of every file, with its hash and source URL, in the change record. The step is done when each file passes verification and the manifest is approved by the security owner.
Carry verified media across the boundary
Transfer the verified ISO, packages and manifest across the isolated boundary through the approved transfer path, such as a one-way data diode or a controlled removable media process. Re-verify the hashes on the inside, because the transfer path is the most common point where files change or are swapped. Record who performed each transfer and when. The step is done when the inside copies match the manifest and the transfer record is signed off.
Install the cluster with quorum and fencing
Install Proxmox VE on at least three nodes, since the High Availability guidance calls for three cluster nodes to keep quorum reliable. Provide shared storage for guests, redundant hardware and watchdog-based fencing, so a failed node is reset before its guests restart elsewhere. Confirm that the watchdog hardware or software your hosts use is supported before go-live, because fencing that does not work will not protect the guests. The step is done when a test node failure triggers a fence and the guest restarts on another node in a lab run.
Point repositories at the internal mirror
On every node, set the apt sources to the internal mirror instead of the public Proxmox and Debian endpoints, and remove any entries that would reach the internet. Then run an update to confirm that the nodes resolve packages only from the mirror. Keep the repository configuration under version control so later changes are reviewed. The step is done when a package update on each node completes against the internal mirror with no outbound connections.
Migrate VMs in waves
Move workloads in waves, starting with low-impact systems. Use the Proxmox VE import wizard for ESXi and vCenter sources, which Proxmox says it tested from ESXi 6.5 to 8.0. Snapshots slow the import, so remove them first. Disks on vSAN cannot be imported directly, so move those VMs to a supported datastore first. Where the wizard does not fit, use OVF import with qm importovf, qm disk import for VMDK files, or Clonezilla as a fallback for disk-level copies. Each wave is done when the guests boot, network mappings are verified and the rollback point is recorded.
Run the patch cycle from the mirror
Each patch cycle starts in staging: sync the mirror, verify new packages against the manifest, then carry them across the boundary and apply them to a test node first. Roll the update through the cluster one node at a time, moving guests off each node before patching it, and confirm the cluster returns to quorum before the next node. Track the Proxmox VE release life, because the FAQ states support runs at least as long as the matching Debian release has security support. The cycle is done when all nodes report the target package versions and the change record is closed.
Moving VM disks across the boundary without a live connection
Choose the offline migration path by how much the isolated network can reach. The simplest route is direct import from ESXi through the Proxmox VE import wizard, which works only when the source hypervisor is reachable from the Proxmox side inside the enclave. Proxmox documents that this import was tested from ESXi 6.5 to 8.0, so confirm your exact build against that range before the first wave. When the source cannot be reached, export each VM as OVF and import it with qm importovf, or export the VMDK files and attach them with qm disk import. Imaging tools such as Clonezilla are the fallback when the source is constrained, but they require more manual work to restore network and boot settings.
Plan around the three documented limits. Disks backed by vSAN cannot be imported directly, so move those VMs to a standard datastore first, and check how this interacts with any vSAN-to-Ceph plan. VMs with snapshots import more slowly, so consolidate snapshots on the source before export and confirm that the consolidation completed on each disk. Also measure transfer time per VM against your maintenance window, because media for the copy usually moves through a controlled transfer process that the security team will want to log and scan.
After each VM boots on Proxmox VE, check the guest OS drivers. Remove VMware Tools, confirm that the virtio storage and network drivers load, and verify that the NIC mapping and MAC behavior match what your firewall rules expect. For Windows guests, confirm license activation, since hardware changes can trigger reactivation, and record the result as evidence for the change ticket. Keep the source VM powered off but retained until the destination has passed your acceptance tests and a restore test from backup.
Evidence that an air-gapped platform review asks for
An assessor reviewing an isolated virtualization platform will look for proof that every change crossing the air gap was known, approved and reversible. The six artifacts below connect software intake, media transfer, patching, access and resilience, and each one should be producible from records kept during the migration rather than rebuilt afterward. DeployOpen prepares these artifacts, but independent auditors and certification bodies decide what they prove.
Software bill of materials and release hashes
For every package, ISO and image carried into the enclave, keep a list of components with versions and the cryptographic hash published by the upstream project. Proxmox VE, XCP-ng, Xen Orchestra and OpenStack each publish their own release artifacts, so the hash recorded at intake should match the hash checked on the isolated side. Confirm with each project which signing keys and checksum files it publishes before you build the intake procedure. This supports the software integrity and authenticity expectations in NERC CIP-013-2 where that standard applies.
Transfer log and media approvals
Every removable medium or data diode transfer needs a record showing who prepared the media, what it contained, which hashes were verified, who approved the import and when it was loaded. Treat the log as an operational record, not a one-off form. Ask your security team to define who may approve a transfer and whether a second person must verify hashes before the medium crosses the boundary. Gaps in this log are the most common reason an assessor asks follow-up questions.
Internal repository configuration and snapshots
Document how the internal package mirror is built, which upstream repositories it tracks, how often it is synchronized from transfer media, and which snapshot is currently published to hosts. Keep the repository configuration in version control and retain dated snapshots so any host can be pinned to the exact package set it was patched with. Confirm that Proxmox VE hosts are pointed at the internal mirror and that the enterprise repository, which requires a valid subscription key, is either used deliberately or disabled and documented.
Patch test records and rollback steps
Each patch batch should carry a test record showing where it was applied first, which workloads were checked, what the result was and the rollback procedure if it fails. A rollback step is only evidence if it has been rehearsed on a non-production host, so record that rehearsal as well. Include the Debian security status of the platform release in your review, because Proxmox VE versions are supported only as long as the matching Debian release has security support. Plan patch windows around the release lifecycle, not around the date a problem appears.
Management plane access records
Keep a record of who holds administrative access to the cluster web interface, API tokens and hypervisor shells, with the role assigned, the approval for it and the date it was reviewed. Export authentication and privileged-session logs to a location inside the enclave that the platform team cannot silently alter. Confirm how role-based permissions are modeled in your chosen platform and how remote administrative sessions are restricted, since NERC CIP-005-7 expects vendor remote access to be controlled and detectable where that standard applies.
HA and fencing test results
Record each high availability test: a node failure, a network partition, a storage path loss and a watchdog-triggered fence. Proxmox VE HA needs at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware and watchdog-based fencing, so the test record should show each of those conditions in place. Capture the time from failure to guest recovery and whether the failed node was reset before its guests restarted elsewhere. Repeat these tests after any change to hardware, storage or firmware.
Questions buyers ask before choosing an air-gapped platform
What does an air-gapped migration off vSphere cost, and which parts are one-time?
The cost comes from four components: staff time, hardware, Proxmox VE subscriptions and integration work. Hardware for the target cluster and any shared storage is mostly one-time, although refresh cycles recur. Proxmox VE is free and open-source software under the GNU AGPL v3, so the software itself carries no license fee. Support is optional and billed per occupied physical CPU socket per year, with Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, per the Proxmox VE pricing page. Those tiers differ in support tickets and response time and in access to the enterprise repository, which production environments usually need. Recurring costs also include the internal team's time for patching and the mirror infrastructure described below. Ask for a written quote based on a fixed scope that separates one-time build work from recurring support and operations.
How long does an offline VM migration take?
Duration depends mainly on VM count, total disk size, how many VMs carry snapshots and how much transfer capacity the isolated network has. The Proxmox wiki notes that VMs with snapshots import more slowly, and that vSAN-backed disks cannot be imported through the built-in wizard, so those disks need a different path. Plan the work in waves: a pilot group of non-critical VMs, then production groups inside agreed change windows. An illustrative example: a site with a few dozen small Linux VMs on local datastores will move far faster than the same count of large database servers with snapshots, so the schedule should be built from an inventory rather than a generic estimate. Ask for a timeline tied to your inventory and change calendar in the written scope.
Can our internal team run an air-gapped Proxmox VE migration without a partner?
Yes, many teams with Linux and storage skills do this in-house, and the Proxmox import wizard handles much of the configuration mapping for ESXi 6.5 to 8.0 sources. The harder parts are the ones that tend to stall internal projects: building a patch mirror that is verified before it crosses the boundary, designing high availability (which needs at least three cluster nodes, shared storage and watchdog-based fencing), reconciling network and storage mappings, and writing runbooks that an auditor can follow. DeployOpen plans, implements, documents, backs up and supports self-hosted platforms inside the client's own networks, so a partner is one option. Decide based on the skills you already have, and ask any partner for a fixed-scope written proposal that names the deliverables.
What do we need to give a migration team before work starts?
Most engagements begin with a complete inventory and a set of diagrams. The core inputs are:
- A VM inventory with operating systems, CPU, memory, disk sizes, snapshot status and any vSAN-backed disks
- Network diagrams showing VLANs, segmentation, firewall zones and the boundary between the isolated network and any transfer media
- Storage details for existing SAN or NFS arrays and any planned Ceph layout
- Hardware records for each host, including CPU socket counts for subscription sizing
- An approved change calendar, including maintenance windows and rollback criteria
- Named owners for security approval, application sign-off and emergency contacts
Also confirm how software packages will be vetted before they enter the network. Missing inputs usually add scope and push back the first wave, so ask for a checklist in the proposal.
How often do we need to carry patches across the air gap?
The cadence depends on your vendor support status and your own risk policy, not on a fixed number. Broadcom's knowledge base states that perpetual-license ESXi hosts and vCenter keep running after support expires, but downloads of new patches require an active support contract, which is why many teams plan their own patch intake. For Proxmox VE, the enterprise repository requires a valid subscription key and is the recommended repository for production, while the no-subscription repository suits testing. Proxmox VE releases follow the Debian base: Proxmox VE 9.0 was released on August 5, 2025 on Debian 13, and Proxmox VE 8 on Debian 12 reaches end of life in August 2026, so plan a major upgrade path too. Each carry-across should be hashed, scanned and logged, which is the software integrity control that NERC CIP-013-2 asks of supply chain procurement. Confirm the cadence with your security team and vendor terms.
Which compliance controls should the air-gapped design be checked against?
Choose the framework that applies to your sector and map each control to a documented design decision. Utilities subject to NERC CIP typically look at CIP-005-7 for electronic security perimeters, which requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication, and at CIP-013-2 for supply chain verification of software and patches. Public-sector and defense programs may reference other frameworks, and the reader should confirm which applies with their assessor. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
Does the Proxmox VE subscription change what features we get?
No. According to the Proxmox VE pricing page, all subscription tiers include the same software features, and the software can run without a subscription. The tiers differ in support entitlements, meaning ticket allowances and response times, and in access to the enterprise repository. For an isolated production site, the practical question is whether you need vendor support and an enterprise repository feed, which affects how you build your patch intake. Ask the vendor or reseller to confirm current pricing and terms in writing before you budget, since subscription prices can change.
Choosing between Proxmox VE and OpenStack for an offline site
For most offline sites that are replacing a vSphere cluster like for like, Proxmox VE is the better starting point, because it puts KVM, containers, clustering, storage and a single web interface in one product that a small operations team can run. The Proxmox VE high availability model needs at least three cluster nodes, shared storage and watchdog-based fencing, so the hardware decision comes first. Proxmox VE versions are supported for about as long as the matching Debian release has security support, so the team should plan upgrades around the Debian cycle and confirm the current end-of-life date in the Proxmox VE FAQ before committing to a version.
OpenStack fits a different requirement: self-service multi-tenant projects, quotas and APIs that several internal groups consume without tickets. It also brings a heavier operating burden. Deployment with Kolla-Ansible (Docker containers) or OpenStack-Ansible (LXC containers or bare metal) and the ongoing care of Keystone federation, Ceph and Neutron all require staff who can run them without internet access, where every image and package must first be mirrored. Stable branches are maintained for about 18 months, and upgrades are supported between SLURP releases as well as adjacent releases, so the upgrade path must be planned around those windows rather than around a vendor's support calendar.
Confirm which option fits your staffing and hardware through a scoped review before you choose. Ask who will patch the air-gapped site, how many people can operate Ansible-based deployments, whether you can meet the Proxmox VE three-node and shared-storage requirements, and whether internal users need multi-tenant self-service at all. A written scope should list the hypervisor choice, the mirrored repositories, the upgrade calendar and the staff training required, so that the decision is based on your environment rather than on feature lists.
How DeployOpen deploys under air-gap constraints
DeployOpen plans, builds, hardens, documents and hands over self-hosted open-source virtualization inside the client's own isolated network. Each engagement starts with a written scope that names the hosts, storage, repositories and evidence the isolated environment needs before any work begins.
How we scope
- Inventory of ESXi hosts, vCenter workloads, storage types and VMs that cannot be exported cleanly
- Written scope naming the chosen platform, offline repository mirror, transfer path and patch process
- Fixed-scope engagements with deliverables and timelines agreed in writing before work starts
How we build
- Build the offline package mirror and verify every carried package before it crosses the boundary
- Deploy the chosen platform inside the client's data center or air-gapped network, with no internet dependency
- Test VM disk transfers with a pilot wave and record checksums, boot results and network mapping
How we hand over
- Runbooks for offline patching, repository refresh, backup restore and node replacement
- Documentation of configuration, access roles and the evidence trail for the security team
- Handover sessions with the operations team so they run the environment without DeployOpen present
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover scheduled offline update cycles and review of each new release before it is applied
- Confirm with DeployOpen which support scope, response expectations and access model apply to your network
