
Air gapped cloud upgrades with Atmosphere release manifests
Air gapped cloud on OpenStack: how Atmosphere's digest-pinned release manifests move a release across the boundary, and what the manifest leaves out.
Lire la noteNotes de terrain / Dernières nouvelles
Des notes d’ingénierie issues de l’exploitation d’infrastructures ouvertes : pannes, décisions de conception et travail upstream qui améliorent l’infrastructure ouverte.
Parcourir toutes les notes
Air gapped cloud on OpenStack: how Atmosphere's digest-pinned release manifests move a release across the boundary, and what the manifest leaves out.
Lire la note
Learn when your team needs OpenStack consulting services and how expert support can help with deployments, migrations, upgrades, and operations.
Lire la note
Assess enterprise AI readiness before investing in GPUs. Explore 12 key factors covering data, models, infrastructure, governance, operations, and costs.
Lire la notevSphere 8 end of support is Oct 11, 2027. Count back from your renewal date and migration estimates to find when the VMware decision is due.
vSphere 8 end of support arrives on October 11, 2027, but the date your team has to act on comes earlier: the latest day it can approve an evaluation, or your next Broadcom renewal if that falls first.
If your estate looks like Gartner's 2,000-VM model, the arithmetic puts the latest scoping start around December 2026, and a migration of the reported length still finishes after patches stop, so the renewal you sign before then has to cover the overlap.
vSphere 8 reaches end of general support on October 11, 2027. The date is not new: by June 2026, vendors were already calling it confirmed.
Broadcom's March 2025 reminder for vSphere 7 shows what such a date means in practice: after October 2, 2025, customers "will not be able to receive product support, security patches and updates."
Two later dates need a careful read.
The first is end of technical guidance, listed for vSphere 8 as October 11, 2029. For vSphere 7, Broadcom footnoted that phase: "Does not apply to Broadcom contracts. Applicable to valid VMware contracts only." If your agreement is a Broadcom one, leave 2029 out of the plan until your account team confirms in writing what it covers.
The second is an extension. Broadcom moved vSphere 7's end of general support from April 2, 2025 to October 2, 2025, and The Register reported in July 2024 that it gave no reason. The same March 2025 reminder told customers to ask their Broadcom representative about Extended Support. Both exist. Broadcom grants both on its own schedule, so a plan that only works with an extension depends on the vendor you may be trying to leave.
Gartner's assessment "Estimating a Large-Scale VMware Migration", as reported by The Register, puts projects at 18 to 48 months for an organization running 2,000 or more VMs on at least 100 servers. Initial scoping needs seven to ten full-time staff for a month, and technical evaluation of replacements needs another six people for up to nine months. By some estimates, a full migration can take three or more years.
Count those back from end of support as a scenario, and replace each reported estimate with your own as soon as you have it:
Two different dates come out of this. The evaluation start date tells your team when it has to approve the work. The migration-complete date tells it how long the renewal has to cover. For an estate that resembles Gartner's 2000+ VM model, the first date lands in late 2026 and the second lands after October 2027, which is why the renewal carries so much weight. A smaller estate or a shorter evaluation moves both. A production proof of concept that kills a node and fails an upgrade halfway through is one way to keep evaluation short without making it shallow.
Our VMware exit program puts that scoping first: its assess phase records VM counts and owners, maps dependencies and sets the renewal timeline next to them before any production change.

Because these migrations run so long, most users would need to renegotiate licenses with Broadcom at least once before finishing, and Broadcom prefers two- or three-year subscriptions.
Put your renewal date on the same line as the dates above. If your current subscription ends before October 2027, that renewal is the first hard decision, and its term sets how long you pay for VMware while the replacement comes up. A three-year term signed in early 2027 ends in early 2030. Whether that term is the right length depends on your own migration estimate, and on costs you can price now: the renewal commitment, migration services, internal staff time, parallel infrastructure during the overlap, landing-zone hardware and ongoing operations on the new platform.
Letting the renewal date slip while you decide has a price of its own. In March 2025, the French arm of the distributor Arrow told its VMware partners that Broadcom would add a 20% penalty to the first-year price of subscriptions not renewed on their anniversary date, according to The Register. Your own contract decides whether any such penalty applies to you.
The edition you renew into may also be different from the one you have now. In December 2025, Broadcom said that VMware vSphere Foundation was "no longer available in some EMEA countries" and named none of them.
The migration budget also falls inside the overlap. External services can cost between $300 and $3,000 per VM for organizations of the size Gartner modelled. On our side, a parallel runway keeps VMware stable while OpenStack is tested with representative workloads and production-like cutovers, so the months you pay Broadcom for at renewal are months in which waves move.
These inputs have no reliable public figure, so fill them in from your own data:
People argue about staff ramp-up more than any other input. When the VDDK story reached Hacker News on September 7, one commenter called OpenStack "about an order of magnitude more complicated" and said "you probably want a team."
The line item behind them is real: someone has to run the new platform on call after cutover, starting with the pilot. If that someone is your team, our support model puts 24/7 migration and Day 2 support behind it; if it is us, fully managed means we run operations, upgrades and patching, monitoring and incident response, hosted in our data centers or on hardware in your facilities.
October 2027 does not force anyone off VMware, and for some estates staying is the cheaper choice.
Broadcom's own path is an upgrade. It released VMware Cloud Foundation 9.0 on June 17, 2025, and upgrading to it keeps the platform your team already runs. If many workloads depend on VMware-specific networking, storage or backup features, a replacement means redesigning them, and staying may cost less over a three-year term. Our earlier walkthrough of recreating NSX and vSwitch networks in Neutron with OVN shows what that redesign involves for networking alone. In exchange for staying, you accept the subscription terms described above.
For an estate that holds perpetual licenses, third-party support keeps it running without a Broadcom renewal. However, none of it produces new Broadcom patches, so ask either provider what they do on the day a critical ESXi vulnerability is published.
Gartner's Palmer named public cloud as a destination for some of the workloads leaving VMware, with the caution that infrastructure-as-a-service "is not suitable for every virtualized workload and can be costly." She also noted that hyperscalers can no longer sell VMware subscriptions for their hosted VMware services, so customers must buy them directly from Broadcom. Lifting VMware into a hyperscaler moves the hardware and keeps the renewal. Refactoring onto native services is a separate program, and Palmer put assessing which applications are ready for re-platforming, and moving those, at up to a year.
With your own team, upstream OpenStack can be a legitimate path. However, there are instances where OpenStack is the wrong fit and teams are not ready to run it.
The take does not hold for an estate well below Gartner's 2,000-VM model, which may finish inside 13 months and feel little pressure from the renewal. It shifts if your current subscription already runs past October 2027: the renewal stops being the first trigger, and the evaluation start date becomes the first date to manage. And if you have already decided to stay on VMware, your dates belong to an upgrade window with its own planning.
Two dates you already hold set the deadline: the renewal date in your contract, and the latest evaluation start counted back from October 11, 2027 through your full migration plan, landing zone included. If your estate looks like Gartner's model as The Register reported it, scoping and evaluation alone put that start around December 2026. Waiting to learn whether Broadcom repeats its vSphere 7 extension only spends that lead time.
Each path sets the next VMware term differently. An upgrade to VCF 9 needs a quote and term for the edition Broadcom actually offers in your country. A partial exit keeps both platforms running for as long as the remaining workloads stay, so the VMware term has to cover those workloads and the budget has to cover running both. A full exit needs a migration estimate built from your own inventory and a named owner for on-call on the new platform, and then the term only has to reach the migration-complete date.
For an exit to OpenStack, the migration-complete date leans heavily on the wave count, and the wave count depends in part on how much of each move has to fit inside a change window. We built MigrateKit, our open-source migration CLI, to move as much of each VM as possible while it keeps running. The first migration cycle copies the whole VM to OpenStack, and each later cycle copies only the blocks changed since the last one, using VMware's change tracking, which has to be enabled on every VM you plan to move. Cutover checks that the Neutron ports exist, syncs, powers the VM off in VMware, runs a final sync and builds the new instance on OpenStack from the volumes it has been syncing.
That changes the arithmetic in two places. The aim is to move most of the copy out of the change window, and your pilot shows how much actually moves. Each window has to hold the guest shutdown, the final sync, the virt-v2v-in-place conversion MigrateKit runs by default and the boot, and you can time all four on your pilot VMs before you set the wave count. If change tracking resets for a disk, the next migration cycle copies that whole disk again. Copy cycles do not take the VM offline, so whether they may run during a freeze that blocks cutovers becomes a question for your change board, and the answer decides how many weekends the freeze really costs.
We have operated OpenStack since 2011, and the migrations we support follow the order this post counts back through: assess the estate, build the landing zone, move a pilot group, then move production in waves. Vanilla Forums is one example.
In a 2018 Superuser case study, we managed the client's two private OpenStack clouds (in Montreal and the US) and saw the company reach six times its original hosting footprint without growing its ops team. Our team can work alongside yours under a support model, or take on deployment, upgrades, monitoring and incident response under a managed one.
MigrateKit is the part of that work that protects your change windows. It is open source under the Apache license, so your team can read its code before it touches a production VM. It copies each VM while the VM runs, then copies only the changed blocks on each later pass, so the cutover window holds the shutdown, the final sync, the conversion and the boot, and a pilot measures all four before anyone signs off the wave plan. It reads disks through VMware's VDDK, so confirming your VDDK access belongs in that pilot too.
For a team still choosing a path, a consultation call sets the dates in this post against your own estate: its size, your renewal date and the path you are leaning toward. A call with our team can work through which of your two dates governs and what a first pilot wave would look like.
Choose from Atmosphere Cloud, Hosted, or On-Premise.
Simplify your cloud operations with our intuitive dashboard.
Run it yourself, tap our expert support, or opt for full remote operations.
Leverage Terraform, Ansible or APIs directly powered by OpenStack & Kubernetes