Software-update: Xen 3.3.1

Xen is een 'virtuele machine hypervisor' voor het x86-platform en laat meerdere besturingssystemen gelijktijdig op één systeem draaien zonder de prestaties drastisch te beïnvloeden. Voor meer informatie over Xen en de bijbehorende community verwijzen we jullie door naar deze en deze pagina. Op dit moment worden alleen Linux en Netbsd ondersteund als hostsystemen, maar men is druk bezig om ook andere besturingssystemen, zoals Solaris, volledig te ondersteunen. De ontwikkelaars hebben deze maand Xen 3.3.1 met de volgende aankondiging uitgebracht:

The Xen 3.3 release contains architectural improvements and new user-visible features, compared to 3.2, including:
  • Power management (P & C states) in the hypervisor
  • HVM emulation domains (qemu-on-minios) for better scalability, performance and security
  • PVGrub: boot PV kernels using real GRUB inside the PV domain
  • Better PV performance: domain lock removed from pagetable-update paths
  • Shadow3: optimisations to make this the best shadow pagetable algorithm yet, making HVM performance better than ever
  • Hardware Assisted Paging enhancements: 2MB page support for better TLB locality
  • CPUID feature levelling: allows safe domain migration across systems with different CPU models
  • PVSCSI drivers for SCSI access direct into PV guests
  • HVM framebuffer optimisations: scan for framebuffer updates more efficiently
  • Device passthrough enhancements
  • Full x86 real-mode emulation for HVM guests on Intel VT: supports a much wider range of legacy guest OSes
  • New qemu merge with upstream development
  • Many other changes in both x86 and IA64 ports
Xen 3.3.1 is a maintenance release in the 3.3 series.
Versienummer 3.3.1
Releasestatus Final
Besturingssystemen Linux
Website Xen
Download http://xen.org/download/
Licentietype GPL

Door Japke Rosink

Meukposter

29-01-2009 • 15:30

18

Bron: Xen

Update-historie

11-'22 Xen 4.15.4 15
07-'22 Xen 4.15.3 0
04-'21 Xen 4.15.0 5
11-'20 Xen 4.13.2 / 4.12.4 0
01-'20 Xen 4.12.2 3
04-'19 Xen 4.12.0 14
03-'19 Xen 4.10.3 / 4.9.4 0
12-'18 Xen 4.11.1 / 4.8.5 7
09-'18 Xen 4.10.2 / 4.9.3 3
07-'18 Xen 4.8.4 9
Meer historie

Reacties (18)

18
18
7
5
1
5
Wijzig sortering
wat is nu dan het wezelijke verschil met http://www.virtualbox.org/

xen draait 'in' de kernel?
Virtualbox heeft ook een kernelcomponent nodig, net zoals alle andere virtualisatiesystemen.

Het verschil is dat Xen op hardware die geen Intel VT of AMD -V ondersteunt, paravirtualisatie doet. Dat betekent dat het guest OS moet aangepast zijn aan Xen, en daardoor kan er bvb. geen Windows gedraaid worden.

Naast paravirtualisatie, kan Xen ook volledige virtualisatie doen als je Intel VT of AMD-V ondersteuning hebt. In dat geval kunnen wel ongewijzigde besturingssystemen gedraaid worden. Virtualbox heeft echter geen Intel VT of AMD-V nodig om ongewijzigde OS'en te draaien.

Xen werkt hoofdzakelijk enkel op een zwaar gepatchte 2.6.18 kernel, terwijl Virtualbox op zowat elke standaardkernel aan de praat te krijgen is. Ook is Xen over het algemeen eerder geschikt voor serverdoeleinden (servers die headless draaien), terwijl Virtualbox eerder gebruikt wordt voor client OS'en die je niet headless draait. Virtualbox komt bijvoorbeeld met een uitgebreide, gebruiksvriendelijke GUI, iets wat je bij Xen standaard niet hebt (alhoewel je zoiets ook wel enigszins kan doen met virt-manager).

Daarnaast is er ook nog KVM. Dat zit in de standaard Linuxkernel zelf al ingebouwd en werkt enkel met Intel VT of AMD-V, en doet volledige virtualisatie, geen paravirtualisatie. Het kan dus ongewijzigde OS'en draaien. Het kan ook virtio voorzien, dat is een techniek waarbij bepaalde drivers (vb. voor disk controller en netwerkkaart) in het client OS aangepast worden, waardoor ze sneller kunnen communiceren met het host OS. Aangezien KVM in de Linuxkernel zit, in tegenstelling tot Xen, wordt dit wellicht in de toekomst het meestgebruikte open source virtualisatiesysteem voor servers.
Xen is op dit moment slechts deels aanwezig in de upstream kernel. ( dat wil zeggen, alleen support voor de virtuele machines ( domu) is aanwezig, maar niet voor het hoofdsysteem, dom0 )

Toch is er vanuit de xen communitie een push om xen in de mainstream kernel te krijgen. Door de grote hoeveelheid code die bij xen betrokken is gaat dit echter nog niet heel snel. Maar bij xen begrijpen ze ook echt wel de noodzaak om hun code in de mainstream te krijgen.
Goed verwoord... maar wil er nog wel even aan toevoegen dat VirtualBox wel middels commandline te starten is in headless mode.

VBoxHeadless programma. Hiermee kun je ook op een Linux machine zonder Xorg een ander systeem virtualiseren!
Het belangrijkste verschil is het verschil in doelgroep.

Waar Virtualbox vooral gebruikt word voor desktops, word Xen vooral gebruikt op servers.

Bij het gebruik van Xen word er gebruik gemaakt van een hypervisor. De hypervisor in xen is eigelijk een "eigen kernel" die de hardware abstactie op zich neemt. Alle machines ( dus ook de hoofdmachine ) draaien hier "virtueel" boven op. De hoofdmachine ( de zogenaamde dom0 ) heeft wel meer rechten dan de andere virtuele machines. ( de domu )

Het meest practische van xen is dat het volledig vanaf de console te gebruiken is. Er is dus geen X server of andere grafische schil nodig. Ook niet geheel onbelangrijk zijn features zoals het live migreren van machines van 1 machine naar een andere ( hiervoor is wel centrale storage vereist ) Waardoor gemakkelijk onderhoud aan fysieke machines gedaan kan worden. Dit maakt xen vooral een datacenter dingetje.

[Reactie gewijzigd door MoonWatcher op 25 juli 2024 09:56]

Ligt er aan wat je bedoelt, op Solaris heb je xVM (xen) en VirtualBox. Het voordeel van Virtualbox/KVM/Qemu dingen is dat de scheduling in de OS laag plaatsvindt en dat het dus relatief eenvoudig met bestaande middelen wordt opgelost. Daar tegenover staat de overhead die daarvoor nodig is en dat er geen garanties zijn dat er bijvoorbeeld genoeg geheugen over is. Nu is bij Xen de 'overhead' ernstig relatief omdat je door een verschrikkelijke Python meuk ongeveer ~256MB aan diskruimte kwijt bent voor alleen het beheer gedeelte en dat beheergedeelte niet het zuinigste omgaat met geheugen, ik verwacht dat memoryleaks daar de oorzaak van zijn.

Dat soort flauwekul heb je minder met een qemu oplossing, het mooie is dat er binnenkort ook een qemu/xen starter aan zit te komen. En daar wacht ik eigenlijk op.
Xen draait op je hardware, de kernels draaien hier weer op, dit is sneller omdat er geen complete virtuele machine ge-emuleerd hoef te worden. de kernels zijn zich e rvan bewust dat ze gevirtualizeerd zijn.
naast het bovenstaande kan je voor meer indormatie hier kijken:
http://fedoraforum.org/forum/printthread.php?t=199835

Het is een discussie over welke virtualisatie technieken het beste gebruikt kan worden met veel interessante informatie.
Anoniem: 19339 29 januari 2009 21:30
Ik snap de opzet van Xen niet helemaal... Heb het idee dat ik wat mis.

Ben zelf Debian en Ubuntu liefhebber. Ik heb deze howto gevolgd, en het werkt op zich wel.

Maar het is me niet duidelijk hoe het zit met het updaten van je host en/of guests met bijvoorbeeld apt-get dist-upgrade. Er worden toch door Xen alternatieve kernels geinstalleerd? Gaat dat dan goed als je een dist-upgrade uitvoert? En in de guests-os'en?

edit: Thanks, Moon! Die link mistte ik dus even, dat de kernel van de domU's dus eigenlijk op de host staan... Dus als ik het goed begrijp: even domU's down gooien, dist-upgrade, al dan niet rebooten, domU's weer up. Thanks! :)

[Reactie gewijzigd door Anoniem: 19339 op 25 juli 2024 09:56]

De Xen Kernel Van de xen client staat op de server.

Open maar eens een .cfg server bestandje in /etc/xen, daar staat de locatie op het hoofd systeem van de kernel die gebruikt word aangegeven. ( meestal iets van /boot/vmlinuz-2.6.18-6-xen-686 of zoiets )

Ik weet niet of het wijsheid is om een live server te dist-upgraden op het moment dat er nog virtuele machines op draaien. Dit omdat je na een dist-upgrade vaak even wil herstarten om zeker te zijn dat alles goed draait en is doorgevoerd. In een data center zou ik iets verwachten in de trend van: machines live virtueel verhuizen naar een andere server, xen server upgraden naar nieuwe versie, virtuele machines terug zetten. virtuele machines dist-upgraden. xen kernel in .cfg bestand naar de nieuwe kernel laten gebruiken en de xen clients herstarten met de nieuwe xen kernel.

Als je maar 1 machine hebt die je wil upgraden kan je er natuurlijk voor kiezen om even al je clients af te sluiten. De dist upgrade door te voeren, je xen client config files in /etc/xen/*.cfg aan te passen naar de nieuwe xen kernel en dan je hele machine een herstart te geven. ( Uiteraard zijn backups voor zo'n senario een pre. ook de downtime van de virtuele machines is op deze manier een stuk hoger )
Inprinsipe hoefje de dom0 = Xen Hypervisor laag, niet te upgraden... Als het werkt dan werkt het zegmaar...

Maar je domU's daarentegen, die draaien wel direct met de buitenwereld, en worden ook echt gebruikt... Deze kunnen zonder problemen worden geüpgrade ;)
Toch knap van Citrix dat de ontwikkeling van deze opensource tak stevig onderhouden blijft.
Dit is overigens een kleine bug-update bovenop 3.3 zegmaar..

Maar ik vind het zeker respectvol dat Citrix de opensource tak niet in de weg zit.

Wat is overigens wel erg jammer vind is dat xen met behoorlijk oude kernel-patches zit...

offtopic:
Dit is mijn eerste meuktip die ook echt geplaatste is
Zojuist ook een waarschuwing van Citrix voor Xenserver 4.0.1 en 4.1.0 binnen gekregen:
http://support.citrix.com/article/CTX118766

Vulnerability in XenServer could result in privilege escalation and arbitrary code execution.

A vulnerabilitly has been identified in Citrix XenServer that could result in attackers escaping a guest domain and potentially executing arbitrary code in in the control domain.
Mitigating Factors
In order to exploit this vulnerability the user needs write access to an Ext2/Ext3 partition which is used by XenServer to boot a guest domain running Linux.
Toch gaat mijn voorkeur uit naar ESXi. Sinds dat ze met een gratis versie uit zijn gekomen, is xen voor mij betreft hobbyen niet meer interessant.
Welke nieuwe linux disto's hebben nog Xen ondersteuning!?

Las dat zowel Ubuntu als Fedora geen Xen kernel meer mee leveren. Wat ik heel spijtig vind. In Ubuntu 8.10 is het nog wel mogelijk om een 2.6.27 kernel zelf te maken las ik.. Fedora doet het daarentegen met Xenner.

Wil graag met Xen stoeien, helaas doet mijn nieuwe laptop (E6500) het niet goed met de linux kernel.Iets van een bad cheksum met m'n intel netwerkkaart.
doordat zowel ubuntu als fedora next-gen qua o.a. support & kernel zijn, en Xen niet werkt op de laatst kernel.. zit dat er niet in ;-)
Eindelijk, dat heeft lang geduurd zeg...:
· CPUID feature levelling: allows safe domain migration across systems with different CPU models
· Full x86 real-mode emulation for HVM guests on Intel VT: supports a much wider range of legacy guest OSes

Op dit item kan niet meer gereageerd worden.