Indlejret hardwarevirtualisering: krav, anvendelser og konfiguration

Informatic Digital » Recursos » Indlejret hardwarevirtualisering: krav, anvendelser og konfiguration

Indlejret virtualisering på moderne hardware er blevet et nærmest uundværligt værktøj for IT-teams, udviklere og undervisere, der har brug for at opsætte komplekse laboratorier, testmiljøer eller sikkerhedsscenarier uden at fylde datacentret med fysiske servere. Kort sagt giver det dig mulighed for at køre virtuelle maskiner inde i andre virtuelle maskiner, samtidig med at du opretholder acceptabel ydeevne og finjusterer ressourcestyring.

Ud over den typiske "at placere én VM inden i en anden" åbner indlejret virtualisering døren for fleksible DevOps-pipelines, realistiske træningsmiljøer, isoleret sikkerhedstestning og IoT Edge-implementeringer på tværs af forskellige platforme, fra on-premise Hyper-V til virtuelle maskiner på Azure eller VMware ESXi. For at alt skal fungere som forventet, skal hardware- og hypervisorkonfigurationen dog opfylde meget specifikke krav.

Hvad er indlejret virtualisering præcist, og hvorfor er det vigtigt?

Indlejret virtualisering refererer til en virtuel maskines evne til at fungere som virtualiseringsvært for andre interne virtuelle maskiner. Med andre ord er der en hypervisor på øverste niveau på den fysiske hardware (f.eks. Hyper-V i Windows Server eller Azure Local), og i en af ​​dens VM'er installerer vi Hyper-V eller en anden kompatibel hypervisor for at oprette flere VM'er.

I tilfælde af Hyper-V tillader indlejret virtualisering, at Hyper-V-rollen installeres i en gæstevirtuel maskine , der igen kører på en fysisk vært med Hyper-V. Denne "mellemliggende" VM eksponerer processorens virtualiseringsudvidelser for de interne VM'er, som opfører sig, som om de var tættere på hardwaren, selvom der faktisk er flere lag nedenunder.

Denne funktionalitet optrådte oprindeligt i Windows Server 2016 og Windows 10 til Intel-processorer , og supporten er siden udvidet til nyere versioner af Windows Server, Windows 11 og AMD-processorer. I dag er det en moden funktion, som Microsoft integrerer i sin officielle dokumentation, og som tredjepartsløsninger også bruger.

Den praktiske værdi er tydelig: Med indlejret virtualisering kan vi replikere produktionsmiljøer, oprette hele klynger, teste risikable konfigurationer eller simulere flerlagsnetværk uden at investere i nye racks eller reservere datacenterplads. For mange virksomheder opvejer de omkostningsbesparelser og den fleksibilitet, det giver, mere end det lille ydelsesunderskud.

Almindelige anvendelsesscenarier for indlejret virtualisering

Et af de mest populære scenarier er at oprette komplekse testlaboratorier . Udviklings- og QA-teams kan bygge flerlagsapplikationsstakke (databaser, mellemtjenester, frontends) udelukkende inden for en enkelt virtuel maskine og inden for denne hoste alle de interne VM'er, der er nødvendige for at replikere et produktionsmiljø.

Det er også meget nyttigt i tekniske trænings- og udviklingsmiljøer . Instruktører kan opsætte en vært-VM, hvor hver elev opretter sine egne gæste-VM'er, konfigurerer netværk, tester serverroller eller implementerer containere uden nogensinde at røre virksomhedens "rigtige" infrastruktur. Alt er indeholdt i en let bortskaffelig sandkasse.

En anden typisk anvendelse er evaluering og test af nye softwareversioner . I stedet for at ændre følsomme konfigurationer direkte på den fysiske vært kan administratorer replikere scenariet på en indlejret virtualiseret VM og validere programrettelser, nye udgivelser eller sikkerhedsændringer, før de implementeres i produktion.

Indlejret virtualisering spiller også en nøglerolle i at muliggøre avancerede sikkerhedsfunktioner såsom virtualiseringsbaseret sikkerhed (VBS) eller specifikke isolationer, der er afhængige af hypervisorfunktioner på forskellige niveauer. Dette muliggør hærdning af bestemte miljøer uden at kræve yderligere hardware.

Inden for IoT-området er indlejret virtualisering nøglen til Azure IoT Edge til Linux i Windows- scenarier , hvor det er nødvendigt at kombinere Windows-, Linux-containere og hypervisor-funktioner på forskellige virtualiseringslag, både lokalt og på tredjepartsplatforme som VMware ESXi eller virtuelle maskiner i Azure.

Hardware- og softwarekrav til indlejret virtualisering

For at alt dette kan fungere korrekt, er det første filter kompatibel hardware og minimumsversioner af operativsystemer . I Azure On-premises-miljøer kræves f.eks. version 2411.3 eller nyere, sammen med virtuelle maskiner, hvis konfigurationsversion er 10.0 eller nyere, hvilket sikrer understøttelse af de nødvendige virtualiseringsudvidelser.

På processorniveau er det vigtigt, hvis du arbejder med Intel, at Intel VT-x virtualiseringsteknologi er aktiveret i BIOS/UEFI. Til AMD-arkitekturer kræves AMD-V-understøttelse, og til avancerede scenarier skal Secure Encrypted Virtualization (SEV)-teknologi være aktiveret, hvilket tilføjer kryptering til VM'er og forbedrer isolation og lavniveausikkerhed.

Værtsoperativsystemet skal være en moderne version af Windows Server eller Windows 10/11 , korrekt opdateret med de seneste programrettelser. Hyper-V skal være installeret på den fysiske maskine, før man forsøger at aktivere nesting; det er ikke en funktion, der følger med som standard blot ved at have en kompatibel CPU.

Et andet vigtigt punkt er de virtuelle maskiners tilstand. For at ændre processorparametre og eksponere virtualiseringsudvidelser skal den VM, der fungerer som den indlejrede vært, være helt slukket , ikke sat på pause eller i en gemt tilstand. Først da tillader Hyper-V dig at ændre avancerede virtuelle processorindstillinger.

Endelig skal netværksforbindelsen planlægges omhyggeligt. Indlejrede virtuelle maskiner kan kræve ekstern adgang eller adgang til andre lag, så det er tilrådeligt at definere fra starten, om interne switche, NAT, MAC-adresseforfalskning eller andre virtuelle netværksteknikker skal bruges for at undgå kommunikations- og filtreringsproblemer.

Aktivér indlejret virtualisering i Hyper-V ved hjælp af PowerShell

Den mest direkte og detaljerede måde at aktivere indlejret virtualisering i Hyper-V er at bruge PowerShell-cmdlets . Denne metode fungerer på både Windows Server og kompatible klientudgaver og giver dig mulighed for at automatisere konfigurationen på tværs af flere værter eller VM'er konsekvent.

Det første trin er at sikre, at den virtuelle maskine, hvor vi vil installere Hyper-V som gæst, er slået fra fra Hyper-V Manager (Luk ned-indstillingen) eller brug den relevante kommando i PowerShell, for eksempel Stop-VM -Name 'NombreVM'Hvis den forbliver suspenderet eller i en gemt tilstand, vil processorændringerne ikke blive anvendt korrekt.

Når den virtuelle maskine er stoppet, skal du eksponere processorvirtualiseringsudvidelserne for gæsteoperativsystemet ved hjælp af cmdlet'en Set-VMProcessor og indstille indstillingen ExposeVirtualizationExtensions til sand. Denne indstilling giver systemet mulighed for, indefra den virtuelle maskine, at se de funktioner, der er nødvendige for at installere hypervisorroller.

For at bekræfte, at handlingen blev udført korrekt, kan vi bruge Get-VMProcessor kombineret med Select i feltet ExposeVirtualizationExtensions. Dette kontrollerer, om værdien er indstillet til sand i den virtuelle processorkonfiguration på den virtuelle målmaskine, og forhindrer, at et delvist konfigureret miljø startes.

Hvis det på noget tidspunkt bliver nødvendigt at vende konfigurationen tilbage – for eksempel under en diagnosticeringsopgave eller fordi indlejrede VM'er ikke længere er nødvendige – skal du blot gentage den samme processor-cmdlet , men ændre værdien til falsk, hvilket igen deaktiverer eksponeringen af ​​virtualiseringsudvidelser for gæste-VM'en.

Når den virtuelle processor er konfigureret, tændes maskinen ved hjælp af Start-VM eller fra Hyper-V Manager . Fra gæsteoperativsystemet installeres den komplette Hyper-V-rolle derefter ved hjælp af de sædvanlige metoder: Server Manager (Tilføj roller og funktioner), DISM, PowerShell osv. Fra det tidspunkt opfører VM'en sig som en ekstra Hyper-V-vært fra administratorens perspektiv.

Netværkskonfiguration og MAC-spoofing i indlejrede miljøer

Når processordelen er færdig, er næste trin netværksforbindelse til de indlejrede virtuelle maskiner . Hvis vi ønsker, at de interne VM'er skal kommunikere med andre netværk, internettet eller computere på højere niveau, er det vigtigt at justere visse parametre i den virtuelle adapter på den mellemliggende VM.

I Hyper-V er det almindelig praksis at aktivere MAC-adresseforfalskning på netværkskortet på den VM, der fungerer som den indlejrede vært. Denne funktion giver interne VM'er mulighed for at sende trafik ved hjælp af deres egne MAC-adresser gennem den samme adapter og omgå blokering eller filtrering på den fysiske værts virtuelle switch.

Denne justering kan foretages fra PowerShell ved hjælp af cmdlet'en Set-VMNetworkAdapter med parameteren MacAddressSpoofing indstillet til Til, anvendt på den tilsvarende netværksadapter for den virtuelle maskine. Dette sikrer, at trafik fra dybereliggende virtuelle maskiner ikke tabes af hypervisoren på øverste niveau.

For mere avancerede konfigurationer anbefales det at foruddesigne topologien for virtuelle switche og NAT-instanser på hvert lag. For eksempel kan vi kombinere interne switche for at isolere laboratorier, routingregler eller firewalls mellem lag og NAT på den mellemliggende vært for at give internetadgang til flere indlejrede VM'er uden at eksponere dem direkte.

Når man arbejder med flere virtualiseringslag, er forbindelsesproblemer ofte relateret til deaktiveret MAC-spoofing, forkert sammenkædede NAT-regler eller alt for restriktive firewalls . Gennemgang af disse punkter og genstart af netværkskort eller tjenester på hvert lag løser normalt de fleste forbindelsesproblemer i indlejrede miljøer.

Brug af den grafiske brugerflade til relaterede opgaver

Selvom den strenge aktivering af indlejret virtualisering styres fuldstændigt fra PowerShell, er mange relaterede opgaver i praksis mere bekvemme via Hyper-V Managers grafiske brugerflade , især hvis vi administrerer flere værter eller ønsker at gennemgå konfigurationen visuelt.

En typisk arbejdsgang involverer at åbne Hyper-V Manager, finde den virtuelle målmaskine og sikre, at den er slukket ved hjælp af indstillingen Luk ned. Dette supplerer brugen af ​​PowerShell og forhindrer utilsigtet start af en VM, der endnu ikke har alle dens parametre korrekt konfigureret.

Når de nødvendige cmdlets til at eksponere virtualiseringsudvidelserne er blevet udført, kan vi vende tilbage til det grafiske miljø og åbne VM-konfigurationsvinduet . Derfra er det nemt at gennemgå og ændre egenskaberne for netværkskortet, antallet af tildelte virtuelle processorer eller den hukommelse, der er tilgængelig for den indlejrede vært-VM.

Muligheden for at aktivere MAC-adresseforfalskning findes i netværkskortets avancerede indstillinger . Aktivering via den grafiske brugerflade er hurtig og gennemsigtig for administratorer, der foretrækker en visuel tilgang, eller som ikke har lært alle cmdlet-parametrene udenad.

Når denne konfiguration er fuldført, kan den daglige miljøadministration udføres enten fra Hyper-V-konsollen på den fysiske vært eller i den indlejrede VM ved hjælp af standardværktøjer til at oprette nye VM'er, konfigurere switche, tilføje roller eller tage snapshots i henhold til behovene i hvert laboratorium.

Indlejret virtualisering i Azure On-Premise og IoT Edge-scenarier

I Azure On-Premise-miljøer er indlejret virtualisering baseret på de samme principper, men tilføjer specifikke versionskrav og understøttelse af avancerede funktioner såsom AMD SEV eller sikkerhedsudvidelser . En minimum systemversion (2411.3 eller nyere) er påkrævet, og VM'er skal bruge en kompatibel konfigurationsversion (10.0 eller nyere).

Når du arbejder med Azure IoT Edge til Linux på Windows, er der tre understøttede muligheder for indlejret virtualisering . Hver især adresserer forskellige infrastrukturbehov og det kontrolniveau, som organisationen ønsker at opretholde over det underliggende miljø og hypervisoren.

Den første mulighed involverer implementering af IoT Edge på en virtuel Windows-maskine på en lokal vært med Hyper-V . Dette er den mest ligefremme fremgangsmåde: indlejret virtualisering aktiveres på den pågældende Windows VM, og derefter installeres og konfigureres Azure IoT Edge til Linux på Windows i henhold til Microsofts specifikke dokumentation.

I dette tilfælde er det afgørende at sikre, at Hyper-V-rollen er korrekt installeret på den lokale vært (Windows Server eller Azure Local) . Uden Hyper-V aktiv på værten vil gæste-VM'en ikke kunne fungere som en indlejret hypervisor eller eksponere de funktioner, der kræves til IoT Edge, i et ekstra lag.

Disse typer implementeringer er meget nyttige, når du har brug for at integrere IoT-enheder, Linux-containere og Azure-tjenester i eksisterende Windows-infrastrukturer, og dermed opretholde en rimelig balance mellem fleksibilitet, ydeevne og nem administration.

Indlejret virtualisering med VMware ESXi og Azure IoT Edge

Et andet interessant scenarie opstår, når vi ønsker at køre Azure IoT Edge til Linux på Windows i en virtuel Windows-maskine, der hostes på VMware ESXi . I denne sammenhæng er indlejret virtualisering afhængig af VMware-hypervisorens funktioner i stedet for Hyper-V direkte på hardwaren.

VMware ESXi version 6.7 og 7.0 inkluderer eksplicit understøttelse af hardwareassisteret virtualisering i gæster , hvilket muliggør den indlejring, der er nødvendig for, at en Windows VM kan blive en Hyper-V-vært. VMware dokumenterer denne funktion i sin vidensbase og beskriver krav og potentielle ydeevneovervejelser.

Den generelle procedure involverer først oprettelse af en Windows VM på ESXi-værten , idet man følger VMwares standardanbefalinger for processorer, hukommelse, lagerplads og netværkskort. Når den er oprettet, lukkes den virtuelle maskine ned for at give mulighed for at ændre dens avancerede CPU-indstillinger.

Fra ESXi- eller vSphere Client-grænsefladen skal du vælge Windows VM, gå til Rediger indstillinger , og i afsnittet CPU-indstillinger skal du finde afsnittet hardwarevirtualisering. Der skal du aktivere indstillingen "Vis hardwareassisteret virtualisering til gæsteoperativsystemet" , som giver Windows mulighed for at se VT-x/AMD-V-udvidelserne, selvom det kører i ESXi.

Når du har gemt ændringerne og genstartet den virtuelle maskine, skal du fortsætte med at installere Hyper-V-hypervisoren på Windows , enten på en klientudgave (Windows 10/11) eller på Windows Server. Sørg for at inkludere administrationsværktøjerne og eventuelle yderligere komponenter, der kræves til de containere eller tjenester, der skal bruges med IoT Edge.

Indlejret virtualisering i virtuelle Azure-maskiner

Når vi tager scenariet op på et højere niveau og arbejder direkte med virtuelle maskiner i Azure som en indlejret virtualiseringsvært , kommer platformens særheder i spil, især med hensyn til de virtuelle switche og standardnetværket, der bruges af Azure VM'er.

Azure IoT Edge til Linux på Windows anses ikke for at være native understøttet på nogen Azure VM, der kører en server-SKU, medmindre et specifikt script køres for at aktivere en passende virtuel switch. Dette script åbner en standardswitch, der tillader IoT Edge-miljøet at fungere korrekt med det ekstra virtualiseringslag.

Microsofts officielle dokumentation beskriver trinnene til at oprette og konfigurere en virtuel switch til Linux på Windows i Azure-kontekst, og dermed tilpasse netværkskravene til containere og Edge-tjenester til cloud-netværksinfrastrukturens karakteristika.

I disse typer implementeringer er det særligt vigtigt at gennemgå VM-SKU'en, lagertypen samt CPU- og RAM-kvoterne , da indlejret virtualisering tilføjer sit eget overhead, og interne VM'er kan forbruge ressourcer intensivt, hvis hele sættet ikke er korrekt dimensioneret.

Trods disse kompleksiteter er fordelen betydelig: en Azure VM kan bruges som en test-, udviklings- eller præproduktionsplatform til IoT Edge-løsninger under de samme betingelser, der senere vil blive replikeret på fysiske edge-enheder eller industrielle gateways, der implementeres i felten.

Sikkerhedskopiering af indbyggede Hyper-V VM'er med specialiserede løsninger

Et aspekt, der ofte overses, når man designer indlejrede virtualiseringsmiljøer, er strategien for backup og disaster recovery . Det er her, backupløsninger på virksomhedsniveau kommer i spil, da de er i stand til korrekt at administrere Hyper-V-miljøer med flere virtualiseringslag og flere platforme, der kører parallelt.

Blandt disse løsninger er værktøjer som Vinchin Backup & Recovery , der understøtter mere end femten forskellige virtualiseringsplatforme, herunder VMware, Proxmox, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack og selvfølgelig Hyper-V. Denne type software er designet til heterogene infrastrukturer, hvor hypervisorer fra forskellige producenter sameksisterer.

Funktioner som permanent trinvis backup, datadeduplikering og -komprimering samt granulære gendannelser reducerer lagerforbruget og den tid, det tager at gendanne individuelle maskiner, specifikke filer eller endda specifikke objekter fra kritiske applikationer, betydeligt.

Derudover hjælper planlagte backuppolitikker og arkiveringsmuligheder til bånd eller skyen med at skræddersy backupstrategien til de lovgivningsmæssige eller interne krav i hver organisation, hvilket opretholder lange opbevaringsperioder uden at øge lageromkostningerne i højtydende arrays.

Den webbaserede administrationskonsol forenkler beskyttelsen af ​​Hyper-V-miljøer med indlejrede VM'er i høj grad: Du vælger de VM'er, der skal beskyttes, vælger backup-lageret, definerer udførelsesstrategien (tidsvinduer, backuptype, opbevaring) og starter jobbet. Mange af disse løsninger tilbyder omfattende prøveperioder, der varer flere uger, for at evaluere deres ydeevne og integration med eksisterende infrastruktur.

Begrænsninger og bedste praksis i indlejrede miljøer

Selvom mulighederne for indlejret virtualisering er omfattende, er der også tekniske begrænsninger pålagt af selve hypervisorernes design , som bør forstås fra starten for at undgå overraskelser i produktions- eller højtilgængelighedsscenarier.

Et tydeligt eksempel er live-migrering af VM'er ved hjælp af indlejret virtualisering . I øjeblikket er det ikke muligt at udføre en live-migrering af en primær vært, mens dens VM'er indeholder gæster, der er afhængige af aktiv indlejring. Microsoft dokumenterer denne begrænsning, og den generelle anbefaling er at planlægge opdateringer eller værtsflytninger med kontrollerede nedlukninger i disse miljøer.

Overvågning af ressourceforbrug på tværs af flere lag kræver en kombineret strategi. Det anbefales at bruge Hyper-V Manager, performance counters og cmdlets som Get-VM på den øverste vært og samtidig bruge lignende værktøjer i den indlejrede vært for at få et klart overblik over, hvordan belastningen er fordelt på tværs af CPU, hukommelse, netværk og lager.

Når en intern VM pludselig mister netværksforbindelsen, er det normalt et symptom på ændringer i firewallregler, NAT-problemer eller deaktivering af MAC-spoofing-indstillinger på en af ​​de involverede adaptere. Kontrol af alle niveauer, verificering af konfigurationen og genstart af de berørte netværkstjenester løser normalt de fleste af disse afbrydelser.

Som en generel bedste praksis er det tilrådeligt at definere miljøets mål, antallet af lag, de typer af arbejdsbelastninger, der skal køres, og backuppolitikken klart, før man implementerer indlejret virtualisering. Dette indledende design vil afgøre, om laboratorie- eller testmiljøet er bæredygtigt på lang sigt og ikke bliver et virvar, der er svært at vedligeholde.

Kort sagt giver indlejret virtualisering af Hyper-V og andre platforme dig mulighed for at få meget mere ud af eksisterende hardware og opsætte laboratorie-, test-, sikkerheds- eller IoT Edge-scenarier med enorm fleksibilitet, så længe CPU-krav, systemversion og netværkskonfiguration respekteres, og alt dette ledsages af en god overvågnings- og backupstrategi.

Relateret artikel:

Komplet guide til Windows Server: Hvad det er, hvad det bruges til, og dets versioner