Re: Update XEN-Host und DomU
Boris <boris@cation.de> wrote:
> # Kernel + memory size
> #
> kernel = '/boot/vmlinuz-2.6.32-5-xen-amd64'
> ramdisk = '/boot/initrd.img-2.6.32-5-xen-amd64'
> Trotzdem bleibt das Kernel-Handling verwirrend - irgendwas verstehe ich
> da noch nicht:
> In der Dom0 läuft der 64bit-Kern:
> dom0# uname -a
> Linux nl-sv-xen2 2.6.32-5-xen-amd64 #1 SMP Mon Sep 23 23:29:01 UTC 2013
> x86_64 GNU/Linux
> In der DomU läuft der auch (das nenne ich 'durchgereicht'):
> domU# uname -a
> Linux nl-vsv-web2 2.6.32-5-xen-amd64 #1 SMP Mon Sep 23 23:29:01 UTC 2013
> x86_64 GNU/Linux
> Er ist in der DomU nicht installiert, sondern ein 32-bit-Kernel mit Modulen:
> domU# dpkg -l | grep linux
> ii linux-image-2.6.32-5-xen-686 2.6.32-48squeeze6
> Linux 2.6.32 for modern PCs, Xen dom0 support
> ii linux-modules-2.6.26-1-xen-686 2.6.26-13lenny2
> Linux 2.6.26 modules on i686
Dieser Kernel wird aber nicht benutzt.
> Und die VM sagt mir auch, sie würde als 32bit-System laufen:
> domU:# getconf LONG_BIT
> 32
> Das widerspricht sich doch, oder?
Nein, ein AMD64-Kernel kann ohne weiteres auch i386-Programme ausführen.
Vor Jahren (bevor die CPUs Hardware-Virtualisierung konnten) hatte ich
so ein Setup auch (64bit Dom0 und 64bit DomU-Kernel mit 32bit Userland)
und dabei sind einige wichtige Dinge zu Tage getreten:
Bestimmte Kernel-nahe Programme, wie z.B. iptables oder lvm waren damals
in der zum Kernel passenden Bit-Breite nötig, weil diese sonst nicht
korrekt mit dem Kernel kommunizieren konnten. Dies (und die Abwesenheit
von sauberem Multiarch, lediglich hackisches BiArch) führt dazu, dass
ich iptables und lvm dann mit dpkg --force in der 64bit-Version ins
System geprügelt habe, damit die Sache funktioniert.
Heute würde ich dringend dazu raten, etwas wie pygrub zu benutzen, um den
Kernel _in_ der DomU zu starten und nicht den Kernel von aussen
durchzureichen.
Damit ist man dann auch wesentlich unabhängiger, was Updates der
einzelnen Systeme angeht.
S°
--
Sigmentation fault. Core dumped.
Reply to: