Univention Bugzilla – Bug 19943
Xen 4 für UCS-DVS
Last modified: 2023-03-25 06:48:27 CET
UCS DVS (OpenDVDI) sollte direkt auf Xen 4 aufbauen. +++ This bug was initially created as a clone of Bug #18357 +++ Wir sollten eine Integration von Xen 4 prüfen. Nach unserer Patch-Policy für UCS 3.0. Ggf. können wir die angepassten Pakete schon vorab für UCS 2.4 als Component bereitstellen.
(In reply to comment #2) > Hier liegt eine erste Testversion: > trunk/component/xen4/xen-4.0
Die Version 4.0.1 liegt im svn. Sie ist im scope "xen4" gebaut worden. Es wurde ein Bug beim Starten des xend gefixt http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1436 . In der blktap2-Makefile wurden Librarypfade korrigiert und das Kernelmodul blktap wird beim Starten des xend geladen.
1. In der debian/controls fehlt mindestens noch ein "Conflicts: xen-3.4", da beide Paket die selben Konfigurations- und Programmdateien verwenden. 2. Ggf. auch noch ein "Depends: libxenstore ${binary:Version}", aber bisher tut Xen-4.0 auch noch mit der alten libxenstore3.0 aus Xen-3.4. 3. Der Patch für PyGrub (z.B. /home/phahn/src/dev/ucs/virtualization/xen-3.4/debian/patches/pygrub_empty_root.patch) fehlt noch.
(In reply to comment #3) > 2. Ggf. auch noch ein "Depends: libxenstore ${binary:Version}", aber bisher tut > Xen-4.0 auch noch mit der alten libxenstore3.0 aus Xen-3.4. Das passt immer noch nicht: > # dpkg -s libxenstore3.0 > Package: libxenstore3.0 > Depends: xen-4.0 (= 4.0.1-7.8.201011041850) Diese Abhängigkeit gehört da nicht hin, weil libxenstore auch ohne xen-4.0 funktioniert. Hintergrund ist, daß libvirt beim Bauen Xen braucht, beim Betrieb allerdings nur die xenstore-lib. Mit der obigen Abhängigkeit müsste dann auch immer Xen installiert sein. > # dpkg -s xen-4.0 > Package: xen-4.0 > Depends: ..., libxenstore3.0, ... Ein Vergleich von "objdump -T /usr/lib/xenstore.so | cut -c 9-" zwischen xen-3.4 und xen-4.0 zeigt, daß die 4er Version zusätzlich das Symbol xs_daemon_destroy_postfork() exportiert, das u.a. von libxl benutzt wird. Damit besteht prinzipiell dann die Gefahr, daß Programme zur Laufzeit wegen des fehlenden Symbols abstürzen. Von daher sollte hier dringend das oben erwähnte "Depends: libxenstore3.0 (= ${binary:Version})" in der debian/controls für Package: xen-4.0 ergänzt werden. In Debian wird das durch die debian/libxenstore3.0.symbols-Datei erreicht: libxenstore.so.3.0 libxenstore3.0 #MINVER# expanding_buffer_ensure@Base 3.2.0 sanitise_value@Base 3.2.0 unsanitise_value@Base 3.2.0 xprintf@Base 3.2.0 xs_count_strings@Base 3.2.0 xs_daemon_close@Base 3.2.0 xs_daemon_open@Base 3.2.0 xs_daemon_open_readonly@Base 3.2.0 xs_daemon_destroy_postfork@Base 4.0.1~rc4 xs_daemon_rootdir@Base 3.2.0 xs_daemon_rundir@Base 3.2.0 xs_daemon_socket@Base 3.2.0 xs_daemon_socket_ro@Base 3.2.0 xs_daemon_tdb@Base 3.2.0 xs_debug_command@Base 3.2.0 xs_directory@Base 3.2.0 xs_domain_dev@Base 3.2.0 xs_domain_open@Base 3.2.0 xs_fileno@Base 3.2.0 xs_get_domain_path@Base 3.2.0 xs_get_permissions@Base 3.2.0 xs_introduce_domain@Base 3.2.0 xs_is_domain_introduced@Base 3.2.0 xs_mkdir@Base 3.2.0 xs_perm_to_string@Base 3.2.0 xs_read@Base 3.2.0 xs_read_watch@Base 3.2.0 xs_release_domain@Base 3.2.0 xs_resume_domain@Base 3.2.0 xs_rm@Base 3.2.0 xs_set_permissions@Base 3.2.0 xs_set_target@Base 3.4.0 xs_strings_to_perms@Base 3.2.0 xs_suspend_evtchn_port@Base 3.4.0 xs_transaction_end@Base 3.2.0 xs_transaction_start@Base 3.2.0 xs_unwatch@Base 3.2.0 xs_watch@Base 3.2.0 xs_write@Base 3.2.0 xs_write_all@Base 3.2.0 Das reicht allerdings nicht, da die libxenlight.so.1.0.0 es seinerseits versäumt, seine Abhängigkeit auf libxenstore.so zu benennen: @ xen-4.0.1/tools/libxl/Makefile:62 libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS) - $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_CFLAGS) -o $@ $^ + $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_libxenstore) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_CFLAGS) -o $@ $^ (FYI: dh_shlibdeps ruft dpkg-shlibdeps auf; das "objdump -x ... | grep NEEDED" auswertet. libxenlight fehlt die Abhängigkeit auf libxenstore, weshalb hier nicht erkannt wird, daß xs_daemon_destroy_postfork() aus libxenstore4 benutzt wird. sbin/xl seinerseits nutzt diese neue Funktion nicht direkt, so das die alte Version noch reicht.) In dem Rahmen sollte auch noch korrigiert werden, das in das libxenstore3.0-Paket nur die *.so.*-Dateien, nicht aber die *.so- und *.a-Datei gehört, da diese nur für das Bauen von weiteren Paketen benötigt werden.
Die Besagten Änderungen wurden vorgenommen
Da ist noch eine Fehler auf xen-users aufgefallen: <http://lists.xensource.com/archives/html/xen-users/2010-11/msg00219.html> <http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1686>
<http://xen.1045712.n5.nabble.com/PATCH-blktap2-blktap2-and-pygrub-xen-unstable-td2547829.html> scheint auch noch für PyGrub notwendig zu sein. Beim erstmaligen Starten einer PV-Domain trat allerdings das Problem auf, daß PyGrub nicht funktionierte: [2010-11-10 17:58:29 4263] INFO (XendDomainInfo:3253) Mounting /var/lib/libvirt/images/ucs24-1-1.qcow on /dev/xvdp. [2010-11-10 17:58:29 4263] DEBUG (DevController:95) DevController: writing {'backend-id': '0', 'virtual-device': '51952', 'device-type': 'disk', 'state': '1', 'backend': '/local/domain/0/backend/vbd/0/51952'} to /local/domain/0/device/vbd/51952. [2010-11-10 17:58:29 4263] DEBUG (DevController:97) DevController: writing {'domain': 'Domain-0', 'frontend': '/local/domain/0/device/vbd/51952', 'uuid': '56c46a8f-157e-904d-11a4-c33cddbbe39f', 'bootable': '0', 'dev': '/dev/xvdp', 'state': '1', 'params': '/dev/xen/blktap-2/tapdev0', 'mode': 'r', 'online': '1', 'frontend-id': '0', 'type': 'phy', 'tapdisk-params': 'qcow:/var/lib/libvirt/images/ucs24-1-1.qcow'} to /local/domain/0/backend/vbd/0/51952. [2010-11-10 17:58:29 4263] DEBUG (DevController:144) Waiting for 51952. [2010-11-10 17:58:29 4263] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug-status. [2010-11-10 17:58:29 4263] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug-status. [2010-11-10 17:58:29 4263] DEBUG (DevController:642) hotplugStatusCallback 1. [2010-11-10 17:58:29 4263] DEBUG (DevController:144) Waiting for 51952. [2010-11-10 17:58:29 4263] DEBUG (DevController:628) hotplugStatusCallback /local/domain/0/backend/vbd/0/51952/hotplug-status. [2010-11-10 17:58:29 4263] DEBUG (DevController:642) hotplugStatusCallback 1. [2010-11-10 17:58:29 4263] ERROR (XendBootloader:43) Disk '/dev/xvdp' isn't accessible [2010-11-10 17:58:29 4263] ERROR (XendDomainInfo:3271) Disk '/dev/xvdp' isn't accessible [2010-11-10 17:58:29 4263] ERROR (XendDomainInfo:3272) Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/xen/xend/XendDomainInfo.py", line 3269, in _configureBootloader bootloader_args, kernel, ramdisk, args) File "/usr/lib/python2.5/site-packages/xen/xend/XendBootloader.py", line 44, in bootloader raise VmError(msg) VmError: Disk '/dev/xvdp' isn't accessible [2010-11-10 17:58:29 4263] INFO (XendDomainInfo:3277) Unmounting /dev/xvdp from /dev/xvdp. [2010-11-10 17:58:29 4263] DEBUG (XendDomainInfo:1286) XendDomainInfo.destroyDevice: deviceClass = tap2, device = /dev/xvdp Der 2. Versuch danach war allerdings erfolgreich. Ich vernute eine Race-Condition zwischen udev und xend, was ein abermaliger Test bestätigt. Durch folgende Schleife wurde das Problem umschifft: /usr/share/pyshared/xen/xend/XendBootloader.py +import time ... def bootloader(...): ... + retries = 10 + while not os.access(disk, os.R_OK): msg = "Disk '%s' isn't accessible" % disk log.error(msg) + time.sleep(1) + retries -= 1 + if retries <= 0: ! raise VmError(msg) ...
Patches wurden eingespielt
Paket wurde nur für amd64 getestet: + Upgrade von xen-3.4.3 funktioniert. + Installation Windows XP (32 FV) funktioniert + Installation Windows 7 (64 FV) funktioniert + Installation UCS_2.4 (32 FV) funktioniert + Installation UCS_2.4 (32 PV) funktioniert + Installation UCS_2.4 (32 FV+tap:Qcow2) funktioniert + Installation UCS_2.4 (32 FV+tap2:aio) funktioniert Bedienung per xm, xl, virsh und UVMM geht: xm pause unpause xm suspend resume xm start destroy shutdown FV-Maschinen fühlen sich immer noch recht träge an, PV-Installation war deutlich schneller. Da scheint sich leider nichte verbessert zu haben. Unschön ist lediglich noch die zusätzliche Abhängigkeit auf python2.5, die wahrscheinlich durch pygrub kommt: # dpkg -s xen-4.0 | egrep --only "python(2..)?( \([^(]+\))?(,|$)" python (<< 2.6), python (>= 2.4), python2.5, # dpkg -L xen-4.0 | xargs grep -s bin/python2.5 /usr/bin/pygrub:#!/usr/bin/python2.5