Vad guiden gör – och inte gör

Den här guiden visar hur du bygger en vendor-anpassad installations-ISO för ESX i en VCF 9.1.x-miljö med vSphere Lifecycle Manager, vLCM. Resultatet kan användas för nyinstallation eller återinstallation av kompatibla servrar. Samma deklarativa image bör även bevaras som JSON-metadata och vid behov som offline-bundle för fortsatt lifecycle-hantering.

Detta skapar inte en ny OEM-certifiering. En egen ISO är bara ett paketeringssätt för komponenter som du själv har valt. Servermodell, I/O-enheter, firmware, ESX-version, Vendor Add-on och drivrutiner måste fortfarande vara kompatibla enligt Broadcom Compatibility Guide och hårdvaruleverantörens matris. Blanda inte paket från olika serverfamiljer bara för att exporten går igenom.

Skärmbilder och menytexter kan förändras mellan 9.1-patchnivåer. Guiden beskriver därför både arbetsflödet och en verifieringspunkt efter varje steg. Följ alltid den aktuella Broadcom-dokumentationen parallellt och prova aldrig en ny image direkt på ett helt produktionskluster.

Förstå komponenterna i en vLCM-image

En deklarativ vLCM-image består normalt av fyra lager. Basen är en specifik ESX-version och build. Ovanpå den kan du välja exakt ett Vendor Add-on från exempelvis serverleverantören. Därefter kan du lägga till fristående komponenter, till exempel en certifierad nätverks- eller lagringsdrivrutin. Ett Hardware Support Manager-tillägg kan dessutom koppla firmware och drivrutinskontroll till den önskade imagen när leverantören stöder detta.

Vendor Add-on är inte samma sak som en gammaldags komplett vendor-ISO. Det är en separat OEM-leverans som vLCM kombinerar med Broadcoms basimage. Den modulära modellen gör det möjligt att uppdatera basimage utan att manuellt packa om en äldre installationsskiva, men den innebär också att du måste välja kompatibla versioner medvetet.

Exporten kan ge tre typer av artefakter. JSON-filen beskriver önskat innehåll men innehåller inte alla binärer. En offline ZIP-bundle innehåller programvarupaketen och kan importeras i en annan depot. Den startbara ISO-filen är främst avsedd för installation eller återställning. För löpande uppdatering av kluster är den deklarativa imagen och dess depot-innehåll viktigare än själva ISO-filen.

Den deklarativa imagen byggs av betrodda komponenter, valideras och exporteras. Testhosten är en obligatorisk kontrollpunkt före användning i produktionskluster.

Steg 1: definiera målplattformen

Dokumentera serverleverantör, modell, generation, bootläge, lagringskontroller, nätverkskort, HBA, GPU eller andra acceleratorer och aktuell firmwarebaseline. Notera även målversionen av ESX och vilken VCF 9.1.x-build miljön använder. Skapa inte en generell ISO för maskiner som har olika kompatibilitetskrav; bygg hellre separata image-profiler per hårdvarufamilj.

Kontrollera servern och samtliga kritiska enheter i Broadcom Compatibility Guide. Jämför sedan med OEM-leverantörens supportmatris. Vendor Add-on och drivrutin ska vara avsedda för både aktuell serverfamilj och vald ESX-release. Om en äldre certifierad Vendor Add-on saknas i Broadcoms portal behöver den normalt hämtas från OEM-leverantören, eftersom Broadcom enligt sin publiceringspolicy bara kan visa den senaste certifierade leveransen för en viss huvudversion.

Verifieringspunkt: En signerad ändringsbilaga listar servermodell, firmwarebaseline, ESX-build, Vendor Add-on, extra komponenter, käll-URL, filhash och ägare. Varje kombination kan spåras till en aktuell supportmatris.

Steg 2: hämta endast betrodda paket

Hämta ESX-depot eller basimage från Broadcom Support Portal med organisationens giltiga entitlement. Hämta OEM Vendor Add-on och eventuella firmwarepaket från Broadcom eller serverleverantörens officiella supportportal. Fristående drivrutiner ska komma från Broadcoms eller enhetstillverkarens officiella distributionskanal och uttryckligen stödja vald ESX-version.

Spara ursprungligt filnamn, publiceringsdatum, versionsnummer och SHA256-hash i ett manifest. Kontrollera signaturstatus och skanna filerna i en isolerad stagingyta. Byt inte namn på paket på ett sätt som tar bort versionsinformationen. Lägg aldrig community-VIB:ar, labbdrivrutiner eller osignerade paket i en image som ska användas i supportad VCF-produktion utan ett formellt undantag och tydlig konsekvensanalys.

Observera att vSphere 9.1 lägger till SHA256 för själva image-definitionen när den exporteras och importeras mellan vCenter-instanser. Broadcom betonar att detta inte är en checksumma av varje ESX-VIB. Behåll därför även egna hashar för hämtade källfiler.

Verifieringspunkt: Alla filer finns i en skrivskyddad stagingyta, har kontrollerad källa och hash och kan kopplas till ett godkänt change-ärende.

Steg 3: fyll vLCM-depån

Öppna Lifecycle Manager i vSphere Client och kontrollera först depotens anslutning och synkroniseringsstatus. I en internetansluten miljö kan basimage och tillgängliga tillägg redan finnas i depån. I en frånkopplad miljö importerar du i stället signerade offline bundles från stagingytan.

vCenter 9.0 och senare har tagit bort funktionen Import ISO från Lifecycle Manager. Försök därför inte importera en gammal OEM-ISO som startpunkt. Importformaten är offline bundle till vLCM-depån samt JSON-image till Image Library, ett vLCM-kluster eller en fristående host. Om du bara har en vendor-ISO behöver du hämta motsvarande Vendor Add-on eller offline bundle från OEM-leverantören.

Använd Lifecycle Manager-vyns importfunktion för offlinepaket. Efter importen kontrollerar du att rätt Vendor Add-on och komponentversioner går att välja när en image skapas. Om ett tillägg saknas är det inte säkert att man ska ersätta det med senaste versionen; verifiera först firmwarekrav och servergeneration.

Verifieringspunkt: Basimage, exakt Vendor Add-on och alla extra komponenter visas i depån med förväntade versioner. Inga okända eller äldre paket har smugit sig in genom tidigare synkroniseringar.

Steg 4: skapa en tillfällig image-bärare

Ett praktiskt GUI-arbetsflöde är att skapa ett tomt, tillfälligt kluster som bara används för att komponera och exportera imagen. Ge det ett tydligt namn, exempelvis ISO-BUILD-<vendor>-<modell>-<datum>, och välj att klustret ska hanteras med en enda vLCM-image. Inga produktionsvärdar behöver flyttas till detta kluster.

I klustrets image-konfiguration väljer du den avsedda ESX-basimagen och rätt Vendor Add-on. Spara grundkonfigurationen och öppna sedan Edit för att lägga till de extra komponenter som verkligen behövs. Ett paket som redan ingår i Vendor Add-on ska normalt inte läggas till en gång till som fristående komponent. Undvik också att använda en host som referens innan du har granskat vilka historiska VIB:ar som då riskerar att följa med.

I större miljöer kan motsvarande flöde automatiseras med vSphere API eller VCF PowerCLI. PowerCLI-kommandot Export-LcmVMHostDesiredState kan exportera en hosts önskade tillstånd som JSON och, med val, som installerbar ISO eller offline-bundle. Använd hostbaserad export först när hostens önskade image är känd, ren och godkänd.

Verifieringspunkt: Image-definitionen visar exakt en basimage, högst ett Vendor Add-on och bara de godkända extra komponenterna. Det tillfälliga klustret innehåller inga värdar eller arbetslaster.

Steg 5: kör kompatibilitets- och imagekontroller

Kör vLCM:s image validation innan export. Lös dependency-fel, konflikter, saknade paket och förbjudna nedgraderingar; ignorera dem inte genom att byta ut paket på måfå. Om Hardware Support Manager finns ska firmware- och drivrutinskontrollen också vara grön. Utan HSM behöver firmwarematchningen dokumenteras manuellt mot OEM-matrisen.

Jämför den önskade imagen med en representativ testhost om en sådan finns. En host som redan innehåller en annan OEM-customization kan rapportera inkompatibilitet eller otillåten nedgradering. Det är en signal om att image-definitionen eller migreringsplanen måste granskas, inte ett skäl att forcera remediation.

Granska särskilt bootkritiska drivrutiner för lagringskontroller, NIC och HBA. Kontrollera att den exporterade installationsimagen kan se installationsmålet och managementnätet. För servrar som använder separat firmwareverktyg eller OEM-managementplugin ska den proceduren ingå i samma changeplan.

Verifieringspunkt: vLCM-valideringen är godkänd, hårdvarukompatibiliteten är dokumenterad och inga varningar om beroenden, signaturer eller nedgraderingar återstår utan ett godkänt undantag.

Steg 6: exportera ISO, JSON och offline-bundle

Öppna det tillfälliga klustrets Updates/Image-vy. Använd menyn med fler åtgärder och välj Export. Exportera installations-ISO för bare-metal-installation. Exportera samtidigt JSON-definitionen och en offline ZIP-bundle om imagen ska kunna återskapas eller flyttas till en annan vCenter-instans utan samma depotanslutning.

Namngiv artefakterna konsekvent, till exempel ESX-9.1-build-vendor-modell-addonversion-yyyymmdd. Skapa en checksumma för varje exporterad fil och lägg den tillsammans med manifest, vLCM-definition, testprotokoll och källhänvisningar. ISO-filen bör lagras i en begränsad innehålls- eller artefaktkatalog och inte på en öppen filyta.

Tänk på att JSON-filen ensam bara beskriver imagen. Om mål-vCenter saknar motsvarande binärer måste offline-bundlen importeras innan JSON-definitionen kan användas. En lyckad ISO-export betyder inte heller att kombinationen är supportad; exporten verifierar paketeringen, inte hela serverns certifieringskedja.

Verifieringspunkt: ISO, JSON och eventuell offline-bundle har unika filnamn, SHA256-hashar och ett gemensamt manifest. En andra administratör kan identifiera exakt vilka komponenter som ingår utan att montera ISO-filen.

Steg 7: prova installationen på en testhost

Starta en representativ, icke-produktionskritisk server från ISO-filen via virtuell media eller en säkert skapad USB-enhet. Bekräfta UEFI- och Secure Boot-beteende, att installationsdiskarna känns igen, att management-NIC fungerar och att installationen slutförs utan oväntade VIB- eller signaturfel.

Efter första boot kontrollerar du version och build, aktiva drivrutiner, storage paths, nätverkslänkar, sensorer och eventuella OEM-managementproviders. Lägg hosten i ett isolerat testkluster som använder samma deklarativa image och kör compliance check. En nyinstallerad host bör vara compliant med den image som ISO-filen exporterades från.

Genomför reboot, maintenance mode, vMotion-test och relevant lagrings- och nätverksprov. Om imagen är avsedd för en VCF-workload domain ska även kommissionering och prechecks provas enligt VCF:s aktuella arbetsflöde innan bred användning.

Verifieringspunkt: Testhosten installerar, startar och blir compliant utan manuella VIB-installationer efteråt. Alla bootkritiska enheter fungerar och testprotokollet är godkänt.

Steg 8: inför kontrollerat och förvalta som kod

Använd först ISO-filen för nyinstallation eller break-glass-återställning. För befintliga kluster bör uppdateringar ske genom vLCM:s önskade image, precheck, maintenance mode och kontrollerad remediation – inte genom att starta om varje host från ISO. VCF:s överordnade lifecycle-arbetsflöden måste respekteras för workload domains; undvik en fristående vCenter-remediation som gör att VCF tappar önskat tillstånd eller supportbarhet.

Versionshantera JSON-definition, manifest och testresultat. Själva vendor-paketen kan ligga i en artefaktdepå med åtkomstkontroll och retention. När basimage, Vendor Add-on, drivrutin eller firmware ändras skapar du en ny immutable version i stället för att skriva över den gamla. Kör samma validering och testsvit för varje ny revision.

Ta bort det tillfälliga byggklustret först när export, dokumentation och test är klara. Behåll inte flera oidentifierade ISO-filer i driftmiljön. Definiera även när en image ska pensioneras och hur snabbt en sårbar drivrutin kan spärras från framtida installationer.

Verifieringspunkt: Produktionsinförandet har changefönster, rollback, hostordning och ansvarig godkännare. Den deklarativa imagen – inte bara ISO-filen – är bevarad och kan återskapas.

Vanliga fel att undvika

  • Importera inte en gammal vendor-ISO till vCenter 9.x; ISO-import i vLCM är borttagen.
  • Blanda inte Vendor Add-on för en serverfamilj med firmware från en annan generation.
  • Lägg inte till en extra drivrutin om samma eller rättare version redan finns i OEM-tillägget.
  • Tolka inte lyckad export som bevis på Broadcom- eller OEM-support.
  • Flytta inte imagen direkt till hela produktionsklustret utan representativ testhost.
  • Spara inte bara JSON-filen när målmiljön saknar paketen; bevara även offline-bundlen.
  • Använd inte installations-ISO som ersättning för deklarativ vLCM-remediation av befintliga kluster.
  • Forcera inte förbi dependency-, downgrade- eller signaturfel.

LabOps IT:s bedömning

Att bygga en egen vendor-anpassad ISO med vLCM är framför allt ett sätt att göra installationen reproducerbar. Den stora vinsten är inte själva skivavbilden utan den deklarativa image-definitionen, spårbarheten och möjligheten att använda samma kombination i depot, testkluster och framtida återställning.

VCF 9.1:s checksumma för image-definitionen förbättrar transportkontrollen, men organisationen behöver fortfarande verifiera källfiler, kompatibilitet och faktisk funktion på hårdvaran. Säkrast är att behandla varje image som en signerad release: källor, hashar, komponentlista, godkännande och testresultat följer artefakten hela vägen.

Den viktigaste gränsdragningen är mellan installation och lifecycle. ISO-filen installerar hosten. vLCM-imagen och VCF:s lifecycle-arbetsflöden håller miljön i önskat tillstånd. Om bara ISO-filen sparas har man byggt en engångsprodukt; om definition, paket och tester bevaras har man byggt en förvaltningsbar process.

Källor