Forskjellen på VMware og Xen

Det kom et godt spørsmål i forumet som jeg tenkte var verdt å besvare på forsiden: Hva er egentlig forskjellen på VMware og Xen? VMware er et kommersielt produkt som har eksistert i mange år og som nå har blitt gratis. Kort fortalt er jeg av den oppfatning at produsenten er klar over at teknologien deres snart vil være avleggs, og dette er et siste forsøk på å kapre kunder og vedlikeholdskontrakter. Fordi programvaren er relativt moden, og mange oppgaver i dag ikke trenger all den datakraften som er tilgjengelig, kan de lykkes med nettopp dette i flere år framover. Xen er relativt umoden teknologi, som Red Hat liker å påpeke, og XenSource har foreløpig ikke lansert et eneste ferdig produkt. Men det kommer neste uke.

På den tekniske siden bruker Xen noe som kalles paravirtualisering, mens VMware fungere mere som en emulator med dynamisk omskriving av minne. For å forklare forskjellen trenger man bittelitt bakgrunn i moderne operativsystemer, og jeg kommer bare til å gi litt forenklet fakta med Linux som eksempel.

• Linux kjernen (kernelen) er en supervisor.
• CPUen eksekverer enten i supervisor modus eller i "vanlig" modus. Kun i supervisor modus er det mulig å snakke direkte med maskinvare.
• Programmer kan ikke snakke direkte med maskinvare eller tildele seg selv minne, men må be supervisor om å gjøre det og gi dem resultatet. Slike forespørsler kalles "system calls" og håndteres spesielt av maskinvaren, ved at den automatisk bytter til å eksekvere supervisoren.
• Å kjøre flere programmer samtidig betyr egentlig å kjøre ett og ett program av gangen, med supervisor mellom hvert bytte.

Utfordringen er at når man kjører et operativsystem så forventer det å kunne snakke med maskinvaren direkte, noe det ikke kan hvis det ble startet som et vanlig program, altså ikke som supervisor. Hvis man prøver på å gjøre dette fører det til en såkalt "exception", og maskinvaren vil automatisk kalle på supervisor som terminerer det aktuelle programmet for å sikre at maskinen ikke kræsjer.

Si at du ønsker å kjøre en vanlig versjon av Slackware på toppen av Debian. Begynnelsen av "programmet" Slackware vil være å laste Linux, som i tur og orden vil sette opp maskinvaren og tildele seg selv minne. Men her stopper det med en gang, for Slackware har ikke lov til å konfigurere eller tildele noe som helst i "vanlig" modus.

VMware
VMWare leser koden som skal lastes inn i minne på forhånd. Når den ser et sted der Slackware vil allokere minne så skriver den det om til en forespørsel til VMware koden om å etterspørre mere minne. VMware koden er tilpasset Debian og vet hvordan det skal spørre supervisor (Debian) om å få allokert mere minne. Tilsvarende, når VMware ser kode i Slackware som prøver å snakke direkte til PCI-busen, eksempelvis for å se hvilke nettverkskort som er tilgjengelige, blir dette skrevet om til en annen forespørsel til VMware sin kode. Siden dette gjøres før koden eksekveres lever Slackware i sin egen verden, og merker aldri at det ikke noensinne sender forespørsler til den egentlige maskinvaren. Ved å installere spesielle drivere i gjest-operativsystemet (Slackware) kan VMware i tillegg redusere behovet for slik omskriving.

Fordelen med VMware er at den ikke krever noen tilpasninger av Slackware, eller andre operativsystemer det skal kjøre. Programmet blir skrevet om etterhvert som det eksekveres. På grunn av abstraksjonsnivået er det heller ikke noe i veien for å flytte virtuelle maskiner mellom to fysiske PCer med forskjellig maskinvare. VMware fungerer som en vanlig applikasjon, som ikke bryr seg om hvordan nettverskort du har så lenge operativsystemet sier en nettverksforbindelse er til stede. Et lite unntak er 64 bits gjest-operativsystem, som krever at man har et 64 bits verts-operativsystem.

Ulempen i forhold til en vanlig emulator er at du ikke kan emulere en annen CPU, du kan f.eks. ikke kjøre kode skrevet for PowerPC på en x86 i VMware. VMware er mye raskere enn en slik emulator, men det å kontinuerlig skrive om minne krever også en del CPU tid. I tillegg er det kostbart at alle forespørsler går via koden til VMware før den når maskinvaren. Ytelsestap på mellom 10 og 50 % er ikke uvanlig, men kan ofte aksepteres fordi få maskiner bruker mer enn 5% av den tilgjengelige kraften over tid.

Xen
Xen har en annen tilnærming til den nevnte problemstillingen. Ideen er at man skal gi de forskjellige operativsystemene så direkte tilgang til maskinvaren som mulig for å minimalisere ytelsestap. Samtidig er sikkerhet viktig, to virtuelle maskiner skal ikke kunne ødelegge for hverandre. Dette fører til at man fortsatt må ha en øverste supervisor, også kalt en hypervisor. Det operativsystemet som startes først, og som kjører Xen, er nettopp dette.

Hvis man kjører Xen på vanlig maskinvare i dag så må man bruke spesialtilpassede versjoner av gjest-operativsystemene. I det eksempelet jeg brukte for VMware betyr det at Debian må bruke en versjon av Linux som har støtte for Xen, og Slackware må bruke en versjon av Linux som ber om Xen sin oppmerksomhet der det ellers ville ha forespurt maskinvaren direkte. Siden det ikke finnes noen tilpasset versjon av Windows, eller mange andre operativsystemer, er det derfor per i dag ikke mulig å kjøre disse under Xen.

Dette vil forandre seg når Intel og AMD lanserer prosessorer med maskinvare som støtter virtualisering, som ventes å skje relativt snart. Det kan forøvrig allerede være bygget inn i enkelte modeller som er på markedet i dag, uten at dette har blitt dokumentert. Man må huske at produsentene er godt tjent med at bedrifter kjøper en dedikert maskin til hvert formål.

Når prosessoren støtter virtualisering vil det finnes flere modus enn i dag. Jeg er ikke oppdatert på terminologien på dette området, men trikset er at man introduserer en falsk supervisor modus. Denne vil, for eksempel, la Slackware snakke med maskinvaren direkte når dette er mulig, og be Xen om hjelp når det kreves. Fordelen med dette er at det er transparent for Slackware, som tror at den kjører på ekte maskinvare. Dette fører også til at man kan bruke operativsystemer som ikke har blitt tilpasset, eksempelvis Windows.

Den store bonusen, i forhold til VMware og emulatorer, er at mesteparten av maskinvaren brukes direkte. Dette gir tilnærmet lik ytelse som om man kjørte systemet direkte på maskinvaren, uten virtualisering. Flere tester har vist svært god responstid og at ytelsen sjelden blir redusert med mer enn 5%.

En ulempe er at man igjen blir maskinvareavhengig, så hvis man skal overføre den virtuelle maskinen til en annen datamaskin så vil denne måtte ha de samme komponentene. Til gjengjeld har XenSource utviklet en del kjekke funksjoner. Blandt annet er det mulig å flytte et helt operativsystem som noen spiller Quake 4 på fra en fysisk maskin til en annen, over gigabit ethernet, uten at spilleren merker noe som helst. Systemet bruker en inkrementell strategi som gjør at mesteparten av systemet flyttes på forhånd, og at kun akkurat den delen av minnet som eksekveres må flyttes i siste liten.

Dette høres kanskje litt unødvendig ut, men hvis man kjører forretningskritiske applikasjoner kan det være uaktuelt å stoppe hele operativsystemet for å flytte det, slik man må på VMware.

Med andre ord har VMware per i dag en rekke fordeler på de fleste bruksområder, men disse vil fort forsvinne ettersom Xen får mere fartstid og maskinvaren får støtte for virtualisering.