Det finns många bra saker du kan göra ovanpå dagens moderna hypervisor-system som ger ett bra sätt att lösa affärsproblem och tekniska utmaningar. En av de riktigt bra sakerna du kan göra med dagens hypervisorer som VMware vSphere är att du kan konfigurera nested virtualisering. Detta öppnar många olika möjligheter att testa och köra hypervisorer inom VMware vSphere.

Ett vanligt användningsfall som många har funnit för att köra nested virtualisering inom VMware vSphere är att köra Microsofts Hyper-V hypervisor för testning och inlärning.

I det här inlägget kommer vi att ta en titt på att konfigurera nested Hyper-V VMs på en VMware ESXi-server och se hur detta kan konfigureras för användning i ett labb eller annan miljö.

Vad är nested virtualisering

För att dyka in i hur man konfigurerar VMware vSphere för att aktivera nested virtualisering av Hyper-V inne i en ESXi-server, låt oss ta en titt på vad nested virtualisering är exakt. När vi tänker på nested virtualization talar vi om att köra en hypervisor inuti en hypervisor. Det betyder att du kan köra hypervisorer av typ 1 som VMware vSphere ESXi och Hyper-V inuti en virtuell maskin ovanpå, i det här fallet, VMware vSphere ESXi.

Hypervisorn som körs i den virtuella maskinen ovanpå VMware vSphere ESXi-servern ser helt enkelt den virtuella maskinvaran som sin fysiska värdmaskinvara på vilken den kan köra virtuella gästmaskiner. Detta möjliggör några mycket intressanta scenarier när du använder din VMware vSphere-miljö som värd för andra hypervisorer som Microsoft Hyper-V.

En viktig punkt att göra när det gäller VMware vSphere är att inbäddad virtualisering av andra hypervisorer som Hyper-V inuti en VM i vSphere inte är ett scenario som stöds. Det är inte bara andra hypervisorer utanför VMware vSphere. Inte ens ESXi som körs inuti en fysisk ESXi värdmiljö stöds. Detta noteras officiellt av VMware i KB-artikeln Support for running ESXi/ESX as a nested virtualization solution (2009916).

Följande konfigurationer är tekniskt möjliga när man kör VMware ESXi inuti andra hypervisorprodukter från VMware, men stöds inte. Detta inkluderar följande.

• VMware ESXi/ESX som körs i VMware Workstation eller VMware Fusion
• VMware ESXi/ESX som körs i VMware ESXi/ESX
• VMware ESXi/ESX som körs i andra hypervisor-lösningar från tredje part

Körning av Hyper-V faller förstås in under samma typ av stödförklaring. Det finns bara en situation där nästlad virtualisering stöds och det är den nästlade vSAN Witness-appliansen.

Utefter detta stödda användningsfall med vSAN Witness-appliansen stöds inte nästlad virtualisering för produktionsmiljön. Med andra ord, om du stöter på problem när du använder nested virtualization får du klara dig själv med support.

Så länge du förstår stödscenariot med nested virtualization är det en utmärkt funktion att utnyttja för andra ändamål. Den kan användas mycket effektivt för labbmiljöer, dev, test och andra liknande typer av scenarier.

Varför köra Hyper-V inuti VMware

Varför vill du köra en hypervisor inuti en annan hypervisor? Mer specifikt, varför vill du köra Hyper-V inuti en VMware ESXi VM? Som redan nämnts är detta inte en konfiguration som stöds för produktionsanvändning. Att köra Hyper-V inuti VMware ger många stora fördelar. Låt oss titta på följande:

• Labbmiljöer
• Ingen ytterligare hårdvara eller nätverksutrustning krävs
• Enklare tillhandahållande och nedmontering av Hyper-V-värdar

Labbmiljöer

Det här är utan tvekan det vanligaste användningsfallet för tillhandahållande av en Hyper-V-värd inuti en virtuell maskin i VMware. Nested virtualization gör det mycket enkelt att tillhandahålla labbmiljöer, dev, test och andra möjliga användningsfall. Hyper-V-laboratorier kan användas för:

• Lärande
• Mjukvarutestning
• POC’ing Hyper-V för olika delar av infrastrukturen eller som ersättning
• Mimifiera en Hyper-V-miljö i en annan del av infrastrukturen
• Patchtestning

I många små och medelstora miljöer finns det kanske bara tillgång till en VMware vSphere-miljö och inga Hyper-V-värdar. Om administratörer vill få tag på en Hyper-V-värd för att lära sig och utveckla sina färdigheter utanför VMware ESXi-hypervisorn, ger de nested virtualiseringsfunktioner som finns i VMware vSphere det perfekta sättet att tillhandahålla en Hyper-V-värd i en VMware vSphere-miljö.

Ingen ytterligare maskinvara eller nätverksutrustning behövs

Med den här möjligheten att nesta Hyper-V inuti VMware vSphere finns det inget behov av att hitta ytterligare maskinvara för en laboratoriemiljö eller en POC av något slag. Allt detta kan tillhandahållas inom vSphere. De robusta virtuella nätverksfunktioner som finns i vSphere gör det också möjligt att tillhandahålla alla specialiserade nätverk som du behöver om du bestämmer dig för att tillhandahålla ett Hyper-V-kluster. Detta kan inkludera Live Migration-, lagrings- och klusternätverk för att bara nämna några. Med hjälp av virtuella portgrupper för växlar kan du enkelt simulera de konfigurationer som annars skulle kunna åstadkommas med fysisk nätverksutrustning.

Enklare tillhandahållande och nedmontering av Hyper-V-värdar

Den här fördelen är inte specifik för nested virtualisering utan snarare för VMware vSphere-virtualisering i allmänhet. VMware har mycket omfattande automatiseringsverktyg inklusive PowerCLI. Detta gör det möjligt att enkelt starta och förstöra virtuella maskiner när du behöver dem. Hela labbkonstruktioner kan automatiseras för provisionering och deprovisionering. Detta tjänar till att göra nested virtualisering ännu mer användbar med de enkla möjligheterna att automatisera din infrastruktur.

Krav för nested Hyper-V VMs på en VMware ESXi-server

När du har bestämt dig för att använda dig av nested virtualisering, kan du då helt enkelt bara skapa en ny VM i vSphere ESXi och börja ladda upp din Hyper-V VM? Tja, inte precis, men processen är ändå mycket enkel att använda när man tänker på den enorma komplexitet som krävs under ”huven” för att nested virtualization faktiskt ska fungera. Det finns egentligen två huvudområden att ta hänsyn till när det gäller kraven för att köra nested Hyper-V VMs på en VMware ESXi-server. Detta inkluderar:

• Exponera hårdvaruassisterad virtualisering för gästoperativsystemet
• Aktivera MAC-adressförfalskade överföringar

Låt oss ta en titt på var och en av dessa och deras betydelse för att köra nested Hyper-V VMs på en VMware ESXi Server.

Exponera hårdvarustödd virtualisering för gästoperativsystemet

Detta första krav kommer du att finna vara absolut nödvändigt. Det är en inställning under inställningarna för den enskilda VM som du använder för att hysa din Hyper-V-installation. Redigera inställningar på din inbäddade Hyper-V VM, expandera CPU och placera en kryssruta bredvid Expose hardware-assisted virtualization to the guest OS (Exponera maskinvaruassisterad virtualisering till gästoperativsystemet).

Aktivering av maskinvaruunderstödd virtualisering i VMware för en Hyper-V VM

Vad händer om du inte aktiverar den här flaggan för maskinvaruunderstödd virtualisering i VMware för din Hyper-V VM? Du kommer inte att se något fel när du bara installerar ditt Windows Server-operativsystem eftersom det fungerar som att installera vilken annan VM som helst. Men när du kommer till punkten att installera Hyper-V-rollen kommer du att se ett fel om den här inställningen inte är aktiverad för den virtuella maskinen. Lägg märke till felet nedan: ”Hyper-V kan inte installeras: Processorn har inte nödvändiga virtualiseringsfunktioner”.

Som en sidoanmärkning måste den här flaggan vara inställd för antingen Hyper-V Core-installationer eller med Hyper-V-rollen installerad i Windows Server med Desktop Experience installerad. Den här förmågan krävs i alla nästlade installationer av Hyper-V-rollen i VMware vSphere.

Fel vid installation av Hyper-V-rollen när flaggan för hårdvaruvirtualisering inte är inställd på VMware VM

Du kan också ställa in den här flaggan med lite PowerCLI-kod som gör att du enkelt kan ställa in flaggan på den angivna VM:en.

$vmName = ’MyHyperVVM’

$vm = Get-VM -Name $vmName

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec

$spec.nestedHVEnabled = $true

$vm.ExtensionData.ReconfigVM($spec)

Aktivering av Promiscuous Mode och MAC Address Forged Transmits

Om du konfigurerar en nested Hyper-V-installation i VMware vSphere vill du troligen inte bara kunna installera en server med Hyper-V-rollen utan också köra en nested Hyper-V VM ovanpå den nested Hyper-V-server som du kör.

Du kanske inte bryr dig om att ha möjlighet till nätverksanslutning till Hyper-V VM, men du kanske vill kunna etablera riktig nätverksanslutning till den inbäddade virtuella maskinen som körs ovanpå den inbäddade Hyper-V-värden i den virtuella VMware-maskinen.

Om du vill ha den här funktionaliteten finns det ett par nätverkskonfigurationsinställningar som du kan behöva göra på din VMware vSwitch som den inbäddade Hyper-V-värden är ansluten till.

Du kan behöva göra detta eftersom det finns ett nytt framsteg i VMware vSwitch-tekniken och nästlad virtualisering sedan lanseringen av VMware vSphere 6.7. Innan VMware vSphere ESXi 6.7 släpptes implementerade VMware inte MAC-inlärning på en vSwitch på samma sätt som i en riktig fysisk switch. Detta gällde antingen vSphere Standard Switch eller vSphere Distributed Switch.

Då detta är fallet med VMware vSwitch före vSphere 6.7, när en virtuell switch tar emot paket som inte har en MAC-adress som matchar den inbäddade hypervisorvärdens vmnic:s pNIC MAC-adress (i fallet med en inbäddad ESXi-värd), tappas paketen.

För att komma runt den här begränsningen finns det två inställningar som måste aktiveras på vSwitch, promiscuous mode och forged transmits.

Konfigurera promiscuous mode och forged transmits på en VMware vSwitch

Hur är det med vSphere 6.7 och högre? Innan vSphere ESX 6.7 släpptes började VMware arbeta på området för nested virtualisering och MAC-inlärningsfunktionalitet i samband med virtuella switchar. En ”MAC Learning Fling” släpptes som introducerade MAC learning-funktionen så att du inte behövde aktivera promiscuous mode och förfalskade sändningsinställningar.

Denna inställning implementerades med lanseringen av VMware vSphere 6.7 ESXi.

Vad är kraven för den nya MAC Learning-funktionen i ESXi 6.7?

Det finns några krav som du måste ha på plats innan du kan dra nytta av den nya MAC learning-funktionen i vSphere 6.7. De är följande:

• Uppgradera vCenter Server och ESXi-servrar till vSphere 6.7
• Kör vSphere Distributed Switch (vDS)
• Uppgradera vDS till den senaste versionen (6.6)
• Hanteras per vSphere Distributed Switch Port Group basis
• Hanteras för närvarande med vSphere API

En sak att notera är att den nya MAC Learning-funktionen med vSphere 6.7 och en vDS 6.6 vSwitch inte är aktiverad som standard. Du måste ställa in flaggorna på lämpligt sätt med API:et.

För att göra den här processen mycket enklare har William Lam, Staff Solution Architecture, skrivit ett par PowerCLI-funktioner som gör det extremt enkelt att kontrollera statusen för MAC Learning och ställa in MAC Learning i din vSphere-miljö. Ladda ner Williams PowerCLI-skript från hans Github-arkiv här:

https://github.com/lamw/vghetto-scripts/blob/master/powershell/MacLearn.ps1

Ett exempel på utdata från funktionen Get-MacLearn som kontrollerar en vSphere Distributed Switch Port Group ser ut som nedan. Notera fälten:

• MacLearning
• NewAllowPrimiscuous
• NewForged Transmits
• NewMacChanges
• Limit
• LimitPolicy

Det här är hur en vDS 6.7 vSwitch-portgrupp ser ut med standardinställningar.

Kontroll av status för MAC Learning på en vSphere 6.7 vDS-switch

För inbäddade ESXi-installationer, och i förlängningen Hyper-V VM:s som körs i din vSphere ESXi-hypervisor, vill du ställa in inställningarna på följande:

• MAC Learning: true
• Promiscuous mode: False
• Forged Transmit: False
• Forged Transmit: False: True
• MAC Changes: True
• MAC Changes: False
• Limit: 4096 (du kan ställa in detta eller låta det vara standardvärdet)
• Limit Policy: Drop (du kan ställa in detta eller låta det vara standardvärdet)

Ovanstående rekommendationer kan ställas in med följande PowerCLI-kod:

• Set-MacLearn -DVPortgroupName @(”DPG-Servers”) -EnableMacLearn $true -EnablePromiscuous $false -EnableForgedTransmit $true -EnableMacChange $false

Som vi nu förväntar oss, som du märker ovan, är inställningen för Promiscuous-läget konfigurerad till False. Även om MAC Learning är aktiverat är Forged Transmit fortfarande inställd på True.

Med MAC Learning-funktionen som finns i vSphere 6.7 kan du undvika några av de säkerhetsmässiga konsekvenserna av att köra en nästlad VM i din vSphere 6.7-miljö genom att förhindra att promiscuous mode behöver aktiveras.

Kan man säkerhetskopiera nischade miljöer?

Även om körning av nischad virtualisering endast stöds av VMware vSphere för vSAN Witness-apparaten, kan det hända att du vill säkerhetskopiera din nischade miljö om du kör nischade Hyper-V VM:er inuti VMware vSphere ESXi. Kan detta göras?

Ja, absolut.

Med hjälp av en modern säkerhetskopieringslösning, som Vembu BDR Suite, kan du säkerhetskopiera inte bara din produktionsmiljö för VMware vSphere eller Microsoft Hyper-V, utan även alla nästlade installationer av ESXi eller Hyper-V som du kan ha i miljön.

Avsluta

Nästlade Hyper-V VM:er på en VMware ESXi-server ger dig möjlighet att leka med Hyper-V, även om du bara har en VMware vSphere-miljö. Som framgår finns det många bra användningsområden för nested virtualisering. Detta inkluderar inlärning, mjukvarutestning, POC’ing och patching av dina Hyper-V-värdar.

Så kraftfull som nested virtualisering är i VMware vSphere kan man förvänta sig att processen för att aktivera den är extremt svår. Det krävs dock bara ett par överväganden från din sida när du tillhandahåller en VMware vSphere VM som kommer att innehålla Hyper-V-installationen. Detta inkluderar att exponera flaggan för hårdvaruassisterad virtualisering på den virtuella CPU:n för Hyper-V VM och även att implementera promiscuous mode eller MAC Learning för att ansluta eventuella inbäddade Hyper-V VM:er till nätverket.

Samt sett är nested Hyper-V VMs på en VMware ESXi-server en extremt kraftfull funktion som gör att du kan testa och lära dig Hyper-V utan fysisk utrustning för att köra Hyper-V hypervisor.

Följ våra Twitter- och Facebook-flöden för nya versioner, uppdateringar, insiktsfulla inlägg och mycket mer.