Univention Bugzilla – Bug 20253
UVMM: Anpassungen an XML Domain Beschreibung beibehalten
Last modified: 2011-10-28 22:27:24 CEST
Aus Ticket#2010100410004183: > Das Setzen der Affinity wird derzeit nicht von UVMMd unterstützt: Wenn > anschließen > Einstellungen an der Domain per UVMMd verändert werden, gehen die > 'Affinity'-Einstellungen wieder verloren und müssen wieder direkt per > "virsh edit" gesetzt werden UVMM sollte dahingehend geändert werden, daß solche händisch gemachten Anpassungen nach Möglichkeit nicht überschrieben werden. Derzeit generiert der UVMM jedes mal die komplette XML-Beschreibung neu. Da nicht alle Einstellungen an das UMC-Modul bzw. CLI-Tool übertragen werden, gehen alle nicht explizit vorhandenen Einstellungen verloren. Ggf. ist es hier machbar, bei Änderungen die existierende Beschreibung einzulesen und die Änderungen darauf durchzuführen.
*** Bug 21395 has been marked as a duplicate of this bug. ***
libvirt wurde jetzt so gepatched, daß bei Qemu-Instanzen die komplette XML-Domain-Beschreibung innerhalb der Snapshot-Datei unter /var/lib/libvirt/qemu/snapshot/$VM/$SNAPSHOT.xml abgespeichert wird. Beim Wiederherstellen eines Snapshots wird der alte KVM-Prozeß derzeit immer beendet und ein neuer KVM-Prozeß mit den gespeicherten Einstellungen gestartet. Dadurch ist es jetzt leider das Umschalten zwischen nicht-umkonfigurierten VMs nicht mehr ganz so schnell. Dafür müsste jede Einstellung gesondert darauf untersucht werden, was loadvm/savevm kaputt macht und welche geändert werden können. Was noch fehlt: - Anpassungen am UMV rückgängig machen, so daß Snapshots wieder veränderbar sind. Zum Testen: 1. Sind alte Snapshots noch ladbar (nur /domainsnapshot/domain/uuid statt vollständiger XML-Beschreibung) 2. Laufende VM → ausgeschalteter VM 3. Ausgeschaltete VM → laufende VM 4. Änderung an der Beschreibung, insbesonderen Speichergröße, CPU-Anzahl, Device-Konfiguration svn8989, libvirt_0.8.7-1.63.201103212001
(In reply to comment #2) > libvirt wurde jetzt so gepatched, daß bei Qemu-Instanzen die komplette... Falscher Bug, da gehört nach Bug #21636
univention/uvmm/node.py#domain_define() wurde so umgeschrieben, daß von Hand gemachte Änderungen an den libvirt-Domain-XML-Dateien beibehalten werden. Das ist nicht für alle Einstellungen möglich, da gewisse Dinge (MAC-Adresse, Block-Device-Busbezeichner) als Schlüssel zum Wiedererkennen der Element verwendet werden: Ändern sich diese zusätzlich zu anderen Einstellungen, so wird das gehandhabt wie das Entfernen des alten Eintrags und das Hinzufügen eines neuen Eintrags. Alle ggf. von Hand gemachten Änderung an solch einem Element und all seiner Kindknoten in der XML-Beschreibung gehen dadurch verloren. Kritisch ist auch das Ändern von Typen, z.B. von einer Bridged-Netzwerkkarte zu einer NATtenden Netzwerkkarte, oder von VNC zu SDL, weil diese dann ganz andere Kindelemente und Attribute erwarten. Getestet werden kann das ganze folgendermaßen: 1. Instanz per UMC oder "virsh define" anlegen 2. Per "virsh edit $VM" Einstellungen an der Instanz ändern 3. Per "virsh dumpxml $VM > orig" das Original sichern. 4. Die Instanz in UMC neu auswählen und dort Änderungen vornehmen; Speichern nicht vergessen. 5. Per "virsh dumpxml $VM | diff orig -" sich die Änderungen anzeigen lassen. Unter <http://libvirt.org/formatdomain.html> findet man die Beschreibung, was alles in der Domain-XML-Beschreibung stehen kann, trotzdem ist nicht alles davon möglich. Sinnvoll sind z.B. folgende Einstellungen: <domain>...<vcpu cpuset='1-2'>2</vcpu>...</domain> <domain>...<cpu match='minimum'><model>Opteron_G3</model><vendor>AMD</vendor><topology sockets='1' cores='2' threads='1'/></cpu>...</domain> <domain>...<devices>...<console type='pty'><target port='0'/></console>...</devices>...</domain> <domain>...<devices>...<watchdog model='i6300esb' action='reset'/>...</devices>...</domain> <domain>...<devices>...<hostdev mode='subsystem' type='pci' managed='yes'><source><address domain='0x0000' bus='0x00' slot='0x07' function='0x0'/></source></hostdev>...</devices>...</domain> svn23137, univention-virtual-machine-manager-daemon_0.9.197-1.206.201103231455 ChangeLog: \item Bei der Konfiguration einer virtuellen Instanz über das UMC-Modul des UVMM werden nun per \ucsCommand{virsh edit} gemachte Änderungen nicht mehr überschrieben (\ucsBug{20253}). PCI-Passthrough tut noch nicht, folgendes sollte aber ein Schritt in die richtige Richtung sein: echo 0000:00:07.0 > /sys/devices/pci0000\:00/0000\:00\:07.0/driver/unbind modprobe pci-stub cat /sys/devices/pci0000\:00/0000\:00\:07.0/{vendor,device} | fmt > /sys/bus/pci/drivers/pci-stub/new_id echo 0000:00:07.0 >/sys/bus/pci/drivers/pci-stub/bind
(In reply to comment #4) > <domain>...<devices>...<hostdev mode='subsystem' type='pci' > managed='yes'><source><address domain='0x0000' bus='0x00' slot='0x07' > function='0x0'/></source></hostdev>...</devices>...</domain> Da ggf. managed='no'. > PCI-Passthrough tut noch nicht, folgendes sollte aber ein Schritt in die > richtige Richtung sein: Auf den neueren xen12-xen16 sollte das auch funktionieren, da erst diese die notwendige Hardwareunterstützung (IOMMU) haben. Siehe auch <http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM> Scheint aber ggf. noch kein Kernel-Bug zu sein: <http://www.spinics.net/lists/kvm/msg50999.html>
Beim Ändern der Speichergröße wird nun auch currentMemory auf den neuen Wert aktualisiert, da ansonsten die VM weiterhin mit dem durch Ballooning reduzierten Speicherplatz arbeitet. svn23184, univention-virtual-machine-manager-daemon_0.9.204-1.214.201103281129 Keine weitere Änderung am ChangeLog-Eintrag
Die Anpassungen konnten erfolgreich getestet werden: Manuelle Anpassungen an der XML-Datei werden nun nicht mehr von UVMM überschrieben. Getestet werden konnte dies unter anderem mit Anpassungen am Speicher (inl. currentMemory), den Laufwerken, und der CPU sowie mit Erweiterungen, die UVMM nicht "kennt", wie z.B. das Einbinden eines USB-Sticks via Passthrough, oder dem Setzen der denkbaren CPU Einstellungen (http://libvirt.org/formatdomain.html#elementsCPU). Die Einstellungen wurden allesamt nicht von UVMM gelöscht/überschrieben - auch nicht bei Änderungen der Maschine via UVMM. Es gibt diverse Fälle, in denen libvirt selbst Zeilen wiederherstellt, wie z.B. das Ballooning Device (muss mittel model=none deaktiviert werden!). Da diesem aber kein Zusammenspiel mit UVMM zugrundeliegt und es imho in allen Fällen auch notwendig ist um einer Zerstörung der Maschinenkonfiguration vorzubeugen, ist das an diesem Bug nicht relevant. Changelogeintrag ist vorhanden - verified!
Vermutlich führen die Anpassungen an dieser Stelle dazu, dass Windowsinstanzen mit GLPV-Treibern "tap" statt "tap2" Devices bekommen. Das führt dann zu Bug#22017
Ich vermute mal, daß nach der Windows-Installation die Boot-Reihenfolge verändert wird. Dabei steht in der UMC natürlich noch die Laufzeitdaten (mit driver/@name="tap") zur Verfügung, die durch das Ändern der Boot-Reihenfolge zurückgeschreiben werden und das dann richtige driver/@name="tap2" in der XML-beschreibung überschreiben. Von daher ist eigentlich nicht dieser Bug schult, sondert die Tatsache, das Xen für laufende Domains fälschlicherweise "tap" liefert, obwohl "tap2" verwendet wird. (bzw. ggf. libvirt, was das falsch übersetzt).
Wieder zu, das wird über einen Patch in libvirt durch Bug #22017 gelöst.
(In reply to comment #10) > Wieder zu, das wird über einen Patch in libvirt durch Bug #22017 gelöst. verified
UCS 2.4-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".