Bestehende Systeme nach XEN migrieren

[bla!zilla]

Hallo Leute,

hier sind ja einige mit XEN KnowHow unterwegs. Da ich eher aus der VMware Welt unterwegs bin, fehlen mir da die Praxiserfahrungen:

Ich habe einen Server mit RHEL 5.1 und XEN. Die CPU unterstüzt IVT. Ich habe ein Quellsystem, auf dem eine andere Linux-Distribution läuft. Mehrere dieser Systeme sollen nun P2V auf die XEN Maschinen migriert werden. Kann ich einfach die vorhandenen Platten per Knoppix Live-CD und dd abziehen und XEN unterschieben, oder hat das nicht hin?

So hatte ich mir das gedacht:

1. Quellsystem per CD booten
2. Pro Partition dd if=/dev/?da1/2/3 of=ZIELVERZEICHNIS/part1/2/3 bs=1M
3. Die erstellten Partitionimages XEN unterschieben

Wie läuft das bei XEN mit den Bootloadern?? Ich habe mal gelesen das die nicht in den MBR installiert werden, sondern... wo?!

Danke für eure Hilfe.

[giotto]

Hi bla!zilla

In iX 4 2008 habe ich einen Artikel gelesen, bei dem eine Xen Instanz als Cold Standby Lösung für einen Physischen Server gebraucht wird (Rootdisk auf dem SAN und solche Spässe).

Dies lässt auch daraus schliessen, dass die Migration klappen wird. Es muss allerdings noch unterschieden werden, ob Du ein Voll -oder Paravirtualisiertes Gastsystem laufen lassen willst. Ausprobiert habe ich jedoch nur mal eine Migration von Vollvirtualisierung nach Paravirtualisierung.

Ich würde das mal so versuchen mit der Migration:

mit dd die bestehende Partition(en) auf den VM Host dumpen, am besten auf ein Logical Volume oder eine andere Partition. Es bietet sich auch die Möglichkeit, innerhalb von einem Image oder einer Partition nochmal zu Partitionieren, hierfür bietet sich das Tool kpartx an.

So oder so würde ich das System das erste Mal vollvirtualisiert booten, dementsprechend musst Du ein HVM Konfigfile unter /etc/xen erstellen. Danach kannst Du die VM mit xm create -c /etc/xen/deinekonfig zu starten versuchen.

Zum Booten ist folgendes zu sagen: Xen bietet 2 Arten, maschinen zu booten:

Bei RedHat ist der pygrub standard, dieser hat den Vorteil, dass er die normale menu.lst vom Gast ausliest. Das wiederum hat den Vorteil, dass du keine Konfigurationen bei einem Kernelupdate machen musst, da diese up2date oder yum automatisch erledigt, sprich in der menu.lst einträgt.

Die andere Variante ist die direkte Konfiguration des bootkernels und der initrd direkt im Konfigfile der VM, etwa:

# Kernel image file.
kernel = "/boot/vmlinuz-2.6.10-xenU"

# Optional ramdisk.
ramdisk = "/boot/initrd.gz"

Hier muss man beachten, dass diese beiden Files auf dem Hostsystem liegen müssen, man muss diese also extrahieren.

Falls Du dann dein System noch auf Paravirtualisierung umrüsten willst (z.B. RHEL4.5 oder RHEL5), kann man das folgendermassen machen:

- Installation des xenU Kernels mittels yum oder up2date
- Initrd mit dem paravirt Blocktreiber neu erstellen, z.B.

mkinitrd -v --with=xenblk --omit-scsi-modules --omit-raid-modules /boot/initrd-2.6.9-55.ELxenU.img 2.6.9-55.ELxenU

(Versionen anpassen)
- menu.lst checken, ob der neue xenU kernel defaultmässig gebootet wird (für pygrub), oder den Kernel und die neue initrd aus der vm extrahieren und im xen Konfigfile eintragen.
- builder eintrag im konfigfile auskommentieren, um die VM auf paravirt umzustellen
- booten und freude haben! :-)

Hoffe, ich konnte das einigermassen verständlich rüberbrigen!

Viel Glück und Gruess

Giotto

[bla!zilla]

Wie unterscheidest du Vollvirtualisierung und Paravirtualisierung? Paravirtualisierung ist doch Virtualisierung anhand von IVT oder AMD-V, korrekt? Der Rest hilft mir schon mal weiter.

[cane]

Ohne Gewähr:

Bei Paravirtualisierung muss IMO der kernel des gasts verändert werden, bei Vollvirtualisierung ist das nicht nötig.

mfg
cane

[giotto]

Hallo zusammen

Mmmh, VT und AMD-V braucht man für Vollvirtualisierung, da wird dem Gast quasi ein vollständiges System vorgegaukelt. So kann beispielsweise auch ein Windows als Xen Gast betrieben werden.

Wie Cane schon gesagt hat braucht man für Paravirtualisierung speziell angepasste Kernel, bei RHEL gibt es solche ab RHEL4U5 und natürlich für RHEL5. Das System weiss, das es virtualisiert ist, und so können Schnittstellen wie Netz und Blockdevices runter zum Hostsystem optimiert werden. So hat man bei der Paravirualisierung einen gewaltigen Performancevorteil, ist meiner Meinung nach wirklich verblüffend, was man da rauskriegt! :-)

Ach ja, für Paravirtualisierung braucht man auch keine CPUs die das Unterstützen, einfach den Xen Kernel booten und gut ist.

Gruss, Giotto

[bla!zilla]

Also sollte ich in jedem Fall der Paravirtualisierung den Vorzug geben?? Ich dachte bisher immer, dass IVT oder AMD-V aufgrund der Integration in die Hardware schneller sind. Gibt es da irgendwo Zahlen?

Bis hierhin erstmal vielen Dank für die Denkansätze.

[fuffy]

Hi!

Also sollte ich in jedem Fall der Paravirtualisierung den Vorzug geben?? Ich dachte bisher immer, dass IVT oder AMD-V aufgrund der Integration in die Hardware schneller sind. Gibt es da irgendwo Zahlen?

Ich kenne zwar keine Zahlen, aber selbst VMware verzichtet z.B. auf AMD-V, weil deren Software-Implementierung nach eigenen Angaben effizienter ist.

Gruß
fuffy

[bla!zilla]

Bei VMware Workstation / Server weiß ich das ich einen Haken setzen kann, aber beim ESX wird der Kram nicht genutzt. Die Aussage seitens VMware war mir bisher unbekannt.

Na ja, im Prinzip ist es auch egal, die Gastsysteme auch Linux-Maschinen sind. Die könnten also ruhigt mit einem angepassten Kernel laufen.

[unux]

Hi,

Zahlen habe ich bisher keine, kann aber gerne in den nächsten Tagen, wenn mal wieder ein bisschen Luft ist, mal einen Benchmark laufen lassen. Rein subjektiv gesehen hatte ich ebenfalls das Gefühl, dass ein paravirtualisiertes System schneller rennt als ein voll virtualisiertes.

Solltest du aber bestimmte PCI-Devices, Com-Ports etc. in deiner domU benötigen, kommst du mit deiner Hardware nicht mehr um einen paravirtualisierten Gast herum. Durchreichen von Devices an HVM Gäste ist am Anfang der Entwicklung und benötigt VT-d.

Greetz UnuX

[bla!zilla]

Neee, nix. Die Kisten sind dumme Mailrelays, Proxies, Load-Balancer aus einer Testumgebung. Die brauchen nix, außer Plattenplatz, RAM, CPU und Netzwerkkonnektivität.

[giotto]

Hi bla!zilla

Ja, wenn du kannst, dann mach paravirtualisierung.

Gemäss meinen Erfahrungen sind paravirtualisiert VMs einiges schneller als vollvirtualisierte.

Für solche Server die du virtualisieren willst, bietet sich das ja geradezu an.

Schöne Tag und Gruess
Giotto

[asterixer]

Hi Blazilla,

Ich war vor ein paar Wochen auf einem Vortrag zu OracleVM was auf XEN Basiert. Oracle raet dringend zu Paravirtualiserierung, da das um Faktoren (irgenwas mit 4) schneller sein soll.
Allerdings geht das mit dem Paravirtualisierung nur fuer Linux Gaeste, Windows geht nur Vollvirtualisiert.

Die einzige auf XEN basierte Virtualisierungsloesung die ich kenne die Windows wirklich flott als Gast rennen laest ist Virtual Iron. Die installieren allerdings diverse Treiber im Gast um eine sehr gute Performance zu erreichen.

Asterix