NO340567B1 - Hierarkisk virtualisering med en flernivå virtualiseringsmekanisme - Google Patents

Description

TEKNISK FELT

Den foreliggende beskrivelsen angår feltet datamaskiner. Mer spesifikt angår den virtualisering av datamaskiner.

BAKGRUNN

Begrepet virtualisering innebærer virtualisering av maskinvare i datamaskiner slik at flere operativsystemer kan kjøre i hver sin separate partisjon på en enkelt fysisk datamaskin. Programvare for virtualisering abstraherer maskinvaren på ulike måter slik at ulike operativsystemer vekselvirker med programvaren, og programvaren i sin tur vekselvirker med maskinvaren.

De fleste virtualiseringssystemer inneholder en enkelt Virtuell-Maskin-Monitor (VMM) programvare. I noen sammenhenger kalles denne VMM-programvaren en "hypervisor". En hypervisor er laget for å kjøre direkte på maskinvare. Som sådan er den øverste myndighet for hvordan maskinvaren benyttes. Av denne grunn er det generelt slik at det kun kan finnes én hypervisor på en maskin (på ett stykke maskinvare). En hypervisor tillater flere "gjeste" operativsystemer (OSer), eller "gjester" for enkelhets skyld, å kjøre samtidig på ett system.

En VMM eller hypervisor kan utformes med visse mål for øye. Ingeniører må avveie sikkerhet, kompleksitet, ytelse og så videre. Noen VMMer og hypervisorer tillater vekselvirke med gjestene gjennom et programvaregrensesnitt. Som med ethvert grensesnitt blir versjonering viktig. En gjest skrevet for en versjon av en hypervisor kan være inkompatibel med en annen versjon av hypervisoren.

Det er således situasjoner hvor det ville være nyttig å kjøre flere kopier av en hypervisor på en enkelt maskin. En versjon kunne for eksempel være ekstremt enkel og tilby høye sikkerhetsgarantier, og en annen versjon kunne tilby mer komplekse og intrikate egenskaper. Slike multiple versjoner kunne kjøre ved siden av hverandre.

Dette er uheldigvis ikke mulig med dagens løsninger fordi det kan være kun én hypervisor på maskinen. En tradisjonell tilnærming til dette problemet er å bruke rekursiv virtualisering, hvorved hypervisorer "nøstes". En enkelt "virkelig" hypervisor sitter på bunnen, og en eller flere andrenivå-hypervisorer kjører over denne. En ulempe med dette arrangementet er dårlig ytelse. Fordi hypervisorene på andre nivå ble skrevet med forutsetning om direkte tilgang til maskinvare, vil de ikke yte så bra. Kort sagt avtar ytelsen til det totale virtualiserte systemet geometrisk med hvert ytterligere nivå av nøstede hypervisorer.

I tillegg tilbyr mange prosessorer maskinvaresupport for ett virtualiseringsnivå, men de støtter sjelden mer enn ett. Således blir det, sett fra et maskinvareperspektiv, vanskelig å implementere flere hypervisorer på en enkelt fysisk maskin. Således ville det være fordelaktig å frembringe mekanismer for å kjøre virtualiseringsprogramvare direkte på maskinvare slik at flere versjoner av programvaren kjører direkte på maskinvaren samtidig.

US 2003/0037089 A1 beskriver en primær virtuell-maskin-monitor i et rekursivt virtualiseringssystem som kan bruke fordelingsinformasjon for å fordele en datter-eller sekundær virtualiseringsmonitor som styrer flere virtuelle maskiner. I det rekursive virtualiseringsmiljø, vil en datter- eller sekundær virtuell-maskin-monitor operere på et ikke-privilegert nivå for å fordele virtuelle maskiner i en virtuell maskin.

SAMMENFATNING

Hovedtrekkene ved den foreliggende oppfinnelse fremgår av de selvstendige krav. Ytterligere trekk ved oppfinnelsen er angitt i de uselvstendige krav.

Gjenstanden beskrevet i den foreliggende søknaden angår hierarkisk virtualisering med en flernivå virtualiseringsmekanisme. I ett eksempel benyttes en fremgangsmåte for å frembringe slik virtualisering hvor en første partisjon vedlikeholdes med en hypervisor. En første virtualiseringsstakk innen den første partisjonen vekselvirker med en andre partisjon, for eksempel ved å opprette en andre partisjon og allokere dens ressurser. Hypervisoren it slikt hierarkisk arrangement av partisjoner, hvor en virtualiseringsstakk i en partisjon styrer en annen partisjon, kjenner faktisk til hver partisjon og kan kommunisere direkte med hver partisjon. Fordi hypervisoren kan kommunisere med hver partisjon, kan den også holde oversikt over enhver ressurs innen enhver gitt partisjon.

Videre kan den andre partisjonen legge til det hierarkiske forholdet mellom partisjonene ved å opprette en tredje partisjon ved å benytte sin egen andre virtualiseringsstakk. I tillegg kan en tredje virtualiseringsstakk i den første partisjonen eksistere ved siden av den første virtualiseringsstakken. Denne tredje virtualiseringsstakken kan opprette en fjerde partisjon som er uavhengig av de ovennevnte første, andre og tredje partisjonene. Alternativt kan den første virtualiseringsstakken opprette den fjerde partisjonen siden en virtualiseringsstakk kan opprette og styre mer enn en partisjon til enhver tid.

I et annet eksempel i beskrivelsen diskuteres sikkerheten i den hirerarkiske virtualiseringen. Således tilveiebringes en morpartisjon, og denne morpartisjonen har en virtualiseringsstakk. En datterpartisjon opprettes av virtualiseringsstakken i morpartisjonen, men datterpartisjonen styres ikke fullstendig av morpartisjonen fordi den har minst en ressurs (eller en del av en ressurs) under sin eksklusive kontroll. Av sikkerhetsgrunner kan det forekomme at en datterpartisjon ikke kan stole på sin morpartisjon. Hvis det er tilfellet, kan visse ressurser i datteren ikke nås av moren. For å implementere denne frikoblingen av datteren fra morpartisjonen, ber datterpartisjonen morpartisjonen om å få eksklusiv kontroll over ressurser og andre objekter, og hypervisoren, som øverste myndighet i dette virtualiserte miljøet, sikrer at morpartisjonen følger datterpartisjonens forespørsler.

Denne sammenfatningen er tatt med for å innføre enkelte konsepter i forenklet form. Disse er ytterligere beskrevet i den detaljerte beskrivelsen nedenfor. Denne sammenfatningen er ikke ment å identifisere nøkkeltrekk eller essensielle trekk ved søknadsgjenstanden i følge kravene. Den er heller ikke ment som et hjelpemiddel for å bestemme omfanget av oppfinnelsen i følge kravene.

KORT BESKRIVELSE AV FIGURENE

Den foregående sammenfatningen så vel som den etterfølgende detaljerte beskrivelsen forstås bedre når de leses sammen med de vedføyde figurene. For å illustrere den foreliggende søknadsgjenstanden, vises ulike aspekter ved den. Følgende figurer er vedlagt: Figur 1 er et blokkdiagram som representerer den logiske lagdelingen i maskinvare-og programvarearkitekturen for et virtualisert operativmiljø i et datamaskinsystem. Figur 2A er et blokkdiagram som representerer et virtualisert databehandlingssystem hvor virtualiseringen utføres av et vertsoperativsystem (enten direkte eller via en hypervisor). Figur 2B er et blokkdiagram som representerer et alternativt virtualisert databehandlingssystem hvor virtualiseringen utføres av en virtuell-maskin-monitor som kjører ved siden av et vertsoperativsystem. Figur 3 illustrerer en type virtualisering med nøstede hypervisorer og partisjoner. Figur 4A illustrerer hierarkisk virtualisering med en flernivå virtualiseringsmekanisme som gjør behovet for nøstede hypervisorer overflødig. Figur 4B gir en oversikt over hvordan hypervisorens mikrokjerne og virtualiseringsstakken passer inn i et eksempel på implementasjon. Figur 4C illustrerer et scenario hvor en datterpartisjon ber en morpartisjon om eksklusiv kontroll over sine egne ressurser. Figur 5 illustrerer poenget at flere virtualiseringsstakker kan være inneholdt i en partisjon. Figur 6 illustrerer arrangementet av virtualiseringsstakker og deres tilhørende partisjoner i et hierarkisk oppsett. Figur 7 illustrerer forholdet mellom en hypervisors mikrokjerne og en virtualiseringsstakk som bringer til veie virtualiseringstjenester for hierarkisk virtualisering, og Figur 8 viser de ulike komponentene som utgjør virtualiseringsstakken og deres forhold til hverandre.

DETALJERT BESKRIVELSE

Oversikt

Beskrivelsen nedenfor starter med en generell og kort drøfting av virtuelle maskiner. Deretter skiftes fokus til en drøfting av hierarkisk virtualisering med en flernivå virtualiseringsmekanisme. Her drøftes relevante aspekter ved hierarkisk virtualisering hvor en partisjon, som inneholder en virtualiseringsstakk og vedlikeholdes av en hypervisor, kan opprette og styre en annen partisjon, eller alternativt kan ha flere enn en virtualiseringsstakker som kan opprette og styre ytterligere partisjoner. I begge tilfeller kan hypervisoren kommunisere direkte med hver partisjon i hierarkiet fordi den kjenner til hver partisjon fra starten av. Til sist drøftes mekanismen som muliggjør hierarkisk virtualisering del for del ved først å dele den opp i en hypervisor mikrokjerne og en virtualiseringsstakk. Hvert av elementene og hver av komponentene i disse to delene drøftes deretter mer detaljert.

Virtuelle maskiner

Figur 1 er et diagram som representerer den logiske lagdelingen i maskinvare- og programvarearkitekturen for et virtualisert operativmiljø i et datamaskinsystem. I figuren kjører et virtualiseringsprogram 110 direkte eller indirekte på den fysiske maskinvarearkitekturen 112. Virtualiseringsprogrammet 110 kan være en virtuell-maskin-monitor som kjører ved siden av et vertsoperativsystem eller et vertsoperativsystem med en hypervisorkomponent hvor hypervisorkomponenten utfører virtualiseringen. Virtualiseringsprogrammet 110 virtualiserer en gjestemaskinvarearkitektur 108 (vist med stiplede linjer for å illustrere at denne komponenten er en partisjon eller en "virtuell maskin"), dvs maskinvare som ikke faktisk eksisterer, men i stedet er virtualisert av virtualiseringsprogrammet 110. Et gjesteoperativsystem 106 kjører på gjestemaskinvarearkitekturen 108, og en programvareapplikasjon 104 kjører på gjesteoperativsystemet 106. I det virtualiserte operativmiljøet på Fig 1 kan programvareapplikasjonen 104 kjøre i et databehandlingssystem 102 selv om programvareapplikasjonen 104 er laget for å kjøres på et operativsystem som er generelt inkompatibelt med et vertsoperativsystem og maskinvarearkitekturen 112. Figur 2A illustrerer et virtualisert databehandlingssystem som omfatter et vertsoperativsystem (verts-OS) programvarelag 204 som kjører direkte over en fysisk datamaskins maskinvare 202, hvor verts-OS 204 gir tilgang til ressursene i den fysiske datamaskinens maskinvare 202 ved å tilby grensesnitt til partisjonene A 208 og B 210 som kan brukes av operativsystemene 212 og 214 henholdsvis. Dette gjør det mulig å skjule verts-OS 204 for operativsystem lagene 212 og 214 som kjører over det. Igjen, for å utføre virtualiseringen, kan verts-OS 204 være et spesiallaget operativsystem med innebygde virtualiseringsfunksjoner eller alternativt et standard operativsystem med en inkorporert hypervisorkomponent som utfører virtualiseringen (ikke vist).

Vi viser igjen til Fig. 2A, hvor det over verts-OS 204 er to partisjoner. Partisjon A 208 kan for eksempel være en virtualisert Intel 386 prosessor. Og partisjon B 210 kan for eksempel være en virtualisert versjon av en av prosessorne i Motorolas 680X0 familie. Innen hver partisjon 208 og 210 kjører gjesteoperativsystemer (gjeste-OSer), henholdsvis A 212 og B 214. På gjeste-OS A 212 kjører to applikasjoner, applikasjon A1 216 og applikasjon A2 218, og på gjeste-OS B 214 kjører applikasjon B1 220.

I forbindelse med Fig. 2A er det viktig å merke seg at partisjon A 208 og partisjon B 210 (som er vist med stiplede linjer) er virtualiserte representasjoner av datamaskinvare som kun eksisterer som programvarekonstruksjoner. De er muliggjort av at det eksekveres spesialisert virtualiseringsprogramvare som ikke bare presenterer partisjon A 208 og partisjon B 210 til henholdsvis gjeste-OS A 212 og gjeste-OS B 214, men som også utfører alle programvarestegene som trengs for at gjeste-OS A 212 og gjeste-OS B 214 skal kunne vekselvirke indirekte med den virkelige fysiske datamaskinens maskinvare 202.

Figur 2B illustrerer et alternativt virtualisert databehandlingssystem hvor virtualiseringen utføres av en virtuell-maskin-monitor (VMM) 204' som kjører ved siden av vertsoperativsystemet 204". I visse tilfeller kan VMM 204' være en applikasjon som kjører på vertsoperativsystemet 204" og som vekselvirker med datamaskinens maskinvare 202 kun gjennom vertsoperativsystemet 204". I andre tilfeller, som vist i Fig. 2B, kan VMM 204' i stedet utgjøre et delvis uavhengig programvaresystem som på noen nivåer vekselvirker indirekte med datamaskinens maskinvare 202 gjennom vertsoperativsystemet 204", mens VMM 204' på andre nivåer vekselvirker direkte med datamaskinens maskinvare 202 (på samme måte som vertsoperativsystemet vekselvirker direkte med datamaskinens maskinvare). I ytterligere andre tilfeller kan VMM 204' utgjøre et fullstendig uavhengig programvaresystem som på alle nivåer vekselvirker direkte med datamaskinens maskinvare 202 (på samme måte som vertsoperativsystemet vekselvirker direkte med datamaskinens maskinvare) uten å benytte vertsoperativsystemet 204" (selv om den fortsatt vekselvirker med vertsoperativsystemet 204" for å koordinere bruk av datamaskinens maskinvare 202, unngå konflikter og lignende).

Alle disse variasjonene for å implementere de ovennevnte partisjonene er kun eksempler på implementasjoner, og ingen ting i dette skal tolkes som en begrensning av oppfinnelsen til en bestemt utførelsesform.

Hierarkisk virtualisering med en flernivå virtuell- maskin- monitor ( VMM)

Hierarkisk virtualisering kan oppnås med en flernivå virtualiseringsmekanisme i form av en virtuell-maskin-monitor (VMM) eller en hypervisor. For eksempel kan funksjonaliteten som tradisjonelt tilbys av en monolittisk hypervisor splittes i en mikrokjerne som kjører direkte på maskinvare og en virtualiseringsstakk som opererer innen en partisjon. Denne formen for flernivåarkitektur muliggjør hierarkisk virtualisering ved at en virtualiseringsstakk innen en partisjon kan opprette og styre (eller "vedlikeholde" for korthets skyld) andre partisjoner. Disse partisjonene kan i sin tur inneholde andre virtualiseringsstakker som kan vedlikeholde ytterligere partisjoner. Det er viktig å merke seg at denne typen arkitektur er forskjellig fra en typisk "nøstet" rekursiv virtualisering, og forbedrer ytelsen av denne.

Figur 3 illustrerer, som kontrast til hierarkisk virtualisering med en flernivå virtualiseringsmekanisme, rekursiv virtualisering. I rekursiv virtualisering er hypervisorene "nøstet". En enkelt "virkelig" hypervisor sitter på bunnen, og en eller flere andre-nivå hypervisorer kjører oppå denne. For eksempel viser Fig. 3 en "virkelig" hypervisor A 301 som kjører på en maskins maskinvare 300. Hypervisorer B 302 og C 308 er nøstet inne i gjestepartisjoner B 314 og C 316, og gjestepartisjonene B 314 og C 316 vedlikeholdes av den "virkelige" hypervisoren A 301.

De nøstede hypervisorene B 302 og C 308 kan hver for seg vedlikeholde sine egne gjestepartisjoner. For eksempel vedlikeholder hypervisor B 302 en gjestepartisjon B.1 304 og gjestepartisjon B.2 306. Tilsvarende vedlikeholder hypervisor C 308 en gjestepartisjon C.1 310 og gjestepartisjon C.2 312. Selv om det ikke er vist i Fig. 3 er det klart for fagfolk på området at gjestepartisjonene B.1 304, B.2 306, C.1 310 og C.2 312 inne i gjestepartisjonene B 314 og C 316 kan være verter for ytterligere nøstede hypervisorer. Disse ytterligere nøstede hypervisorene kan vedlikeholde ytterligere nøstede partisjoner, og så videre.

Dette rekursive arrangementet har imidlertid ulemper med svak ytelse. Fordi hypervisorene på andre (og høyere) nivå er skrevet under forutsetning av at de har direkte tilgang til maskinvare, vil de ikke yte godt. I tillegg tilbyr mange prosessorer maskinvarestøtte for ett nivå av virtualisering, men de tilbyr sjelden støtte for flere enn ett. Endelig, i et slikt nøstet oppsett er ingen hypervisor kjent med alle partisjoner, og kan heller ikke kommunisere direkte (f eks via hyperkall) med alle partisjoner. Hvis for eksempel hypervisor A 301 vil kommunisere med gjest B.1 304, må kommunikasjonen gå gjennom hypervisor B 302, hvilket er svært ineffektivt.

I motsetning til Fig. 3 viser figurene 4A og 4B hierarkisk virtualisering med en flernivå virtualiseringsmekanisme som overflødiggjør behovet for å bruke nøstede hypervisorer. Således forestiller Fig. 4A en hypervisor med splittet funksjonalitet (som virker på flere nivå) ved siden av en tradisjonell hypervisor. På venstre side av Fig. 4A vises et tradisjonelt hypervisoroppsett. På høyre side er oppsettet beskrevet i følge oppfinnelsen, hvor en hypervisor er delt i en virtualiseringsstakk 402 og en mikrokjernedel 400.

Mikrokjernen 400 er svært liten og enkel, og den vekselvirker med maskinvaren 403. Den tilbyr kun de mest grunnleggende tjenestene som trengs for å partisjonere en maskins ressurser. De mer komplekse delene av hypervisor 401 er "skjøvet ut" til en eller annen valgt gjestepartisjon 405 i form av en virtualiseringsstakk 402. Virtualiseringsstakken 402 tar seg av funksjoner som virtualisering av maskinvareenheter, minnehåndtering, oppretting av partisjoner, konfigurasjon og så videre.

Fig. 4B gir en oversikt over hvordan hypervisorens mikrokjernedel og virtualiseringsstakk forholder seg til hverandre i et typisk virtualiseringsmiljø. I en utførelsesform av den foreliggende oppfinnelse sitter hypervisorens mikrokjerne 400 således direkte på den fysiske maskinvaren 403, og virtualiseringsstakk 1 402, som tilhører hypervisorens mikrokjerne 400, er skjøvet ut til en morpartisjon 404. Virtualiseringsstakken 402 er i sin tur i stand til å vedlikeholde sine egne partisjoner. I

Fig. 4B vedlikeholder virtualiseringsstakken 402 en datterpartisjon A 406 og en datterpartisjon B 408.

Fra et sikkerhetssynspunkt er det interessant at datterpartisjoner faktisk kan mangle tillit til sine morpartisjoner, selv om morpartisjoner vanligvis styrer datterpartisjoner. Fordi en morpartisjon som standard har kontroll over en datterpartisjon, kan den vedlikeholde ressursene inne i en datterpartisjon. Hvis skadevoldende programvare noen gang infiltrerte en morpartisjon, ville datterpartisjonen være utsatt for den skadevoldende programvaren. Av denne grunn beskrives en annen utførelsesform hvor en datterpartisjon kan be sin morpartisjon om å bli frigjort eller frikoblet fra morpartisjonens kontroll. En slik frikobling etterfølges av at morpartisjonen oppgir sin kontroll over datterpartisjonens ressurser (så som minnesider) og medfører at morpartisjonen avinstallerer sine overvåkingsrutiner (som kan forsyne morpartisjonen med informasjon vedrørende innholdet i datterpartisjonen).

Fig. 4C viser således et tilfelle der en datterpartisjon A 406 ber 410 en morpartisjon 404 om å bli frikoblet. En dertil egnet komponent i virtualiseringsstakken behandler denne forespørselen. Det som typisk kan skje er at forespørselen foretas av et operativsystem (dvs kjernen i OSet) i datterpartisjonen A 406 eller i en form for driver i datterpartisjonen A 406. Denne forespørselen rettes så til en bootlaster i morpartisjonen 404. Bootlasteren kan være en opplyst bootlaster (dvs en bootlaster som kjenner til virtualisering). På denne måten kan morpartisjonen 404 forhindre enhver tukling med datterpartisjonen 406, siden datterpartisjonen A 406 ikke kan hackes gjennom morpartisjonen 404 så snart den er frikoblet.

Det er hypervisor 400 som faktisk håndhever (412) reglene for forespørselen, siden den er øverste myndighet i ethvert virtualisert system. I Fig 4C er for eksempel en del av minnet i datterpartisjonen A 406 utilgjengelig for 414 for morpartisjonen 404. Således mangler morpartisjonen 404 tilgang til ressurser i datterpartisjonen A 406. Morpartisjonen 404 kan likevel ha tilgang til andre deler av datterpartisjonen A 406. På tilsvarende måte er datterpartisjonen B 408 utilgjengelig 414 for morpartisjonen 404. Morpartisjonen 404 er derfor overhode ikke klarert, slik at datterpartisjonen B 408 blir svært sikker. Dette betyr at morpartisjonen 404 ikke kan vite noe om datterpartisjonen B 408. Interessant nok bemerkes at i visse utførelsesformer av oppfinnelsen kan morpartisjonen 404 i egenskap av morpartisjon 404 terminere datterpartisjonen B 408 hvis datterpartisjonen oppfører seg på en ikke tillatt eller uventet måte, til tross for at morpartisjonen 404 har begrenset (eller ingen) kontroll over en fullt frikoblet partisjon, så som partisjon B 408.

I en ytterligere utførelsesform av den foreliggende oppfinnelsen viser Fig. 5 at flere virtualiseringsstakker kan befinne seg i en partisjon. For eksempel kan en første virtualiseringsstakk 1 502 befinne seg i en morpartisjon 508 sammen med en andre virtualiseringsstakk 2 503. Den første virtualiseringsstakken 1 502 er i stand til å vedlikeholde flere datterpartisjoner (i forhold til morpartisjonen den befinner seg i). Således vedlikeholder virtualiseringsstakk 1 502 datterpartisjon 1A 504 og datterpartisjon 1B 506. På samme måte vedlikeholder virtualiseringsstakk 2 503 datterpartisjon 2A 505 og datterpartisjon 2B 507. Selv om kun to virtualiseringsstakker er vist, kan et vilkårlig antall virtualiseringsstakker befinne seg i en gitt partisjon, og hver av disse virtualiseringsstakkene kan vedlikeholde et vilkårlig antall datterpartisjoner.

En grunn til å ha flere virtualiseringsstakker samtidig i en partisjon, er for eksempel at en virtualiseringsstakk 502 kunne være innrettet mot å støtte strippede sikre partisjoner, mens en annen virtualiseringsstakk 503 kunne være innrettet mot å tilby full støtte for alle typer ressurser. Selvsagt ville den førstnevnte virtualiseringsstakken 502 være en god del sikrere (og følgelig også dens partisjoner) fordi den ville være proporsjonalt mindre kompleks enn den sistnevnte virtualiseringsstakken 503. Sikkerhet og kompleksitet ville måtte avveies mot hverandre i denne sammenhengen. Således kunne, for eksempel, den sistnevnte virtualiseringsstakken 503 tilby støtte for IDE (Integrated Device Electronics) og SCSI (Small Computer System Interface), mens den førstnevnte versjonen 502 ikke ville tilby slik støtte.

I enda en ytterligere utførelsesform, som er vist i Fig. 6, kan de ovennevnte virtualiseringsstakkene og deres tilhørende partisjoner ordnes på en hierarkisk måte. Således vedlikeholder en hypervisors mikrokjerne 600 en morpartisjon 608. og virtualiseringsstakk 1 602 som tilhører hypervisorens mikrokjerne 600 befinner seg i morpartisjonen 608. Virtualiseringsstakk 1 602 vedlikeholder en første datterpartisjon 1A 604 og en andre datterpartisjon 1B 606.En andre virtualiseringsstakk 2 610 vedlikeholder to ytterligere datterpartisjoner (eller datterdøtre av den opprinnelige partisjonen 608): datterpartisjon 2A 605 og datterpartisjon 2B 607.

Selv om det ikke er vist i Fig. 6, skal det forstås at hver av datterpatrisjonene 605 og 607 som vedlikeholdes av den andre virtualiseringsstakken 2 610 i sin tur kunne vedlikeholdt en eller flere tertiære virtualiseringsstakker, og disse stakkene kunne i sin tur vedlikeholde ytterligere datterpatrisjoner. Kort sagt forsøker Fig. 6 å illustrere at arkitekturen med hypervisorens mikrokjerne og virtualiseringsstakk muliggjør hierarkisk virtualisering. Partisjoner kan inneholde flere virtualiseringsstakker, og slike virtualiseringsstakker kan vedlikeholde flerte partisjoner, som i sin tur kan vedlikeholde ytterligere virtualiseringsstakker og så videre.

En fordel med denne typen hierarkisk orden er at den støtter flernivå administrasjon av store maskiner. For eksempel kan en "maskinadministrator" styre virtualiseringsstakken i en "rotpartisjon" (dvs den øverste morpartisjonen). Denne administratoren kan så opprette underpartisjoner som har egne virtualiseringspartisjoner, og tilordne hver av dem et sett maskinressurser (minne, prosessorer, nettverkskort, disker og så videre). Denne administratoren kan så la andre administratorer (for eksempel administratorer på team-nivå) partisjonere ressursene de ble tildelt ytterligere. I et slikt tilfelle er virtualiseringsstakken på nivå to begrenset til å benytte ressursene som ble tildelt av virtualiseringsstakken på første nive, dvs på rotnivå, men de tildelte ressursene kan brukes på passende måte etter ønske og behov. Et styringssystem for virtuelle maskiner som kjenner til hierarkiet kan presentere hierarkiet som sådan, og tillate en administrator på hvert nivå å reallokere ressurser mellom partisjonene de (han/hun) kontrollerer.

Denne typen hierarkisk scenario bør skilles fra den nøstede tilfellet som ble drøftet med i referanse til Fig. 3. Ulikt det nøstede tilfellet som har flere hypervisorer som kjører i nøstede partisjoner, og hvor hver hypervisor ikke er kjent med basepartisjoner (underliggende) eller avledete partisjoner (overliggende), er det i det hierarkiske tilfellet en enkelt hypervisor som kjenner til alle partisjonene. I dette tilfellet muliggjør flere virtualiseringsstakker at det opprettes ulike hierarkiske forhold mellom partisjonene. Det er interessant å merke seg at den foreliggende hypervisoren kan kommunisere direkte med enhver annen partisjon, selv når slike partisjoner vedlikeholdes i et hierarkisk forhold til hverandre av de ulike tilhørende virtualiseringsstakkene. Dette er i motsetning til tidligere kjent teknikk, og betyr at behovet for å gå gjennom en eller flere andre hypervisorer eller virtualiseringsprogramvare blir overflødig. En slik direkte kommunikasjon kan oppnås gjennom direkte hyperkall fra hypervisoren til enhver gitt partisjon.

Hypervisor med mikrokjerne og virtualiseringstjenester

Som nevnt over, støttes hierarkisk virtualisering av arkitekturen med hypervisorens mikrokjerne og virtualiseringsstakk. Figur 7 fokuserer på hypervisorkomponentene, som omfatter hypervisorens mikrokjerne 702 og virtualiseringstjenester 704 i hypervisoren. (Figur 8 nedenfor fokuserer på arkitekturen i virtualiseringsstakken.)

Med henvisning til figur 7, er det nederste laget i mikrokjernen 702 et abstraksjonslag for maskinvare (hardware abstraction layer) 706, som har ansvaret for å abstrahere plattformspesifikke egenskaper for mikrokjernen 702. Andre moduler i dette laget og laget drøftet nedenfor kan benyttes, hvilket er velkjent for fagfolk på området. Disse lagene og modulene de inneholder er kun ment som eksempler, og presenteres her for drøftingens del. De skal ikke tolkes begrensende eller dispositivt på noen måte.

På toppen av dette laget er minnehåndteringslaget 710. Dette laget har en minnehåndteringsmodul som tilbyr primitiv intern minnehåndtering for hypervisor 700 og en ressurshåndteringsmodul som lagrer ressurspolitikkene for en gitt CPU og minnebruk. Komponenter på høyere nivå har ansvaret for å håndheve disse politikkene.

Endelig inneholder det tredje kjernelaget 712 minst fire eksempelmoduler:

For det første en sikkerhetsaksesshåndteringsmodul som styrer tilgangsrettigheter for partisjoner og ressurser som kan deles eller flyttes mellom partisjoner; for det andre en trådhåndterer som håndterer interne tråder i hypervisor 700; for det tredje en tidshåndterer som håndterer timerkøer og timerinterrupt, og for det fjerde en tidsfordeler (scheduler) som implementerer tidsfordeling i hypervisor 700.

Tilsvarende kan fire lag benyttes i virtualiseringstjenestene 704.

Det første laget er virtualiseringsabstraksjonslaget 714, som inneholder en virtualiseringsabstaksjonsmodul. Denne abstraherer virtualiseringsutvidelsene som tilbys av en prosessor.

Over dette ligger et partisjonslag 716 som inneholder minst tre av de følgende moduler: En partisjonshåndteringsmodul som håndterer partisjonsobjektene og tilhørende datastrukturer; en virtuell-prosessorhåndteringsmodul, som håndterer en eller flere virtuelle prosessorer assosiert med hver partisjon - i dette oppsettet har hver prosessor sin egen prosessortilstand og kjører på sin egen hypervisorstakk; og en syntetisk interruptkontroller som implementerer en interruptkontroller tilsvarende en x86 avansert programmerbar interruptkontroller.

Det neste laget vedrører adresserom met. Dette laget kan ha en adressehåndteringsmodul som håndterer definisjonen av en gjests fysiske adresserom og dets avbildning på underliggende fysiske minneressurser. Selvsagt kan andre moduler benyttes for å hjelpe til med å manipulere

adresseromsmekanismer, og dette er kun et eksempel på en modul.

Til sist inneholder virtualiseringstjenestene 704 fire moduler: Først behandler en fordelingshåndterer (dispatch manager) innkommende hendelser, og fordeler dem på passende måte; for det andre fordeler en hyperkallhåndteringsmodul hyperkall fra en gjest; for det tredje en avbrudsshåndteringsmodul som som håndterer fordeling og ruting av oppfangede hendelser (eng. intercepts), for eksempel aksesskall til modellspesifikke registre, eksekvering av visse instruksjoner og så videre; og for det fjerde en instruksjonskompletteringsmodul som håndterer sluttføring av visse instruksjoner under virtualisering.

Komponenter i virtualiseringsstakken

I en annen utførelsesform viser figur 8 de ulike komponentene som utgjør virtualiseringsstakken og deres forhold til hverandre. Beslektede komponenter som ikke beskrives her er beskrevet i en beslektet søknad kalt "Systems and methods for multi-level intercept processing in a virtual machine environment", serienummer 11/078 141, levert 11. mars 2005. Den "eksterne monitor" beskrevet i sistnevnte søknad er en delkomponent i den virtuelle stakken som drøftes i den foreliggende søknaden.

En gitt virtualiseringsstakk 800 kan implementeres i brukermodus 802 og kjernemodus 804. Videre kan kjernemodusen 804 ha komponenter så som et API og meldingshåndteringsbibliotek 806 for hypervisoren, og en infrastrukturdriver 810 for virtualisering. Bruker-modus 802 kan ha komponenter så som en virtuell maskintjeneste 812 og en arbeidsprosess 814 for den virtuelle maskinen.

Hver av disse komponentene kan ha en spesifikt definert oppgave. For eksempel eksponererer hypervisorens API-bibliotek 806 hypervisorens API til komponenter på høyere nivå, slik at disse kan kalle hypervisoren ved bruk av normale konvensjoner for operativsystem kal I. Dette biblioteket kan finnes i alle partisjoner som inneholder opplyst kode (dvs kode som kjenner til virtualisering) - enten de er vert for en virtualiseringsstakk eller ikke.

Videre tillater hypervisorens meldingshåndteringsbibliotek 806 kallende kode å registrere returkall på kjernenivå for meldinger som mottas fra hypervisoren eller fra andre partisjoner. Slike meldinger leveres som interrupter mellom partisjonene med meldingen som nyttelast. Dette grensesnittet gjør det mulig at en partisjon er vert for flere parallelle virtualiseringsstakker. For eksemepl kan en tredjepart implementere en virtualiseringsstyakk som befinner seg i samme morpartisjon som originalpartens virtualiseringsstakk. Eller flere versjoner av originalpartens virtualiseringsstakk kan kjøre side om side.

Så kommer Virtialiserings InfrastrukturDriveren (VID) 810, som innkapsler hoveddelen av virtualiseringsstakkens kjernemodusfunksjonalitet. Denne inneholder flere delkomponenter. For eksempel inneholder den virtualiseringsstakkens minnehåndtering (Virtualization Stack Memory Manager - VSMM). Denne komponentent har ansvaret for å håndtere en pool av systemets fysiske minnesider som "eies" av virtualiseringsstakken, og som brukes til å støtte gjestens fysiske minne i datterpartisjonene som håndteres av den aktuelle virtualiseringsstakken. Denne delkomponenten støtter overtildeling av minne og minneside-deling mellom partisjonene (for sider med identisk innhold). Den har også et sett av grensesnitt som gjør det mulig for brukermoduskomponenter å definere layout av en virtuell maskins fysiske adresserom (Guest Physical Address - GPA) og å plassere lese- og skriveoperasjoner på minnesideområder (f eks til bruk i snapshots eller varm migrering).

Videre inneholder VID 810 en modul for komplettering av komplekse instruksjoner (Complex Instruction Completion). Denne delkomponenten kan tilke komplekse instruksjoner som vedrører minne, og som ikke håndteres direkte av hypervisoren. Denne støtten kreves for visse tilfeller av enhetsemulering (f eks tilgang til planart VGA-minne, skriving til ROM eller tilgang til en emulert enhets minnemappede registre).

VID 810 inneholder også en prosessorintercepter. Denne delkomponenten gjør det mulig for brukermoduskomponenter å spesifisere virtuelle prosessorintercepts. For eksempel kan en emulert enhetsmodul ønske å motta en intercept-notifikasjon når et bestemt område av l/O-porter blir aksessert gjennnom en INN eller UT-instruksjon. Andre eksempler på prosessorintercepter omfatter: MSR-aksess, CPUID, unntak og HLT. Denne komponenten sporer de installerte interceptene og ruter intercept-notifikasjoner på passende måte.

Til sist kan VID 810 inneholde en delkomponent for å opprette og styre partisjoner (Partition Create and Control). Denne delkomponenten gjør det mulig for komponenter på brukernivå å opprette, slette og håndtere partisjoner, spesifisere partisjonsvise ressurser og kvoter, og å definere politikker for tidsdeling og tilgangskontroll. For eksempel kan man tenke seg at en ny partisjon opprettes ved å først gjøre et hyperkall til en modul i hypervisoren, (f eks HvCreatePartition). Deretter opprettes en eller flere virtuelle prosessorer ved å kalle et hyperkall HvCreateVp. Minne tilordnes gjestens 'fysiske' adresserom (GPA) i den nyopprettede partisjonen ved å utføre enda et hyperkall, f eks HvMapGpaPages. Et hyperkall Hvlnstalllntercepts ber om intercepts forvisse prosessorfunksjoner. Ulike politikker for tidsdeling og sikkerhet settes ved å utføre hyperkallet HvSetPartionProperty. Initialiseringskode, f eks en OS-laster eller en system-BIOS, kopieres inn i den nyopprettede virtuelle maskinens minne. Eksekvering i den virtuelle maskinen begynner når et hyperkall HvResumePartition utføres. Disse hyperkallene er kun eksempler. Fagfolk på området innser uten videre at andre og tilsvarende metoder kan implementeres for å opprette en partisjon. Fagfolk kan identifisere tilsvarende metoder for å slette en partisjon (fjerne prosessorer, GPA-sider o s v). Det samme gjelder metoder for å håndtere partisjonens ressurser.

Som nevnt over, eksisterer både VID 810 og HV API 806 i kjernemodus 804. Det finnes imidlertid andre komponenter av virtualiseringsstakken 800 i brukermodus 802. For eksempel håndterer en virtuell maskintjeneste VMSRVC 812 et sett VM-konfigurasjoner og tilveiebringer et sett WMI-baserte APIer for å håndtere og styre virtuelle maskiner. Denne er ansvarlig for å avdele en ny VM arbeidsprosess når en virtuell maskin startes. Denne tjenesten kan lages slik at det er mulig å starte den om uten at noen av VM arbeidsprosessene påvirkes (hvilket gjør systemet mer fleksibelt og robust hvis tjenesten havarerer).

En annen komponent i brukermodus 802 er Virtuell Maskin Arbeidsprosess 814. Hver virtuelle maskin har en tilhørende arbeidsprosess. Hvis en komponent inne i arbeidsprosessen havarerer, kan skaden begrenses til en enkelt virtuell maskin. I arbeidsprosessen 814 er det et rammeverk for virtualiserte enheter. En virtuell maskin er satt sammen av et sett virtuelle (maskinvare)enheter. Hver enhet har sine egne innstillinger og parametre. Mange av disse kan justeres av brukeren. Enhetsrammeverket har ansvaret for å instansiere (lage nye forekomster av) virtuelle enhetsmoduler, og for å "koble sammen" disse enhetene til en funksjonell virtuell maskin. Enhetene som inngår i en virtuell maskin er definert i et enhetsmanifest, som er en del av den virtuelle maskinens konfigurasjonsfil.

Inne i det foran nevnte rammeverket er de virtuelle enhetsmodulene (VDEVene). Disse plugg-inn-modulene inneholder logikken som som trengs for å instansiere, initialisere, lagre, hente, og terminere en virtuell enhet. Noen virtuelle enheter implementerer full emulering av de opprinnelige maskinvareenhetene. Disse virtuelle enhetene kalles emulerte enhetsmoduler, og bruker l/O og minne-intercepts for å agere på gjesteaksesser.

Inne i arbeidsprosessen 814 kan det også befinne seg en virtuell-maskin-skaper (creator). Denne komponenten har ansvaret for å opprette og håndtere en kjørende virtuell maskin. Den håndterer politikker som gjelder hele den virtuelle maskinen, og agerer på forespørsler om dynamiske ressursendringer. Den har også ansvaret for stopp og start, lagring og fremhenting, ta snapshot og varm migrering av den virtuelle maskinen.

Selv om den foreliggende søknadsgjenstanden er beskrevet i forbindelse med de foretrukne utførelsesformene som er vist i de ulike figurene, er det underforstått at andre tilsvarende utførelsesformer kan benyttes, eller at trekk kan modifiseres eller tilføyes i de beskrevne utførelsesformene for å utføre de samme funksjonene i den foreliggende oppfinnelsen uten at oppfinnelsen endres. For eksempel ble en utførelsesform drøftet i forbindelse med hierarkisk virtualisering muliggjort ved bruk av en flernivå virtualiseringsmekanisme. Andre mekanismer som tilsvarer funksjonaliteten i de beskrevne utførelsesformene skal imidlertid også omfattes av oppfinnelsen. Derfor skal ikke den foreliggende oppfinnelsen begrenses til bestemte utførelsesformer, men fortolkes ut fra bredden og omfanget av de vedføyde kravene.

Claims (20)

1. Fremgangsmåte for å tilveiebringe hierarkisk virtualisering, omfattende: å opprettholde en første partisjon (608) med en hypervisor (600), der den første partisjon (608) omfatter en første virtualiseringsstakk (602) som er i stand til å opprette og styre mer enn én partisjon til enhver tid; og å vekselvirke med en andre partisjon (606) ved å bruke den første virtualiseringsstakk (602) i den første partisjonen (608), hvor hypervisoren (600) kjenner til den første partisjonen (608) og den andre partisjonen (606), og hvor den første partisjon og den andre partisjon er virtualiserte representasjoner av datamaskinvare, og den andre partisjon har minst én ressurs som er eksklusivt styrt av den andre partisjon.

2. Fremgangsmåte i følge krav 1, hvor hypervisoren (400) videre kjenner til minst én ressurs (416) i den første partisjonen (406) og den andre partisjonen (414), og hvor hypervisoren (400) er konfigurert til å holde en fortegnelse over den minst ene ressursen (416) etter forespørsel.

3. Fremgangsmåte i følge krav 1, hvor den andre partisjonen (606) kommuni-serer direkte med hypervisoren (600).

4. Fremgangsmåte i følge krav 1, hvor den første virtualiseringsstakken (602) oppretter den andre partisjonen (606).

5. Fremgangsmåte i følge krav 4, hvor den andre partisjonen (606) inneholder en andre virtualiseringsstakk (610) som er konfigurert til å opprette og vekselvirke med en tredje partisjon (605).

6. Fremgangsmåte i følge krav 1, hvor den første partisjonen (508) inneholder den første virtualiseringsstakken (502) og også en andre virtualiseringsstakk (503), hvor den første virtualiseringsstakken (502) og den andre virtualiseringsstakken (503) befinner seg i den første partisjonen (508) samtidig i en viss tidsperiode.

7. Fremgangsmåte i følge krav 1, hvor den første virtualiseringsstakken (508) oppretter den andre partisjonen (504) og en tredje partisjon (506).

8. Databehandlingssystem for tilveiebringelse av sikret hierarkisk virtualisering, omfattende: datamaskinvare, et vertsoperativsystem konfigurert til å kjøres på datamaskinvaren, idet vertsoperativsystemet eksponerer eller fremviser et grensesnitt til en morpartisjon (404) med en hypervisor (400), hvor morpartisjonen (404) har en virtualiseringsstakk (402) som er i stand til å opprette og styre mer enn én partisjon til enhver tid, og en datterpartisjon (406), hvor datterpartisjonen (406) er opprettet av virtualiseringsstakken (402) i morpartisjonen (404), og hvor datterpartisjonen (406) har minst én ressurs (414) som er eksklusivt styrt av datterpartisjonen (406), og hvor morpartisjonen og datterpartisjonen er virtualiserte representasjoner av datamaskinvare, og hvor hypervisoren (400) kjenner til morpartisjonen (404) og datterpartisjonen (406).

9. System i følge krav 8, hvor ressursen (414) omfatter minst én minneside.

10. System i følge krav 8, hvor datterpartisjonen (406) oppnår eksklusiv styring av ressursen (414) ved å sende en forespørsel (410) til morpartisjonen (404).

11. System i følge krav 10, hvor hypervisoren (400) validerer (412) at morpartisjonen (404) har rettet seg etter forespørselen (410) som ble sendt av datterpartisjonen (406).

12. System i følge krav 10, hvor forespørselen (410) som sendes av datterpartisjonen (406), sendes av en operativsystemkjerne i datterpartisjonen (406).

13. System i følge krav 10, hvor forespørselen (410) som sendes av datterpartisjonen (406), sendes av en driver i datterpartisjonen (406).

14. System i følge krav 10, hvor forespørselen (410) som sendes av datterpartisjonen (406), sendes til en bootlaster i morpartisjonen (404).

15. Datamaskinlesbart medium med datamaskineksekverbare instruksjoner som tilveiebringer hierarkisk virtualisering, omfattende: å bruke en første partisjon (608) til å opprette en andre partisjon (604), hvor den andre partisjonen (604) er opprettet av en virtualiseringsstakk (602) i den første partisjonen (608), hvor virtualiseringsstakken (602) er i stand til å opprette og styre mer enn én partisjon til enhver tid og å tilveiebringe en hypervisor (600) med mikrokjerne, som er konfigurert til å vekselvirke direkte med den første partisjonen (608) og den andre partisjonen (604), hvor den første partisjon og den andre partisjon er virtualiserte representasjoner av datamaskinvare, og den andre partisjon har minst én ressurs som er eksklusivt styrt av den andre partisjon.

16. Et datamaskinlesbart medium i følge krav 15, hvor virtualiseringsstakken (602) i den første partisjonen (608) videre oppretter en tredje partisjon (606).

17. Et datamaskinlesbart medium i følge krav 15, som videre omfatter en andre virtualiseringsstakk (503) lokalisert i den første partisjonen (508), hvor den andre virtualiseringsstakken (503) oppretter en tredje partisjon (505).

18. Et datamaskinlesbart medium i følge krav 15, hvor den andre partisjonen (606) har sin egen virtualiseringsstakk (610).

19. Et datamaskinlesbart medium i følge krav 18, hvor virtualiseringsstakken (610) i den andre partisjonen (606) oppretter en tredje partisjon (605).

20. Et datamaskinlesbart medium i følge krav 18, hvor virtualiseringsstakken (602) i den første partisjonen (608) og en virtualiseringsstakk (610) i den andre partisjonen (606) eksisterer samtidig i en viss tidsperiode.