Virtuele hypervisors

Bare metal virtualisatieplatforms zoals ESX, Hyper-V of Xen heten hypervisors. Het zijn gestripte besturingssystemen met een eigen kernel. Hun hoofddoel is het aanleveren van een omgeving waarin standaard besturingssystemen kunnen opereren en opstarten. De vraag is dan of een hypervisor ook zichzelf kan virtualiseren.

Nested hypervisors?
Meestal kunnen hypervisors zichzelf virtualiseren. Maar er zijn theoretische en concrete vereisten. Eerst even de theoretische achtergrond: het grootste struikelblok is de processor. Een 32-bits-besturingssysteem (OS) is relatief simpel te virtualiseren, de x86-code onderscheppen (binary translation/emulation), aanpassen en verwerken.

Maar voor 64-bitssystemen ligt dat anders. Deze vragen een veel nauwere samenwerking met de CPU. Meer zelfs: 64-bitsystemen vereisen aangepaste processors. Indien de besturingssystemen native draaien is er uiteraard minstens een 64-bitprocessor nodig. Indien men een virtueel OS wil draaien heeft men niet enkel een 64-bit-CPU nodig, maar tevens de CPU Hardware Virtualisatie-uitbreiding in de vorm van Intel VT-x of AMD-V. Deze kan door geen enkele commerciële hypervisor ‘doorgegeven’ of geëmuleerd worden voor een VM.

Theoretisch betekent dit dat een hypervisor virtueel kan geïnstalleerd worden indien deze niet als hoofdvereiste hardwarevirtualisatie-extensies heeft. Dit sluit meteen Microsoft Hyper-V uit om virtueel te draaien.

Concreet voorbeeld: vESX
Tot zover de theorie. In de praktijk zijn er toch nog enkele haken en ogen aan. Even het stappenplan schetsen om een virtuele ESX-server aan te maken. We spreken van pESX (physical ESX), vESX (virtual ESX) en zelfs vVM (virtual VM). Deze laatste (vVM) is uiteraard altijd een 32-bit-OS.

ESX & ESXi zijn perfect door elkaar te gebruiken, dus een fysieke ESXi met een virtuele ESX of vice versa is geen probleem. Op de pESX maak je een nieuwe VM aan met minstens 2 GB geheugen en als Guest OS kies je Linux Other (64-bit). Voor de rest laten we alles standaard (E1000, LSI Logic Parallel).

De vESX zal perfect netwerkverbinding hebben, maar om de vVM’s toegang te geven tot het netwerk is het nodig om promiscuous mode aan te zetten op de vSwitch van de pESX. Doe dit ook indien de vESX toegang nodig heeft tot een SAN-netwerk (via een vSwitch of dvSwitch).

Een tweede belangrijke aanpassing die specifiek nodig is om zonder foutboodschap (Unable to boot VM inside VM) vVM’s te starten is een toevoeging in de opties van de vESX-VM zelf: vESX uitschakelen, dan Edit Settings van de VM, binnen Options selecteer dan General en klik op Add Row. Typ als Name monitor_control.restrict_backdoor en voer dan als Value TRUE in.

De vESX zal nu perfect werken. Nog één kleine tip: we kunnen deze vESX-VM’s ook gewoon klonen. En zoals we gewend zijn van ESX zal het MAC-adres van deze VM’s telkens aangepast worden. Maar spijtig genoeg is dit niet volledig correct bij vESX-machines. ESX heeft namelijk altijd nog een virtueel MAC-adres voor zijn Service Console Port Groups en eventuele VMkernel Port Groups.

Deze worden bij het klonen niet gewijzigd, waardoor er bij het opstarten van bijvoorbeeld vijf gekloonde vESX VM’s er vijf gelijke MAC-adressen op het netwerk komen. Dit verzadigt het netwerk dusdanig dat communicatie bijna onmogelijk wordt.

De lastige oplossing is om in het bestand /etc/vmware/esx.conf deze MAC-adressen op te sporen en aan te passen (en te rebooten). Bij ESXi is het simpeler om in de lokale console gewoon Reset System Configuration te kiezen en tevens te herstarten. Alle settings zijn dan wel opnieuw ingesteld, maar de vVM’s zijn niet verloren.

Waarom?
Allereerst: een mechanisme als dit wordt niet ondersteund voor productiedoeleinden en zelfs ten strengste afgeraden. Bovendien krijgt de performantie een flinke knauw: de vertragingen die er zijn als we overgaan van een native naar een virtuele omgeving (jawel, er is nog steeds een overhead), worden soms zelfs meer dan vermenigvuldigd.

Toch zijn er ook voordelen, en dan meer bepaald in R&D-omgevingen: op slechts één server een HA-oplossing uitproberen, een virtuele SAN-software installeren voor de virtuele hypervisors, het is zelfs mogelijk een Live Migration (vMotion) uit te voeren van een virtuele naar een native hypervisor. vMotion zal uiteraard niet werken bij 64bit VM’s, maar een Cold Migration of een kloon maken wel. Op die manier is het zelfs mogelijk om een soort P2V (physical-to-virtual) van een heel datacenter te doen en dit volledig functioneel systeem te back-uppen.