Xen en VMware vechten om native Linux-ondersteuning

Linux-kerneldeveloper Greg Kroah-Hartman heeft zijn toehoorders gisteren tijdens de O'Reilly Open Source Conference voorgehouden dat de Linux-kernel niet voorzien zal worden van ondersteuning voor één specifieke virtualisatietechnologie. De reden daarvoor is dat XenSource en VMware, de twee spelers die hun technologie in de kernel zouden willen hebben, nog niet tot een gezamenlijke oplossing hebben kunnen komen. Zowel XenSource als VMware ontwikkelen virtualisatie- en hypervisorsoftware en beide bedrijven zouden ook graag zien dat hun technologie in de Linux-kernel wordt opgenomen. De technologieën van de twee bedrijven zijn echter incompatibel. De kernelmaintainers hebben dit aan XenSource en VMware laten weten en ook verteld dat er gezocht moet worden naar een gezamenlijke oplossing, zodat Linux met beide producten kan samenwerken.

Het is echter geen eenvoudige taak om XenSource en VMware met elkaar in gesprek te laten komen en inmiddels zijn daarom enkele neutrale partijen bij de gesprekken betrokken. Vooralsnog ziet het er evenwel niet naar uit dat een oplossing op korte termijn verwacht kan worden. Oorspronkelijk was het de bedoeling dat Xen in de kernel geïntegreerd zou worden, wat zou betekenen dat Linux alleen bovenop de Xen-hypervisor zou kunnen draaien en dat Linux niet zou kunnen omgaan met de VMware-hypervisor. Dat ging echter niet door, omdat besloten werd dat er een generieke hypervisorinterface in de kernel moest komen. Volgens XenSource bestaat er echter al een interface die gebruikt kan worden voor de communicatie tussen hypervisors en Linux-kernel. Deze wordt al gebruikt in de Xen-implementaties bij Novell en Red Hat. De mening van VMware over deze software is vooralsnog onbekend.

Reacties (34)

Wordt hier dan al rekening gehouden met de toekomstige hardware virtualisaties van intel en amd?

Die is er al, en wordt zowel door Xen als VMWare ondersteund

Lijkt mij dat de standaard voor zulke dingen niet overgelaten kan worden aan de virtualisatie industrie zelf dus dan maar andersom: laat de standaardisatie over aan kerneldevelopers, distrubiteurs en communities en dan mogen deze bedrijven (en anderen) proberen hun producten daar op af te stemmen.

Zoals mijn moeder zei: Ik wil ook wel eens wat.

ideologisch gezien heb je gelijk, echter is die gedachte (zelfs) in de Linux wereld steeds minder terug te vinden. Tegenwoordig gaat het gewoon om ' big bucks'

Maar gelukkig is dat het om de big bucks gaat nog niet doorgeslagen op de kerneldevelopers.

Goede zaak.

Ik weet niet of het wel een goed zaak voor Linux is.

Als de ego minded mensen van beide bedrijven niet tot elkaar komen mist Linux een behoorlijk belangrijke functionaliteit. Of dat Linux ten goede komt is maar zeer de vraag.

Ik weet niet waarom je mij aanhaalt hoor, maar ik heb niet om iets gevraagd of iets beweerd wat ook maar op enige manier contact maakt met jouw verhaal.

@pruttelpot

wrong. Linux mist die functie niet.

Je kunt gewoon een patch van Xen of VMware loslaten op je kernel source en die dan compilen. Geen punt. Het zit alleen maar niet default in de kernel - en dat is dus iets waar distro's voor moeten gaan zorgen. (al met al zijn die dus zo'n beetje het slachtoffer van de strijd tussen Xen en VMware)

Als distro's dat niet doen, is het dus niet mogelijk om linux binnen een virtual machine te _installeren_. Dat zegt niets over het gebruik. Je kunt linux installeren buiten de VM, dan de kernel patchen en compilen en daarme inside de VM booten (nadat je het systeem herstart hebt). Stuk ingewikkelder, sad enough.

Er worden regelmatig patches voor de Linux kernel afgewezen. Bijvoorbeeld omdat de kwaliteit niet goed is, of het de kernel developers teveel extra werk gaat kosten.

Algemene regel is, lever het goed aan, dan supporten wij ook de toekomstige revisies erop (als een interne interface aangepast wordt bijvoorbeeld).

Zolang je code niet in de mainstream kernel zit, moet je zelf constant veranderingen in de kernel bijhouden, en gebruikers moeten steeds aparte drivers/patches van je software installeren. In de mainsteam kernel wordt je code zelf ook onderhouden voor je, en wordt het standaard op ieder Linux systeem meegeleverd.

ff voor de duidelijkheid, nadat je code is opgenomen wordt je nog steeds geacht de boel te onderhouden.

Maar er wordt wat meer rekening met je gehouden, en de kans dat anderen helpen met patches is groter.

Wat maakt het uit dat er een virtualisatietechniek in de kernel wordt gestopt

Draait het dan in een VM omgeving Voor zover ik weet is dat al het geval.
Kan het dan een VM omgeving starten Voor zover ik weet is dat ook al mogelijk.

Het enige wat ik kan bedenken is dat het mogelijk is om een VM omgeving sneller te laten draaien, maar of dat noodzakelijk is en of het de implementatie van 2 verschillende technieken waard is: nee.

@70070540: MS heeft dit ook nog niet (voor zover ik weet), dus of dit nou zooo belangrijk is

Het gaat inderdaad om sneller en beter. Met technieken als Xen en VMWare ESX heb je geen Host OS meer nodig en nu nog wel.

MS heeft (binnenkort) Windows Virtualisation. Wat eigenlijk hetzelfde doet als Xen en VMWare, maar dan voor Windows. In een eerder artikel heeft MS aangegeven "compatible" te willen worden met Xen (Xen-enabled OS ook op WV draaien. Windows zal nooit op Xen draaien).

Er zijn dus eigenlijk drie grote hypervisors, die van Xen, VMWare en MS. Linux zal geen ondersteuning krijgen voor die van MS, aangezien MS dat niet zal toelaten. Linux kan dus eventueel ondersteuning krijgen voor een algemene hypervisor interface, die VMWare en Xen dan gaan implementeren.

Met een beetje mazzel gaat MS ook die generieke interface inplementeren (in zijn WV natuurlijk, niet in Windows Guests), zodat Linux zowel op Xen, VMWare als WV zal kunnen draaien.

Windows zal in dat scenario overigens nog steeds alleen op WV kunnen draaien, MS wil natuurlijk niet dat Windows onder een andere hypervisor dan die van zichzelf kan werken.

windows zal nooit op xen draaien? Ik heb in verschillende bronnen gelezen dat dat met de introductie van hardware assisted virtualisatie wel mogelijk zal worden. Waar heb jij jouw info vandaan?

Wij bieden zelfs al Windows VM's op Xen hosts aan.

Werkt prima, maar de processor moet dan wel VT, of Pacifica ondersteuning bieden.

Ah, nu begrijp ik het wat beter.

Die techniek is nodig om meerdere VM's te starten zonder een host OS. Dus voor een specifiek server systeem met verschillende servers.
De VM's zouden dan onderling met elkaar moeten afstemmen over wie wat wanneer doet. Begrijp ik het zo goed


Over Windows en Xen: ik weet niet zeker wat ik er allemaal over gelezen had. De ene keer lees ik dat Windows er niet op zal draaien, maar wel als host zal ondersteunen. De andere keer lees ik dat MS een speciaal Xen enabled OS zal uitgeven (naast de bestaande OS-sen). Dus wat het nu is/wordt

Ik denk dat MS zowel host als client OS op xen zal draaien.

Feit is dat beide technische geen probleem is voor MS & xen.(ze werken al langer samen) Het feit dat er nog een boel FUD rondom dit thema is geeft wel aan dat dit nog geen toekomstvaste keus is.

op het moment moeten de kernel modules nog vaak zelf gecompileerd worden

en dat wil nog wel eens een b*tch zijn

Ik heb Debian met 2.6 kernel laatst in een VmWare omgeving geinstalleerd, zonder dat ik specifieke acties heb moeten doen.
Het blijft gewoon werken

Dus je wil zeggen dat een Linux distributie met Linux kernel 2.6.15+ niet op Vmware te installeren is?

En als je dus een normale update van je kernel zou doen zonder patches hij ineens niet meer wil werken?

Lijkt me erg vervelend(al lijkt me niet dat dit zo is overigens).

Overigens heb ik ubuntu(6.06 met kernel 2.6.15.6) laatst nog op vmware workstation geinstalleerd zonder problemen, maar het zou dus bij hogere versies kunnen zijn.

nee dat zeg ik niet
dat gaat prima zelfs

andersom is het lastiger, Vmware draaien op een 2.6.15+ kernel gaat niet heel erg out-of-the-box
het wil wel, maar je moet er wat meer moeite voor doen
nogmaals, ik bedoel dus Linux als vmware host

Ok, duidelijk.
Verkeerd begrepen

dat kan kloppen ja

maar probeer het maar eens met een hagelnieuwe kernel
vanaf 2.6.15 (of iets in die buurt) ben je wel patches nodig

ook wel te doen, maar jammer dat het nodig is
dat soort dingen worden wel opgelost als het in de kernel geintegreerd wordt

MS heeft dit ook nog niet (voor zover ik weet), dus of dit nou zooo belangrijk is

Dus als MS iets niet heeft is het ook niet belangrijk?

Er zullen velen zijn (waaronder ik) die het daar niet mee eens zijn.

Waarschijnlijk is er dus incompatibiliteit tussen de kernel drivers.
Ik draai Suse 10.1 en als ik de XEN-kernel start willen de VMWare drivers ook niet compileren (ook niet met patch die nodig is).
Helaas is dat nu dus niet naast elkaar te gebruiken (of ik mis wat).
Een uniforme interface lijkt me dan ook een ideale oplossing, dat kan dan mooi tot standaard worden verheven.

Men wil Xen en VMware niet naast elkaar draaien, men wil vooral voorkomen dat er twee (relatief complexe/ingrijpende) hypervisors moeten worden onderhouden.

Dan hebben we strax misschien nog:

linux-image-2.6.18-2-xen
linux-image-2.6.18-2-vmw

Het zou wel de makkelijkste oplossing zijn. en je hebt nu ook al voor lek systeem een andere kernel (686, k7, enz)

EDIT:

hhmm, deed net even zoeken naar een paar kernel header packetten op backports, en daar zag ik al xen en vserver pakketten, dus waarom houden we het niet zo?

Je begrijpt het niet.

Natuurlijk kan je xen en vmw in de source gooien en een selectie maken welke je wilt hebben.
net zo als 686 k7 enz....

Maar Men wilt dat je elke willekeurige Distro pakt en je deze aan de virtuele omgeving kan kangen.
net zo als bijne elke voor i386 gebaseerde pc de install cd in i386 is gecompileert.

De oplossing is natuurlijk duidelijk. Weg met allebei en een open source virtualisatie systeem schrijven wat je dan ondersteund in de kernel.

Xen is toch opensource?

Een uniforme interface zou idd wel ideaal zijn.

begrijp niet dat de kernel developers niet kiezen voor de sterkste partij. Xen is echt gewoon nowhere in virtulisatieland. Nu kiezen voor VMWare en als Xen ooit een rol van betekenis gaat spelen moeten ze zich maar aanpassen.

Om de ruimte open te laten voor nog een derde opkomende partij eventueel? Ze willen zich iig niet wedden op 1 paard. Dat paart moet nog wel wat jaren mee kunnen gaan.

Wordt bij 3D drivers ook niet gedaan, er is keurig een interface waarop ATI, NVidia e.d. aansluiten. Zoiets gaat er nu dus ook komen voor VM software.

en TERECHT.

als er één partij gebaad is bij Open Interface Standaarden dan is dat wel de linux kernel -
deze hele kernel staat aan de bron van wellicht miljoenen computers, en tientallen "grote" en honderden (zo niet duizende) "kleine" distro's

als je die bron al laat vervuilen door de belangen van 1 enkel bedrijft, krijg je daar hoe dan ook problemen mee

Tja, een beetje van vrije keus

Volgens mij was Xen open source en willen ze die wel ondersteunen, het past namelijk in hun ideologie.
Maar VmWare is een grote jongen en kan niet overgeslagen worden.

Dat geeft een dilemma waar een oplossing voor gezocht moet worden

Tja, voor elk platform is weer een andere oplossing.
XEN en vmware draait alleen op het x86 platform.
Voor het PPC platform is er weer een andere oplossing.
IBM heeft dit al jaren geleden ontwikkeld voor het system/390 en dat heet VM/390.
Dit draait ook op Power4 en Power5 gebaseerde processoren.
Zoals bijv. de PPC970 die ook door Apple gebruikt wordt.