Michael Schmidt 
Almost every piece of VMware® exit guidance, including most of what is on this site, assumes something it never states: that the cluster you are landing on can reach the internet. The assumption hides in ordinary sentences. Install the operator. Pull the driver. Register the cluster. Convert the disk with the migration toolkit. Each of those is a network call to somewhere outside the datacentre, and in a normal estate nobody notices, because the call succeeds.
In a disconnected estate every one of them fails, and they fail in the same afternoon.
Defence programmes, classified enclaves, public-sector networks, OT and industrial control environments, and regulated finance all run large vSphere estates. They are on exactly the same Broadcom licensing clock as everyone else, and they have the hardest exit of anyone, because the published migration playbooks were written for teams with egress. What follows is the version for teams without it.
One clarification first, because these two topics get merged constantly and they are not the same problem. This is not an article about data sovereignty. Sovereignty is a question about where data and keys sit and whose law reaches them, and it is covered separately in achieving data sovereignty in 2026. This is a question about operations with no route out: a cluster that cannot resolve a public DNS name, let alone pull from it, and that still has to run stateful production workloads after vSphere is gone.
What a disconnected estate removes from the migration plan
The instinct on these teams is usually that offline installation is a solved problem. It is a fair instinct. The vSphere estate itself was almost certainly built offline: vCenter came off an ISO, patches came in as offline bundles, and the whole apparatus was designed in an era when a management appliance installed once and then sat there.
Kubernetes platforms do not behave that way, and this is the single biggest surprise in a dark-site exit. A one-time offline install is not the same thing as ongoing offline operation. A Kubernetes platform pulls container images continuously, not once: every node reboot, every pod reschedule, every scale-out, every operator upgrade, every certificate rotation that restarts a controller. A cluster that installed cleanly from a mirror in March will fail to bring up a replacement node in July if the mirror lost an image or the platform moved a tag. The dependency is not a step in a runbook. It is a permanent condition of the platform.
Once you accept that, the four failing assumptions become concrete:
- A reachable container registry. Not one image, dozens, across the distribution, the CSI layer, the virtualization stack, and every operator.
- An operator catalogue that resolves. On Red Hat® OpenShift® the catalogue is itself a set of images served from a public index, and OperatorHub is empty in a disconnected cluster until it is mirrored and the catalogue source is repointed.
- A vendor control plane to register with. Any storage or platform product whose management runs as a service somewhere else is simply out of the running, not degraded.
- A licence that validates over the network. Anything that phones out to check entitlement will fail closed at the worst possible moment, which in a migration is during cutover.
There is a fifth that only shows up in storage, and it is worth naming separately because it is the one that survives everything else: the NVMe over TCP initiator is part of the mainline Linux kernel. It is not a download, not a vendor agent, not a signed third-party module. On a supported node it is a modprobe nvme-tcp and an entry in /etc/modules-load.d/, which is the same in a dark site as it is on a laptop with fibre. The transport under the whole storage layer needs no egress because it is already on the machine.
What the storage layer needs mirrored, and what needs nothing at all
The useful way to plan this is not as an install guide but as a dependency inventory: for each piece, does it need egress, a one-time mirrored artefact, or nothing.
| Dependency | Needs a route out? | How it is handled offline |
|---|---|---|
| Container images (control plane, storage plane, CSI) | One-time mirror, refreshed per version | Synchronise the vendor’s image repository into a local registry such as Artifactory or Nexus, then point the install at the local registry |
| Deployment tooling | One-time mirror | The helm-deployer image carries the deployment tooling, so the chart repository does not have to be reachable from the cluster |
| Storage control plane | No | Runs inside your own cluster. There is no external control plane and no call-home requirement |
| Licence validation | No | Nothing to validate over the network at run time |
| NVMe/TCP transport | No | In-kernel on supported distributions, loaded with a module, not installed |
| Snapshot and clone operations | No | Local to the storage cluster; no external service participates |
| S3 backup target | No egress needed | The backup configuration accepts a local endpoint, so an on-premises or in-cluster object store is a first-class target rather than a workaround |
Table 1: Storage dependency inventory for a disconnected deployment.
Three of those rows are the ones worth arguing about with a vendor before you shortlist anything, because they are architectural and cannot be fixed with a mirror.
The first is where the control plane lives. Simplyblock’s control plane and storage plane both run on your own infrastructure, managed by an operator installed from a single Helm chart, and the site states plainly that there is no external control plane and no call-home requirement. That sentence has been sitting in a post about FIPS-compliant storage for months, framed as a compliance property. In a migration it is a schedule property: a product whose management plane is a hosted service is not a candidate you have to evaluate offline, because it is not a candidate at all.
The second is what happens to snapshots. A cutover in a disconnected site cannot stage anything through a cloud bucket, so the snapshot and clone path has to be complete inside the cluster. It is, and the same is true of backup: the cluster’s backup specification takes a localEndpoint, which means a local S3-compatible store is the normal configuration rather than a documented exception.
The third is the mirror itself. Simplyblock publishes the required images to a single organisation in a public registry and documents the disconnected path as: synchronise that repository into your local registry, then run the ordinary installation with the image locations pointed at the local copy. The helm-deployer image is the recommended entry point and carries the deployment tooling with it. Notably, the vendor does not attempt to specify how you mirror, and that is the correct division of labour, because in a dark site the answer is whatever your change-control process already approves.
Where the offline translation is not clean
A dark-site reader spots a hand-waved install path immediately, so here is the honest half. None of the following is a reason to keep paying for vSphere. All of it is work you will do anyway, and it is cheaper to know now.
Image lists drift between versions. A mirror that was complete for one release is not automatically complete for the next. This is not specific to storage, it is true of every component in a Kubernetes platform, and it is the reason disconnected estates end up pinning versions much harder than connected ones. Treat the mirror set as a versioned artefact with an owner, verify it against the exact release you are pinning, and re-verify before every upgrade rather than after a node fails to come up.
Storage is one row in a much longer mirror manifest. No storage layer removes the need to mirror the distribution itself, the virtualization operator, the migration toolkit, the observability stack, and the operating system package repositories that feed your nodes. On the plain Linux deployment model the control plane and storage nodes want a Red Hat-based distribution at version 9 on the current patch level, and those packages come from your own Satellite or local mirror, not from a storage vendor. Budget for the manifest, not for one product.
The registry becomes infrastructure, with everything that implies. It is now a single point of failure for cluster recovery, a change-control object, and a thing that drifts when you have more than one site. Two enclaves with two independently maintained mirrors will diverge, and the divergence surfaces as a node that will not join in the site nobody has touched for a quarter.
Compliance gates do not shrink because the architecture got simpler. Estates carrying STIG hardening baselines, FedRAMP obligations, or impact-level requirements have review cycles that run in months. A storage layer with no external dependencies materially shortens the review, because there is no egress path to justify and no third-party service in scope, but it does not remove the gate. Plan the exit around the review calendar rather than the technical one.
Some sites are small, and that changes the shape rather than the plan. Compact and remote enclaves run on constrained hardware, including ARM64, and the storage components can be confined to labelled worker nodes rather than spread across every node in the cluster. That is a deployment shape, not a different architecture. If the site genuinely needs synchronous protection across two locations, that is a separate design question and it is worked through in the vSAN stretched cluster replacement post.
Planning an exit in an enclave that cannot reach the internet? Bring your mirror constraints, your compliance calendar, and your site inventory, and we will map which pieces need a mirrored artefact and which need nothing at all. Talk to a storage architect
A cutover sequence that assumes no route out
The ordering below is not the connected sequence with a mirror bolted on the front. It is different in one important way: the version freeze happens before anything is installed, because in a disconnected estate the version you mirror is the version you are married to for the whole migration window.
- Freeze versions first, then build the mirror. Pin the distribution, the virtualization operator, the migration toolkit, and the storage release together, as one set, and mirror them as one set. Record the manifest somewhere that survives the project.
- Prove a node rebuild before you migrate a workload. Delete a worker and let the platform rebuild it entirely from the mirror. This is the test that distinguishes a working mirror from a mirror that happened to be warm in a cache. Do it before any production data is involved.
- Stand up storage and validate the local paths. Install the operator, create the cluster and pool, then exercise the three operations the cutover depends on: provision a volume through a StorageClass, take and restore a snapshot, and write and restore a backup to the local object store. All three are local by design, so a failure here is a configuration problem, not a connectivity one.
- Migrate in waves sized by the frozen version, not by the calendar. Every wave runs against the same pinned set. If a wave needs a newer component, it is a new mirror cycle with its own change control, which is precisely why waves should be sized to finish inside one.
- Re-verify the mirror before the last wave and before every upgrade. The final wave is usually the most important workload and it is the one that runs furthest from the day the manifest was built.
| Decision | Connected estate | Disconnected estate |
|---|---|---|
| Component versions | Roll forward as releases land | Frozen per migration wave, mirrored as one set |
| Storage management plane | Hosted or self-hosted, both viable | Self-hosted only, and it must be a hard requirement in the shortlist |
| Cutover staging | Cloud object store is an easy option | Local snapshot and clone, plus a local S3 endpoint |
| Recovery from node loss | Pull from upstream, minutes | Pull from the local mirror, so the mirror is a recovery dependency |
Table 2: What changes in the exit plan when the cluster has no egress.
The reason this reads as more discipline rather than more architecture is that the storage layer is doing very little that is special. It installs from a mirror like everything else, and then it operates entirely inside the cluster. That is the whole differentiator, and it is worth being clear that it is a negative property: the value is in the dependencies that are absent. For the environment-level view of where this fits, see edge and air-gapped storage and private cloud storage; for the install mechanics in their ordinary connected form, the hyperconverged install walkthrough is the fastest way to see what the offline version is a variation of.
Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. In a disconnected estate that matters for a mundane reason. There is no metering call to make, so entitlement is a contract question rather than a run-time dependency.
Questions and Answers
Can simplyblock be installed in an air-gapped Kubernetes cluster?
Yes, and it is a documented deployment path rather than a special case. The required images for the control plane, the storage plane, and the CSI driver are published to a single organisation in a public container registry, and the disconnected procedure is to synchronise that repository into a local registry such as JFrog Artifactory or Sonatype Nexus, then run the ordinary installation with image locations pointed at the local copy. The helm-deployer image is the recommended entry point because it carries the deployment tooling with it. After installation there is no external control plane and no call-home requirement, so the cluster operates with no route out at all.
What is the difference between an air-gapped exit and a data sovereignty requirement?
They answer different questions and frequently apply to the same estate without overlapping. Sovereignty is about where data and encryption keys sit and which jurisdiction can reach them, and a sovereign deployment may still have full internet egress. A disconnected deployment is about operating with no route out, and it may sit entirely inside one country’s borders without that being the point. Teams that need both should treat them as two sets of requirements, because a product can satisfy one and fail the other.
Does the NVMe/TCP data path need internet access?
No. The initiator is part of the mainline Linux kernel rather than a vendor agent, so on a supported distribution it is loaded as a module and made persistent with a file in /etc/modules-load.d/. Nothing is downloaded and no external service participates in the data path. This is one of the practical reasons an NVMe/TCP fabric travels well into isolated environments: the transport is already on every node before you install anything.
Can snapshots and backups work without an internet connection?
Yes. Snapshot and clone operations are local to the storage cluster, and the backup configuration accepts a local endpoint, which makes an on-premises or in-cluster S3-compatible object store a first-class backup target rather than a workaround. That matters specifically during a migration cutover, because a disconnected site cannot stage volume data through a cloud bucket and needs the entire snapshot and restore path to complete inside the cluster.
What is the biggest planning mistake teams make on a disconnected VMware exit?
Treating the mirror as an installation step instead of permanent infrastructure. A Kubernetes platform pulls images continuously, so the mirror is a recovery dependency for the life of the cluster, not a one-time bootstrap. The practical consequence is to freeze component versions per migration wave, mirror them as one manifest with a named owner, and prove a full node rebuild from the mirror before any production workload moves. Teams that skip the rebuild test usually discover an incomplete mirror months later, during an unplanned node replacement.
