OpenStack-projektet offentliggjorde 2026.2 Hibiscus den 30 september 2026. Det är projektets 34:e samordnade version. En ny versionsetikett är i sig inget skäl att byta en fungerande molnplattform. Det intressanta för infrastrukturspecialister är att flera tjänster nu tillför verifierbara möjligheter inom skyddad beräkning, nätverksintegration och delad lagring. Ändringarna är utgivna i den nya serien, men deras praktiska tillgänglighet beror på distribution, fysisk hårdvara och vilka drivrutiner som faktiskt används.
Nova kan starta konfidentiella virtuella maskiner
Nova stöder nu instanser med AMD SEV-SNP och Intel TDX. Teknikerna krypterar VM-minne och använder hårdvarustöd för att minska den åtkomst som värdsystemets privilegierade programvara normalt har. SEV-SNP lägger till integritetsskydd och möjlighet till signerad attestering; TDX erbjuder en motsvarande modell på kompatibla Intelplattformar. Det är en betydelsefull arkitekturmöjlighet för känsliga arbetslaster i delad infrastruktur, men den löser inte automatiskt identitet, nätverksisolering eller skydd av data på lagringsmediet.
Operatören kan begära SEV-SNP med extraegenskapen hw:mem_encryption_model=amd-sev-snp på en flavor eller motsvarande image-egenskap hw_mem_encryption_model. För TDX används intel-tdx. En flavor är OpenStacks mall för resurser och egenskaper; kravet behöver alltså knytas till de instanstyper som ska få placeras på lämpliga värdar. Kontrollera CPU-modell, firmware, värdkärna, KVM, libvirt, QEMU och gäststöd mot den valda distributionens dokumentation. Nova-stöd i källkoden är inte bevis för att befintliga servrar eller färdiga distributioner redan uppfyller alla förutsättningar.
En skyddad VM bör testas som ett helt arbetsflöde. Skapa en separat instanstyp, starta på en verifierat kompatibel värd och kontrollera att placeringen verkligen ger begärd krypteringsmodell. Låt därefter arbetslastens ägare granska attesteringsrapporten enligt den egna tillitsmodellen. Prova även om backup, snapshot, evakuering och migration stöds för just denna typ av instans. För vissa skyddade gäster kan vanliga driftåtgärder ha andra begränsningar än för en traditionell KVM-VM; anta inte funktionslikhet utan ett acceptansprov.
Acceleratorer och VM-migrering får mer precis hantering
Nova kan nu hantera Cyborg-styrda mediated devices, exempelvis vissa vGPU-resurser, via en ny MDEV-bindning. Samtidigt kan Novas egen hantering av sådana enheter finnas kvar. En ny ägaregenskap ska förhindra att båda vägarna försöker schemalägga samma resurs. Detta är relevant för AI- och VDI-miljöer som använder delade acceleratorer. Inventera dock GPU-modell, värddrivrutin, Cyborg-drivrutin och gästlicensiering innan en befintlig pool ändras.
Nova kan också lossa en instans från en låst tillgänglighetszon, flytta den till en annan zon och vid behov låsa den där igen, utan att återskapa VM:n. Funktionen använder en ny API-mikroversion. Separat stöds kall migrering och storleksändring av instanser med virtiofs-anslutna Manila-shares; resursen monteras på destinationsvärden och hålls kvar på källan tills ändringen bekräftas. Det förbättrar återgångsmöjligheten, men beskrivs inte som stöd för live migration av samma kombination. Testa därför den faktiska migreringsvägen och kontrollera API-versionen i klient och distribution.
Neutron kan koppla tenantnät till EVPN-fabric
Hibiscus lägger till en EVPN-tjänsteplugin och en OVN-agentutökning som kan annonsera BGP EVPN Type-5-rutter via FRR. Syftet är att göra IP-prefix för tenantnät synliga i datacenterfabricen. För organisationer med EVPN i underlaget kan detta minska behovet av separata, manuellt underhållna ruttkopplingar. Funktionen är en integrationsmöjlighet, inte ett löfte om att varje befintlig EVPN-fabric fungerar utan konfiguration.
Nätverksteamet bör prova en avgränsad tenant i labb och verifiera vilka prefix som annonseras, vilken route target och VNI som används, samt hur borttagning och failover syns i fabricen. Granska även hur den nya möjligheten för direkt routbara tenantadresser via OVN:s leak_routes samverkar med brandväggar och säkerhetsgrupper. Ett fel i route-policy kan påverka betydligt fler arbetslaster än en enskild VM.
En annan, smalare driftsförbättring gäller ML2/OVS-installationer med HA-routrar: OpenStack anger mer än femton gånger lägre minnesfotavtryck för övervakningen av keepalived-status efter att en daemon ersatts med ett skalskript. Det är ett projektspecifikt mått för denna komponent, inte en generell prestandagaranti för Neutron. Mät effekten i den egna topologin innan kapacitetsplanen ändras.
Manila breddar lagringsvalen men skärper certifikatkraven
Manila får drivrutiner för Weka och Lustre, två parallella filsystem som ofta används för datatunga AI- och HPC-arbetslaster. Weka-drivrutinen kan exponera shares via WEKAFS-klient eller NFS och mappar varje Manila-projekt till en Weka-organisation i en multitenantinstallation. Lustre-drivrutinen arbetar mot ett i förväg etablerat filsystem och kräver Lustre 2.16 eller senare. Dessa integrationer ger nya val för delad fillagring, men kräver separat kontroll av drivrutinernas åtkomstmodell, kvoter och nätverk.
För befintliga lagringsmiljöer finns ändringar som kan vara viktigare än nya drivrutiner. Manilas API för share-migrering är inte längre experimentellt från mikroversion 2.96. Dell PowerScale får asynkron återgång till snapshot och HPE Alletra MP B10000 får fler snapshotåtgärder. Samtidigt är TLS-certifikatverifiering nu aktiverad som standard i Manilas drivrutiner för Pure Storage FlashBlade, Hitachi HSP och NetApp ONTAP. Miljöer med egna certifikat måste tillhandahålla rätt CA-kedja eller installera certifikatet i systemets trust store före uppgradering. Stäng inte av verifieringen som permanent genväg; kontrollera anslutningen i en testmiljö.
Uppgradering behöver styras tjänst för tjänst
Hibiscus är inte en SLURP-version. OpenStacks Skip Level Upgrade Release Process låter operatörer på föregående SLURP-version, 2026.1 Gazpacho, planera en direkt uppgradering till förväntade 2027.1 Indri och därmed hoppa över Hibiscus. En organisation som behöver funktionerna nu kan förstås välja att införa Hibiscus, men ska då läsa versionsnoteringarna för varje installerad tjänst och sin distributions stödda väg. En släppt upstreamversion betyder inte att varje leverantörspaket är färdigt.
Det finns särskilda övergångsrisker. Horizon aktiverar nya standardvärden för RBAC-scope, Manila kräver policygranskning där äldre scopebeteende använts, och flera tjänster går från eventlet mot Pythontrådar. Freezer tar bort sitt v1-API. Inventera därför API-klienter, egna policyfiler, backupjobb och integrationsskript innan ett uppgraderingsfönster bokas. Kör tester med representativa tenantroller: visa, skapa, migrera och återställa resurser, inklusive negativa test där åtkomst ska nekas.
LabOps IT:s bedömning
Vår bedömning är att Hibiscus når nyhetströskeln genom summan av konkreta arkitekturförändringar. Konfidentiella VM:ar kan ge en ny tillitsgräns för känsliga arbetslaster; EVPN-kopplingen kan förenkla nätverksarkitektur i rätt fabric; Manila kan ansluta fler parallella filsystem. Den största praktiska risken är att behandla versionsnumret som ett enda kompatibilitetsbesked. Planera införandet som flera separata piloter med mätbara kontrollpunkter för säkerhet, placering, ruttannonsering, lagringsåtkomst och återställning.
För miljöer utan omedelbart behov av dessa funktioner är en planerad uppgradering rimligare än ett brådskande byte. Säkerhetsrättningar i enskilda tjänster måste bedömas separat mot installerade versioner och leverantörens backportar; en ny huvudversion är inte alltid enda sättet att få en relevant fix.