Bug 18357 - Xen 4 für UCS 3.0
Xen 4 für UCS 3.0
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Virtualization - Xen
UCS 2.3
Other Linux
: P5 enhancement (vote)
: UCS 3.0 - RC
Assigned To: Philipp Hahn
Stefan Gohmann
:
Depends on:
Blocks: 24858
  Show dependency treegraph
 
Reported: 2010-05-10 08:11 CEST by Stefan Gohmann
Modified: 2011-12-13 15:47 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
dmesg.log (42.38 KB, text/plain)
2011-11-21 22:02 CET, Stefan Gohmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2010-05-10 08:11:23 CEST
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.
Comment 1 Philipp Hahn univentionstaff 2010-09-08 10:54:07 CEST
Mit Xen-3.4.3 aus UCS-2.4 scheint es derzeit nicht möglich zu sein, blktap bzw. blktap2 zu nutzen: Der Xen-3.4.3 Hypervisor baut auf den PvOpts-Kerneln (2.6.32) auf, die nur noch BlkTap2 haben, im User-Space-Teil von Xen-3.4.3 scheint aber nur BlkTap(1) vorhanden zu sein.
Es wäre für mich interessant zu wissen, ob mit Xen4 wieder BlkTap(1 oder 2) tut. Derzeit tut mit 3.4.3 eben nur file:, was die Loop-Back-Devices benutz, was verlässliche Aussagen zur Performance verbietet <https://billy.knut.univention.de/uniwiki/index.php/Copy_on_Write> und nicht Crash-resistent ist.
Wichtig für CoW in UVMM und DVS.
Comment 2 Stefan Gohmann univentionstaff 2010-09-09 14:26:08 CEST
Hier liegt eine erste Testversion:
 trunk/component/xen4/xen-4.0

Die sollte auf 4.0.1 aktualisiert und einer Xen4-Component für UCS 2.4 gebaut werden.
Comment 3 Moritz Muehlenhoff univentionstaff 2011-01-03 12:00:21 CET
Es wurde ein Speicherleck im xend gemeldet, beim Import sollte geprüft werden, ob das in Xen 4 korrigiert wurde:

Es handelt sich um den Patch xen-3.4.3-memory-leak-xend.patch aus
http://www.gitco.de/repo/src/xen-3.4.3-1.el5.src.rpm
Comment 4 Stefan Gohmann univentionstaff 2011-02-02 08:07:40 CET
Das aktuelle Paket ist im DVS Scope und sollte für UCS 3 übernommen werden. Das Debian Upstream Paket habe ich nicht importiert bzw. wieder entfernt.
Comment 5 Stefan Gohmann univentionstaff 2011-04-06 11:25:18 CEST
Es sollte direkt Xen 4.1 importiert werden. Als Vorlage kann trunk/component/xen4/xen-4.0 verwendet werden.
Comment 6 Markus Groß univentionstaff 2011-04-20 13:32:20 CEST
Hier liegt eine erste Version für Xen 4.1:
 trunk/component/xen4/xen-4.1
Comment 7 Markus Groß univentionstaff 2011-04-27 12:32:21 CEST
Das Paket univention-xen wurde ebenfalls an xen 4.1 angepasst:
trunk/component/xen4/univention-xen
Comment 8 Stefan Gohmann univentionstaff 2011-05-02 08:03:42 CEST
Die Änderungen bitte hier machen:
 dev/branches/ucs-3.0/ucs/virtualization

In trunk müssten die Änderungen wieder rückgängig gemacht werden, da das noch UCS 2.4 ist.
Comment 9 Markus Groß univentionstaff 2011-05-04 09:02:06 CEST
Die Änderungen wurden in den UCS-3.0 branch verschoben und im trunk rückgängig gemacht.
Comment 10 Moritz Muehlenhoff univentionstaff 2011-05-12 09:46:34 CEST
Es gibt eine ganze Reihe von Paketen in Squeeze, die libxen-dev als Build-Dependency benötigen, ich passe xen-4.1 noch so an, dass es als separates Binary-Paket bereitgestellt wird.
Comment 11 Moritz Muehlenhoff univentionstaff 2011-05-12 15:45:55 CEST
(In reply to comment #10)
> Es gibt eine ganze Reihe von Paketen in Squeeze, die libxen-dev als
> Build-Dependency benötigen, ich passe xen-4.1 noch so an, dass es als separates
> Binary-Paket bereitgestellt wird.

Das xen-4.1-Paket erzeugt nun ein weiteres Binary-Paket libxen-dev. Damit konnte ich libvirt 0.9.1 erfolgreich bauen (zumindest was Xen betrifft, es besteht bei libvirt noch ein zusätzliches Python/CDBS-Problem).
Comment 12 Markus Groß univentionstaff 2011-06-06 08:14:10 CEST
Das libxen-dev Paket enthält nun die nötigen Dateien der libxenlight Schnittstelle.
Außerdem wird Xen 4.1.0 nun gepatcht, um die Funktionalität dieser Schnittstelle zu erweitern und ein paar Fehler zu korrigieren.

Für Xen 4.1.1 sollten jedoch folgende Patches entfernt werden, da sie für Xen 4.1.1 zurückportiert wurden:
unmap_pages_after_coredump.patch
unmap_pages_after_save.patch
Comment 13 Philipp Hahn univentionstaff 2011-08-15 12:29:31 CEST
<http://libvirt.org/hvsupport.html> enthält eine gute Tabelle, in der aufgelistet ist, was von libvirt bereits in qemu, xen, xenapi unterstützt wird.
Comment 14 Moritz Muehlenhoff univentionstaff 2011-09-06 15:25:00 CEST
Bei der Übernahme sollte geprüft werden, ob die folgenden Xen-Patches aus UCS 2.4 noch relevant sind:

./xen-3.4/2.4-0-0-ucs/3.4.2-8-virtualization/xenblock.patch
./xen-common/2.4-0-0-ucs/3.1.0-0-1/create-old-stype-loopback-devices.patch
Comment 15 Philipp Hahn univentionstaff 2011-10-17 10:45:07 CEST
Für UCS-3.0 wurde jetzt xen-4.1.1-5.9.201110130929 paketiert.
Es wird weiterhin die Xend-(Python)-API verwendet, weil die XenLight-(C)-API von libvirt immer noch nicht richtig funktioniert und wichtige Funktionen (Migration) fehlen.

(In reply to comment #12)
> Für Xen 4.1.1 sollten jedoch folgende Patches entfernt werden, da sie für Xen
> 4.1.1 zurückportiert wurden:
> unmap_pages_after_coredump.patch
> unmap_pages_after_save.patch

die sind entfernt.

(In reply to comment #14)
> ./xen-3.4/2.4-0-0-ucs/3.4.2-8-virtualization/xenblock.patch

Der Patch war nur für OpenDVDI relevant, weil dort LVM-Snapshot-Volumes mit Leerzeichen im Namen vorkamen. Der Patch wurde aber nicht übernommen, weil das "normalerweise" nicht vorkommt.

> ./xen-common/2.4-0-0-ucs/3.1.0-0-1/create-old-stype-loopback-devices.patch

Die Patches ist nicht mehr relevant, da die Verwendung von Loop-Back-Devices zu Problemen führt und wir seit UCS-2.4-2 blocktap2 verwenden.

ChnageLog:
\item \ucsName{Xen} is updated to version 4.1.1 (\ucsBug{18357}).
Comment 16 Philipp Hahn univentionstaff 2011-10-22 06:32:31 CEST
(In reply to comment #15)
> Für UCS-3.0 wurde jetzt xen-4.1.1-5.9.201110130929 paketiert.

Da diese Woche auch noch 4.1.2 erschienen ist, wurde das kurzerhand auch noch paketiert. Beim lesen des Diffs zwischen -1 und -2 sind dann doch noch ein paar gefixte Bugs aufgefallen, die das für sinnvoll erschienen ließen.
Dabei wurden noch 2 alte Patches von Markus reaktiviert und eine von Guido verworfen.

svn28102, xen-4.1_4.1.2-1.11.201110220617.

> ChnageLog:
> \item \ucsName{Xen} is updated to version 4.1.1 (\ucsBug{18357}).

4.1.1 → 4.1.2
Comment 17 Stefan Gohmann univentionstaff 2011-11-18 20:11:51 CET
Es scheint noch ein Problem in der Kommunikation zwischen Xen und libvirt zu geben. Wenn ich meine Windows VM starte, dann wird sie anschließend in UVMM nicht mehr angezeigt, auch in libvirt ist sie nicht mehr sichtbar.

root@xen16:~# virsh list --all
16:56:22.099: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
16:56:22.101: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
16:56:22.110: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
16:56:22.111: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
16:56:22.113: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
16:56:22.226: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
16:56:22.227: 27496: error : xenHypervisorInit:2158 :  ioctl 3166208
 Id Name                 State
----------------------------------

root@xen16:~#

Ansonsten wirkte die Windows Instanz zunächst träge, nach der GPLPV Installation war das aber OK.

UCS 2.4 und UCS 3 Installationen laufen gerade.
Comment 18 Stefan Gohmann univentionstaff 2011-11-21 22:02:12 CET
Created attachment 3845 [details]
dmesg.log

Ein weiteres Problem ist, dass das Booten einer UCS Installations-DVD sehr lange dauert, siehe dmesg.log.
Comment 19 Philipp Hahn univentionstaff 2011-11-22 08:21:50 CET
Relevanter Auszug aus Attachment 3845 [details]:
> [5.776073] XENBUS: Waiting for devices to initialise: 295s...

Das passiert eigentlich immer dann, wenn gemischt IDE-Laufwerke und PV-Laufwerke in PV-Xen-Domains vorkommen: Dann findet Xen immer nur eine Sorte von Laufwerken und wartet 300s, bis er die anderen findet. Das scheitert aber dann IMHO immer.
Die genaue Ursache ist mir allerdings weiterhin unklar.
Comment 20 Philipp Hahn univentionstaff 2011-11-22 17:21:02 CET
(In reply to comment #17)
Backport of libvirt-v0.8.8-195-gb24b442:
Add Support Xen sysctl v8, domctl v7.

svn9936, libvirt_0.8.7-1.104.201111221644

ChangeLog:
\item \ucsName{Xen} was updated to version 4.1.2. Support for Xen-4.1 was back-ported to \ucsName{libvirt} (\ucsBug{18357}).
Comment 21 Stefan Gohmann univentionstaff 2011-11-23 08:49:34 CET
Grundsätzlich sieht es schon sehr gut. Problematisch ist, dass ein vollvirtualisiertes UCS 3.0 nach der Installation nicht startet.
Comment 22 Philipp Hahn univentionstaff 2011-11-23 16:43:14 CET
(In reply to comment #21)
> Grundsätzlich sieht es schon sehr gut. Problematisch ist, dass ein
> vollvirtualisiertes UCS 3.0 nach der Installation nicht startet.

1. Der Kernel bootet, allerdings wird die Ausgabe beim Umschalten in den grafischen Grub schwarz.
Kommentiert man in der /boot/grub/grub.cfg alles bezüglich Umschaltung in den Grafikmodus aus, so sieht man das der Kernel bootet.


2. Unter xen-4.1 erkennt der 2.6.32-Kernel anscheinend, das er unter Xen läuft und wechselt selbständig auf die PV-Treiber (Stichwort: PV-in-HVM).

# dmesg | grep unplug
[     0.000000] Netfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated NICs.
[     0.000000] Blkfront and the Xen platform PCI driver have been compiled for this kernel: unplug emulated disks.

Das lässt über Grub sich per Kernel-Kommandozeilenparameter deaktivieren:
 xen_emul_unplug=never


3. Durch das Umschalten von HV auf PV-Treiber funktioniert die Netzwerkverbindung nicht: Die vom "xen_netfront"-Treiber erkannte eth0 hat eine MAC-Adresse von "00:00:00:00:00:00".
Ursache ist, das libvirt in der XML-Beschreibung von HV ausgeht und deswegen /domain/devices/interface/model/@type='rtl8139' setzt. Das wird in folgende Einstellungen im XenStore übersetzt, über den dom0 mit domU kommunizieren:

# xenstore-ls -f /local/domain/39/device/vif
/local/domain/39/device/vif/0/model = "rtl8139"
/local/domain/39/device/vif/0/type = "ioemu"
/local/domain/39/device/vif/0/mac = "00:16:3e:73:d5:6b"
...
/.../vif/.../error = '... parsing vif/0/mac'

Für den Fall das 'model' nicht gesetzt ist, ist in libvirt/src/xenxs/xen_sxpr.c dazu folgender Kommentar zu lesen:
         * apparently (type ioemu) breaks paravirt drivers on HVM so skip
         * this from XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU

Entfernt man aus der XML-Domain-Beschreibung die explizite Definition des Models, so funktioniert anschließend die Umschaltung von HV auf PV und xen_netfront kann die MAC-Adresse auslesen.
Comment 23 Philipp Hahn univentionstaff 2011-11-24 10:37:35 CET
(In reply to comment #22)
> 1. Der Kernel bootet, allerdings wird die Ausgabe beim Umschalten in den
> grafischen Grub schwarz.
> Kommentiert man in der /boot/grub/grub.cfg alles bezüglich Umschaltung in den
> Grafikmodus aus, so sieht man das der Kernel bootet.

Die Umstellung der Grub-Auflösung auf 800×600 wird ausgelagert in Bug #24858.
Comment 24 Stefan Gohmann univentionstaff 2011-11-24 16:38:51 CET
Wie vorhin besprochen, von
http://xen.1045712.n5.nabble.com/Xen-4-1-2-PVHVM-guest-with-Linux-3-1-0-network-problem-empty-MAC-address-all-zeroes-td4953451.html

It seems "type=ioemu" is not required for anything..
not even for normal HVM emulated nics.

So this works for both normal HVM and PVHVM:
vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]

Demnach würde ich denken, dass wir das in libvirt ändern könnten / sollten. Ein Test mit Windows Systemen mit und ohne GPLPV sollte zeigen, ob das immer funktioniert.
Comment 25 Philipp Hahn univentionstaff 2011-11-25 07:13:48 CET
(In reply to comment #24)
> Wie vorhin besprochen, von
> http://xen.1045712.n5.nabble.com/Xen-4-1-2-PVHVM-guest-with-Linux-3-1-0-network-problem-empty-MAC-address-all-zeroes-td4953451.html
> 
> It seems "type=ioemu" is not required for anything..
> not even for normal HVM emulated nics.
> 
> So this works for both normal HVM and PVHVM:
> vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]
> 
> Demnach würde ich denken, dass wir das in libvirt ändern könnten / sollten. Ein
> Test mit Windows Systemen mit und ohne GPLPV sollte zeigen, ob das immer
> funktioniert.

Aus einem anderen Posting:
 > Exactly what does the "type=ioemu" stuff mean? And why is the tap > needed for networking? And what does it do in this context (i.e. I > know that a tap is a virtual Ethernet in the DOM0, but at least for PV > the xvif is all that's needed).

ioemu is a part from qemu used in Xen to emulate the io devices for HVM guests. ioemu uses tap for the emulated ethernet device.

It is possible to use paravirtualized drivers in HVM guests for (much) better io performance. xvif is used only by a PV ethernet driver. Since Dom0 does not know if a HVM guest has PV drivers or not, both tap and xvif are provided.

type=ioemu explicitely specifies that ioemu has to be used.
Comment 26 Philipp Hahn univentionstaff 2011-11-25 14:59:35 CET
Folgender Code sorgt dafür, das bei gesetztem "ioemu" dann die MAC-Adresse fehlt:

xen-4.1/tools/python/xen/xend/server/netif.py:
...
class NetifController(DevController):
...
    def getDeviceDetails(self, config):
    ...
        front = {}
        if typ != 'ioemu':
            front = { 'handle' : "%i" % devid,
                      'mac'    : mac }

Von daher scheint es sinnvoll zu sein, 'ioemu' nicht mehr zu setzen. Das wurde in libvirt bewerkstelligt.

svn9946, libvirt_0.8.7-1.106.201111251450
ChangeLog: ±0
Comment 27 Philipp Hahn univentionstaff 2011-11-25 16:37:23 CET
Beim herunterfahren der VMs werden die blktap2-Prozesse nicht beenden. In /var/log/xen/xend-debug.log steht folgendes:

Unhandled exception in thread started by 
Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 199, in finishDeviceCleanup
    TapdiskController.destroy(path)
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 289, in destroy
    tapdisk = TapdiskController.fromDevice(device)
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 278, in fromDevice
    TapdiskController.list())
  File "/usr/lib/python2.6/dist-packages/xen/xend/server/BlktapController.py", line 256, in list
    key, value = pair.split('=')
ValueError: need more than 1 value to unpack
Comment 28 Philipp Hahn univentionstaff 2011-11-25 20:58:26 CET
Das Problem waren Leerzeichen in den Image-Dateinamen: Intern wird 'tap-ctl list' aufgerufen, das die Leerzeichen nicht quotet. Das wird dann von BlktapController.py zerhackstückt, was zu dem beobachteten Fehler führt.

Als schneller Work-Around wurde das Ausgabeformat von "tap-ctl list" jetzt auf 4 "Spalten" hart kodiert, so daß das Problem dadurch umgangen wird.

svn29601,29602, xen-4.1_4.1.2-4.15.201111252001
ChangeLog: ±0
Comment 29 Stefan Gohmann univentionstaff 2011-11-26 21:48:06 CET
(In reply to comment #26)
> Folgender Code sorgt dafür, das bei gesetztem "ioemu" dann die MAC-Adresse
> fehlt:
> 
> xen-4.1/tools/python/xen/xend/server/netif.py:
> ...
> class NetifController(DevController):
> ...
>     def getDeviceDetails(self, config):
>     ...
>         front = {}
>         if typ != 'ioemu':
>             front = { 'handle' : "%i" % devid,
>                       'mac'    : mac }
> 
> Von daher scheint es sinnvoll zu sein, 'ioemu' nicht mehr zu setzen. Das wurde
> in libvirt bewerkstelligt.
> 
> svn9946, libvirt_0.8.7-1.106.201111251450
> ChangeLog: ±0

Ich habe 0.8.7-1.106.201111251450 installiert und eine neue Xen Instanz  voll virtualisiert angelegt (10.201.0.16):

root@xen16:~# virsh dumpxml stefan_UCS_3_vollvirtualisiert
<domain type='xen' id='64'>
  <name>stefan_UCS_3_vollvirtualisiert</name>
  <uuid>47a6ae8b-1d72-ab1d-1242-53b25eaa4a8a</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type>hvm</type>
    <loader>/usr/lib/xen/boot/hvmloader</loader>
    <boot dev='cdrom'/>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
    <disk type='file' device='cdrom'>
      <driver name='tap2' type='aio'/>
      <source file='/mnt/xen16/ucs_3.0-0-latest-amd64.iso'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='tap2' type='aio'/>
      <source file='/var/lib/libvirt/images/stefan_UCS_3_vollvirtualisiert-0.raw'/>
      <target dev='hdb' bus='ide'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:6f:c2:e4'/>
      <source bridge='eth0'/>
      <script path='/etc/xen/scripts/vif-bridge'/>
      <target dev='vif64.0'/>
      <model type='rtl8139'/>
    </interface>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='5901' autoport='yes' listen='0.0.0.0' keymap='de'/>
  </devices>
</domain>

root@xen16:~# xm li stefan_UCS_3_vollvirtualisiert --long | grep -A 5 -B 2 bridge
    (device
        (vif
            (bridge eth0)
            (uuid d97a774e-9e87-433d-5fac-0925a7b935ac)
            (script /etc/xen/scripts/vif-bridge)
            (mac 00:16:3e:6f:c2:e4)
            (model rtl8139)
            (type ioemu)
            (backend 0)
        )
Comment 30 Philipp Hahn univentionstaff 2011-11-28 16:20:37 CET
Der Patch hatte statt der Endung .patch die Endung .diff und wurde deswegen vom Build-System ignoriert. Außerdem wurde die falsche Stele in libvirt gepatched.

svn9947,svn9948,svn9949 libvirt-bin_0.8.7-1.108.201111281217
ChangeLog: ±0

# virsh domxml-to-native xen-sxpr $VM.xml | grep --only '(device (vif \(([^)]*)\)*))'
(device (vif (mac '00:16:3e:cb:b0:4a')(bridge 'eth0')(script 'vif-bridge')(model 'rtl8139')))

# xm list --long $VM
...
    (device
        (vif
            (bridge eth0)
            (uuid 275a70a5-a8ba-c3db-11d1-8c4dcbc25bd2)
            (script /etc/xen/scripts/vif-bridge)
            (mac 00:16:3e:78:0e:f4)
            (model netfront)
            (backend 0)
        )
    )
...
    (device
        (vif
            (uuid 03536f86-13f3-2a09-9d65-fa99ac921748)
            (bridge eth0)
            (mac 00:16:3e:cb:b0:4a)
            (model rtl8139)
            (script vif-bridge)
        )
    )

Damit funktioniert zwar jetzt das Umschalten von HVM auf PV, allerdings treten bei der Installation mit Blktap2-Devices weiterhin SEGVs und andere Probleme (Basispakete lassen sich nicht installieren, ro-Dateisystem nach Korruption) auf, die bei mit auf zwei verschiedenen Rechnern eine zuverlässige Installation verhindern.
Dabei ist es unerheblich, ob die Instanz direkt PV oder HVM ist, die später selbständig auf die PV-Treiber wechselt.
1 oder 2 Platten ist auch unerheblich; mit mehr Platten tritt das Problem nur schneller auf.
Mit driver=file (loop-back) trat das Problem bisher nicht auf.
Comment 31 Philipp Hahn univentionstaff 2011-12-01 13:21:18 CET
(In reply to comment #26)
> Von daher scheint es sinnvoll zu sein, 'ioemu' nicht mehr zu setzen. Das wurde
> in libvirt bewerkstelligt.

Siehe <http://libvirt.org/git/?p=libvirt.git;a=commit;h=dddad4bcb452f684b9c0e9454f43ef0eba2280b5> für das "warum das in libvirt so ist".
Comment 32 Philipp Hahn univentionstaff 2011-12-02 14:16:18 CET
Da das Auftreten der Speicherkorruption bisher nur auf einen Rechnertyp begrenz
ist, wird das getrennt über Bug #25102 weiterbearbeitet.
Ansonsten funktioniert Xen-4.1.2.

Ggf. noch offene Punkte:
1. Umstellen auf libaio1 aus Debian
2. Fehlende Abhängigkeit auf python-lxml (Bug #25060)
3. "ioemu": Ggf. eine Möglichkeit im UVMM zu schaffen, kein Modell(="Automatisch") anzugeben, was dann per Default sowohl einen PV-NIC wie auch einen HV-NIC (rtl8139) zur Verfügung stellen würde.
Comment 33 Stefan Gohmann univentionstaff 2011-12-02 19:18:17 CET
Funktioniert soweit, der Rest folgt in den Produkttests. Auch die Live-Migration von Xen Instanzen von 2.4-4 nach 3.0 war erfolgreich.

Der umgekehrte Weg hat nicht funktioniert, das sollte aber irrelevant sein.
Comment 34 Sönke Schwardt-Krummrich univentionstaff 2011-12-13 15:41:19 CET
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer
neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden:
"Clone This Bug"