Xen | |
---|---|
Xen som kör NetBSD och tre Linux- distributioner | |
Sorts | Virtualiseringsserver _ |
Utvecklaren | Xen-projektet, XenSource, Inc. |
Skrivet i | C [1] |
Operativ system | Linux , OpenSolaris , BSD |
Första upplagan | 2003 |
senaste versionen | |
Licens | GNU GPL 2 [3] |
Hemsida | xenproject.org |
Mediafiler på Wikimedia Commons |
Xen (pron. / ˈzɛn / ) är en plattformsoberoende hypervisor utvecklad vid University of Cambridge Computer Lab och licensierad under GPL . Huvudfunktioner: stöd för paravirtualiseringsläget förutom hårdvaruvirtualisering, minimikoden för själva hypervisorn på grund av att det maximala antalet komponenter utanför hypervisorn har tagits bort.
Xen började som ett forskningsprojekt vid University of Cambridge ledd av Ian Pratt , som senare blev grundaren av XenSource. Företaget stödde utvecklingen av en öppen källkodsversion (xen) och sålde samtidigt kommersiella versioner av programvaran som heter XenServer och XenEnterprise.
Den första offentliga versionen av Xen var 2003. I oktober 2007 köpte Citrix XenSource och döpte om produkterna:
De döptes senare om till XenServer (gratis), Essentials för XenServer Enterprise och Essentials för XenServer Platinum.
Den 22 oktober 2007 slutförde Citrix sitt övertagande av XenSource [4] och det kostnadsfria projektet flyttade till xen.org.
Den 21 oktober 2009 meddelade Citrix att kommersiella versioner av XenServer skulle bli helt gratis [5] . Simon Crosby , chefsingenjör för Citrix Virtualization Division, sa: "XenServer är 100 % gratis och kommer snart att vara helt öppen källkod. Vi planerar inte att göra någon vinst [på detta] alls” [6] ). Det finns en gratisversion av Citrix XenServer, men XenCenter (centraliserad hanteringsprogramvara) är inte källkodad, även om den är tillgänglig för gratis nedladdning.
15 april 2013 Xen kom under Linux Foundations vingar [1] Arkiverad 19 april 2013 på Wayback Machine
Version | Utgivningsdatum | Anteckningar |
---|---|---|
1.0 | 2003.10.02 [7] [8] | |
2.0 | 2004.11.05 [9] | Livemigrering för paravirtuella gästmaskiner |
3.0 | 2005.12.05 [10] [11] |
Version 3.0.4 lade också till: |
3.1 | 2007.05.18 [15] | Livemigrering för HVM-gäster, XenAPI-stöd |
3.2 | 2008.01.17 [16] | "Vidarebefordra" PCI, "viloläge" ACPI S3. |
3.3 | 2008.08.24 [17] | Förbättringar av PCI-vidarebefordran och energihantering. |
3.4 | 2009.05.18 [18] | Innehåller den första versionen av "Xen Client Initiative" (XCI). |
4.0 | 2010.04.07 [19] | Tillåter att Linux-kärnor används som dom0 med den nya PVOps-mekanismen. [tjugo] |
4.1 | 2011/03/25 [21] | Stöd för mer än 255 processorer, förbättrad stabilitet.( [22] ). |
4.2 | 2012.09.17 [23] | Stöd för 4095 fysiska (och upp till 512 virtuella) processorer, stöd för flera PCI-segment, förbättrad säkerhet och dokumentation.( [24] ). |
4.3 | 2013.07.09 [25] | Experimentellt stöd för ARM. Redovisning av funktionerna i NUMA-arkitekturen i schemaläggaren. Öppna vSwitch- stöd . |
4.4 | 2014/03/10 [26] | ARM-stödet är nu stabilt. Stöd för libxl av libvirt-biblioteket. Nytt skalbart gränssnitt för evenemangskanaler. Stöd för att skapa kapslade virtuella miljöer på Intel-hårdvara. Borttaget stöd för x86 32-bitars och ia64 (itanium) hypervisorer. |
4.5 | 2015/01/15 [27] | Toolstack skrivs nu om i C och kallas xl eller libxl, och ersätter helt den gamla verktygsstack xend som skrevs i python. |
4.6 | 2015/10/13 [28] | |
4.7 | 2016.06.24 [29] | Förbättringar: säkerhet, livemigrering, prestanda och arbetsbelastning. Hårdvarustöd (ARM och Intel Xeon). [trettio] |
4.8.1 | 2017.04.12 [31] | |
4.9 | 2017/07/28 [32] | Xen Project 4.9 Release Notes |
4.10 | 2017/12/12 [33] | Xen Project 4.10 Release Notes |
4.11 | 2018.07.10 [34] | Xen Project 4.11 Release Notes |
4.12 | 2019.04.02 [35] | Xen Project 4.12 Release Notes |
Tekniken för virtuella maskiner låter dig utöka utrustningens funktionalitet på följande sätt:
Kärnkonceptet för en hypervisor är en domän . En kör kopia av en virtuell maskin kallas en domän. Om den virtuella maskinen startas om, avslutas dess domän (vid tidpunkten för omstart) och en ny domän visas. Dessutom, även under migreringen, kopieras innehåll från en domän till en annan. Under sin livstid befinner sig alltså nästan alla virtuella maskiner i sin tur i olika domäner. Xen arbetar endast med konceptet en domän, och konceptet med en "virtuell maskin" dyker upp på administrationsnivå (applikationsprogram som styr hypervisorn).
Domäner är av flera typer. De mest kända är dom0 och domU . dom0 är den första lanserade Xen-domänen, vanligtvis skapas och laddas den automatiskt omedelbart efter att hypervisorn har laddats och initierats. Den här domänen har speciella rättigheter att kontrollera hypervisorn, och som standard är all datorhårdvara tillgänglig från dom0. Faktum är att dom0 är där programvaran som hanterar Xen bor. dom0 är alltid ensam.
domU är en medlemsdomän (förkortning för User domain) som innehåller domänen för virtuella maskiner som körs. Har vanligtvis inte tillgång till riktig hårdvara och är "nyttolasten" för virtualiseringssystemet. Till skillnad från dom0 kan domU vara många (vanligtvis flera dussin).
stub-domän - en domän som kör ett mycket specialiserat OS som ger arbete med vilken hårdvara eller drivrutin som helst. Det är en vidareutveckling av Xen-säkerhetsmodellen.
domänbyggare (domänkonstruktor) - ett program som skapar domU (laddar in den nödvändiga koden och säger åt hypervisorn att köras). Förutom att konstruera domänen sysslar han vanligtvis med att ansluta och konfigurera de virtuella enheter som är tillgängliga för den virtuella maskinen. Hon är också ansvarig för processen att migrera en virtuell maskin från värd till värd.
Paravirtualisering är anpassningen av kärnan i ett körbart operativsystem för att fungera tillsammans med Xen, vanligtvis förkortat till PV. Låter dig uppnå mycket hög prestanda på grund av bristen på emulering av "riktig hårdvara", enkelheten i gränssnitt och med hänsyn till förekomsten av en hypervisor när systemanrop i kärnkoden körs. Exekveringen av privilegierade operationer är förbjudna, istället för dem görs hypercalls ( eng. hypercalls ) - förfrågningar från gäst-OS-kärnan till hypervisorn med en begäran om att utföra vissa operationer. I de flesta fall påverkar ändringar vid portering av ett OS till Xen endast OS-kärnan, även om de kan innebära mindre ändringar i systembibliotek (t.ex. libc). Processen att anpassa sig till Xen är mycket lik portering för en ny plattform, men den är mycket enklare på grund av den enkla implementeringen av "gäst"-delen av drivrutinen (drivrutiner i Xen består av två delar - en exekveras utanför virtuell maskin, den andra är inuti den. Delen av drivrutinen i gästsystemet är extremt primitiv och fungerar endast som en frågeöversättare till den andra delen (detta gjordes avsiktligt för att underlätta porteringen av operativsystemet till Xen). PV-läge stöder inte "kapslade" processorlägen, såsom real-86, virtual-86, växling mellan 32-bitars och 64-bitars läge, stöd för hårdvaruvirtualiseringsemulering, etc. I detta avseende, PV-läge, finns det inget initialt fragment av datorstarten (med imitation av BIOS-kod, bootloader, etc.), och gästsystemkärnan startar omedelbart i önskat läge, precis som vanliga program startar. I detta avseende, i synnerhet, kan Xen själv inte köras i PV-läge (det vill säga det är omöjligt att köra en "kapslad" hypervisor i PV-läge).
I hårdvaruvirtualiseringsläge (HVM) "vet" gästoperativsystemet inte om hypervisorns existens. Xen, med hjälp av moduler från QEMU , emulerar riktig hårdvara och låter dig starta operativsystemet. I slutet av det, för normal prestanda, bör PV-drivrutiner lanseras som implementerar ett snabbt gränssnitt med virtuella enheter, liknande hur det fungerar i PV-läge. Eftersom de flesta av de privilegierade operationerna emuleras är det möjligt att köra Xen i HVM-läge från under Xen. I detta fall kan den kapslade hypervisorn endast fungera i PV-läge.
Xen-hypervisorn (för version 3.4) implementerar en minimal uppsättning operationer för att hantera huvudminne, processortillstånd, processorns realtidstimer och klockräknare (TSC), avbrott och DMA-kontroll. Alla andra funktioner, såsom implementering av disk- och blockenheter, skapande och borttagning av virtuella maskiner, deras migrering mellan servrar, etc., implementeras i kontrolldomänen. På grund av detta är storleken på hypervisorn mycket liten (för version 3.4 är storleken på den binära koden för hela hypervisorn mindre än 600 KB), liksom storleken på dess källkod. Enligt författarnas avsikt ökar detta stabiliteten i virtualiseringssystemet, eftersom ett fel i komponenter utanför hypervisorn inte leder till kompromiss/skada på själva hypervisorn och begränsar skadan till endast den misslyckade komponenten, utan att störa resten.
Alla funktioner relaterade till driften av nätverket, block (disk) enheter, emulering av videoadaptrar och andra enheter flyttas ut från hypervisorn. De flesta av dessa enheter består av två delar: drivrutiner i domU och program i dom0. Drivrutinen (oftast inbyggd i OS-kärnan eller laddad som en modul) implementerar den minsta mängden arbete, i själva verket att översätta förfrågningar från OS till programmet i dom0. Programmet i dom0 gör det mesta. I det här fallet körs programmet oftast som en separat process för varje servad enhet. Ett fel i ett sådant program leder till fel på endast en enhet (block, nätverk) och påverkar inte driften av andra kopior av programmet (det vill säga det påverkar inte nätverket / blockera enheterna i andra domäner, eller till och med andra enheter inom samma domän).
Följande terminologi används traditionellt: frontend är den del av modulen som finns i domU, backend är delen som finns i dom0. För vissa enhetstyper kan backend-delen vara annorlunda samtidigt som man behåller samma frontend-del. Till exempel kan en blockenhetsdrivrutin ha en backend i form av en VHD-avbildare, en blockenhetsdrivrutin, en iscsi-initiator och så vidare.
Xen tillhandahåller tre kommunikationsmekanismer för domäner: en med hypervisorn (hypercalls) och två mellan domänerna. Oftast sker interaktion mellan dom0 och domU, även om modellen tillåter interaktion mellan två domUs.
Interaktion över domäner kommer ner till två typer: händelser (händelser) och delade mem (delad minnesåtkomst). Det tredje alternativet, överföring av minnessidor, är ett specialfall av tillgång till delat minne.
Händelser tjänar ungefär samma syfte som avbrott i x86-arkitekturen eller signaler i Unix - snabb synkron eller asynkron överföring av en signal om förekomsten av någon händelse. Delad minnesåtkomst ger möjlighet att överföra betydande mängder information och händelser ger en överföringshastighet.
Händelser kan maskeras eller demaskeras. Omaskerade händelser orsakar ett återuppringning (anropar funktionen vars adress skickades tidigare) och låter dig bearbeta händelsen direkt efter att den inträffar. Maskerade händelser sätter bara en flagga för att händelsen har inträffat, och hanteraren ser med jämna mellanrum för att se om händelsen (en eller flera) har inträffat. Den andra metoden gör att du inte kan ringa tillbaka för varje händelse och, vid frekventa händelser, minskar handläggningstiden avsevärt. Tvärtom låter det första alternativet (med ett återuppringningssamtal) dig öka hastigheten för att bearbeta en händelse som kanske inte inträffar särskilt ofta, men som kräver ett omedelbart svar.
Xen (via hanteringsstacken) stöder migrering av virtuella gästdatorer över nätverket. Migrering av paravirtuella maskiner stöds från version Xen 2, och HVM - från version 3. Migrering kan ske med gästsystemet avstängt, eller direkt i processen, den så kallade "live" migreringen ( engelska live migration ) utan förlust av tillgänglighet.
Det krävs att båda fysiska Xen-servrarna ser samma lagring där den virtuella maskinens data finns. Detta krävs eftersom vid migrering av en virtuell maskin kopieras inte dess filsystem, eftersom detta skulle ta för mycket tid även i fallet med ett snabbt nätverk. Delad lagring kan baseras på olika SAN- eller NAS -tekniker som Fibre Channel , iSCSI eller DRBD .
På grund av det faktum att hypervisorn själv (ca 500-600 KB) implementerar endast "kärnan" i systemet, flyttas all annan funktionalitet till applikationslagret som körs i dom0. En uppsättning program som implementerar funktionalitet utanför Xen kallas engelska. toolstack (det finns ingen väletablerad översättning, ibland används termen "management stack").
Det finns två versioner av verktygsstacken för Xen: xend- baserad (ingår i de flesta Xen-distributioner) och xapi- baserad (ingår i Citrix XenServer och Xen Cloud Platform). Xend utvecklades samtidigt som Xen, skriven i Python, och från första början var den under en öppen källkodslicens. Xapi tillhörde Xensource (hädanefter Citrix), men släpptes under GPL 2009. Xapi är skriven i OCaml , i skrivande stund hade den en mindre uppsättning funktioner, men var mer stabil.
I version 4.5 ersattes xend skrivet i python av xl/libxl skrivet i C.
Båda versionerna av verktygsstapeln innehåller följande verktyg:
Toolstack tillhandahåller hantering av virtuella maskiner (skapande/radering, start/stopp, migrering, anslutning av resurser, etc.). Dessutom tillhandahåller verktygslådan resurshantering för storskaliga system: den skapar och underhåller arkiv för lagring av virtuella maskindiskavbildningar (SR - storage repository), stöder serverpooler för migrering av virtuella maskiner och kan hantera komplexa lokala nätverkskonfigurationer, inklusive de med stöd för VLAN . Dessutom stöds XenApi-fjärrkontrollgränssnittet baserat på XML-RPC [36] .
Xen stöder fler och fler plattformar varje dag.
Som en typ 1 hybrid hypervisor körs Xen direkt på hårdvaruplattformen men kräver ett värdoperativsystem i dom0 för att köras. Xen stöder processorer från Pentium II , det finns versioner för x86-64 , PowerPC , Itanium (upp till version 4.4) och ARM-arkitekturer (stabil sedan version 4.4). Ladda Xen görs med en boot loader som GRUB eller liknande. Direkt efter laddning startar Xen operativsystemet i dom0.
De flesta installationer använder Linux som operativsystem för dom0-kontrolldomänen. Under en lång tid ingick inte Xen-stöd i den officiella Linux-kärnan och fanns som en uppsättning patchar för v2.6.18-kärnan. Sedan v2.6.37 har pv_ops- mekanismen dykt upp i Linux-kärnan för att interagera med hypervisorer [37] . Denna mekanism gör att kärnan kan arbeta både i paravirtuellt läge och direkt på hårdvaran. Från och med Xen 4.0 stöder den pv_ops-mekanismen för Linux-kärnan i dom0 [38] . Linux-kärnor över 3.0 har också fullt stöd för Xen för både dom0 och domU [39] .
Dessutom kan följande operativsystem fungera som dom0:
De flesta operativsystem kan köras i HVM hårdvaruvirtualiseringsläge, men paravirtualiseringsteknik används för att uppnå hög exekveringshastighet. Följande gästoperativsystem kan köras i paravirtuellt läge i domU:
Portar av andra operativsystem som Plan 9 är också under arbete. Det förväntas att officiella portar för Xen kommer att släppas för alla dessa operativsystem (som hände för NetBSD).
Operativsystem i Microsoft Windows-familjen kan köras i fullt HVM-virtualiseringsläge från och med Xen 3 på processorer som stöder hårdvaruvirtualisering. I det här fallet emuleras virtuella enheter (disk, nätverk) med en speciell version av QEMU . För att snabba upp Windows kan så kallade paravirtuella drivrutiner användas . Till skillnad från Linux i paravirtuellt läge är Windows-kärnan omodifierad och körs i hårdvaruvirtualiseringsläge, men enhetsdrivrutiner får åtkomst till Xen direkt (via HyperCalls), och kringgår QEMU-emuleringsskiktet. Det finns en utveckling av GPL-baserade paravirtualiseringsdrivrutiner för Windows, och Citrix XenServer och Oracle VM-produkter innehåller signerade paravirtualiseringsdrivrutiner för Windows.
Xen används ofta som en virtualiseringskomponent i molnberäkningar och dedikerade privata servertjänster . Värdföretag som Amazon Elastic Compute Cloud , Liquid Web , Fujitsu Global Cloud Platform , [46] Linode , SparkNode [47] och Rackspace Cloud använder Xen som en virtuell maskinhypervisor.
För närvarande[ förtydliga ] Xen-gemenskapen utvecklar Xen Cloud Platform (XCP), ett servervirtualiseringssystem. XCP kommer från den fria versionen av Citrix XenServer och släpps helt under GNU GPL .
Det finns flera kommersiella serverkonsolideringsprodukter baserade på Xen. I synnerhet är det produkter som: