Auf Rechner A wird DVS Instanz "i1" angelegt. Dieser Rechner fällt aus und nun wird diese Instanz , ebenfalls als "i1" auf Rechner B angelegt. Nach dem Neustart vom Rechner A gibt es dort aber weiterhin die Instanz "i1" in libvirt: -> virsh list --all Unter Umständen (wenn z.B. durch einen Ausfall von Rechner B die Instanz wieder auf Rechner A umgezogen wird) kann es damit Probleme geben, weil keine weitere Instanz mit diesem Namen auf Rechner A angelegt werden kann. Es sollte also auf dem ausgefallenem Rechner auch die libvirt Konfigurationen der Instanzen gelöscht werden.
Vielleicht reicht es hier alle Instanzen zu löschen, die ein "univentionVirtualMachineReplacedBy: 510190ce-1ca2-2e39-13cf-35314f38bf19" haben.
Ich habe jetzt einen doppelten Failover fabriziert. Dann habe ich folgende UVMM Information Objekte im LDAP: # 4c0b7254-7bef-ae72-d86f-e768ea5377ec, Information, Virtual Machine Manager, dvs10.local dn: univentionVirtualMachineUUID=4c0b7254-7bef-ae72-d86f-e768ea5377ec,cn=Infor mation,cn=Virtual Machine Manager,dc=dvs10,dc=local univentionVirtualMachineOS: Microsoft Windows XP objectClass: univentionVirtualMachine univentionVirtualMachineUUID: 4c0b7254-7bef-ae72-d86f-e768ea5377ec univentionVirtualMachineReplacedBy: 510190ce-1ca2-2e39-13cf-35314f38bf19 # 510190ce-1ca2-2e39-13cf-35314f38bf19, Information, Virtual Machine Manager, dvs10.local dn: univentionVirtualMachineUUID=510190ce-1ca2-2e39-13cf-35314f38bf19,cn=Infor mation,cn=Virtual Machine Manager,dc=dvs10,dc=local univentionVirtualMachineOS: Microsoft Windows XP objectClass: univentionVirtualMachine univentionVirtualMachineUUID: 510190ce-1ca2-2e39-13cf-35314f38bf19 # 0b4647a4-c1fe-a49e-ac58-60e6e45a4df4, Information, Virtual Machine Manager, dvs10.local dn: univentionVirtualMachineUUID=0b4647a4-c1fe-a49e-ac58-60e6e45a4df4,cn=Infor mation,cn=Virtual Machine Manager,dc=dvs10,dc=local univentionVirtualMachineOS: Microsoft Windows XP objectClass: univentionVirtualMachine univentionVirtualMachineUUID: 0b4647a4-c1fe-a49e-ac58-60e6e45a4df4 Die aktuell (laufende) Instanz ist "0b4647a4-c1fe-a49e-ac58-60e6e45a4df4", jedoch wurde an der vorherigen Instanz "510190ce-1ca2-2e39-13cf-35314f38bf19" nicht das "univentionVirtualMachineReplacedBy" gesetzt. Beim ersten Failover wurde das noch getan, siehe "4c0b7254-7bef-ae72-d86f-e768ea5377ec"
Das Template für /etc/init.d/libvirt-guests wurde im Paket univention-dvs-node entsprechend angepasst: * Während der "ON_BOOT=start" Phase der Instanzen wird nach dem LDAP-Attribut univentionVirtualMachineReplacedBy gesucht (eingeführt durch Bug 22416). * Wenn diese LDAP-Suche erfolgreich ist, wird per "virsh undefine" die ersetzte UUID in libvirt entfernt und danach im UDM das uvmm/info Objekt. Die Ursache für die Beobachtung in Comment 2 ist noch unklar, ggf. waren die Pakete auf xen12 nicht aktuell? Erstmal fixed.
Auch der dvs-suspend-replaced-vm Listener wurde so angepasst dass für die als "replacedBy" markierten VMs ein virsh destoroy und virsh undefine ausgeführt wird.
Die Instanzen auf dem ausgefallenem Rechner werden gelöscht (virsh undefine). Getestet mit "poweroff" und "ifdown eth0". Das Problem mit "univentionVirtualMachineReplacedBy" ist mir nicht nochmal auftreten.
Nochmal auf, ein paar mal (2 von ca. 10) hat das Löschen der Instanz auf dem ausgefallenem Rechner nicht geklappt. Im Listener log sieht man folgendes: 3ac2464,cn=Information,cn=Virtual Machine Manager,dc=dvs10pt,dc=local cmd: m 17.06.11 13:03:32 LISTENER ( INFO ) : updating univentionVirtualMachineUUID=e09f620c-9854-5b17-a036-0710b3ac2464,cn=Information,cn=Virtual Machine Manager,dc=dvs10pt,dc=local 17.06.11 13:03:32 LISTENER ( INFO ) : running handlers for univentionVirtualMachineUUID=e09f620c-9854-5b17-a036-0710b3ac2464,cn=Information,cn=Virtual Machine Manager,dc=dvs10pt,dc=local 17.06.11 13:03:32 LISTENER ( INFO ) : univentionVirtualMachineReplacedBy ? univentionVirtualMachineReplacedBy 17.06.11 13:04:02 LISTENER ( PROCESS ) : DVS halted replaced virtual machine "e09f620c-9854-5b17-a036-0710b3ac2464": virsh destroy output: error: Failed to destroy domain e09f620c-9854-5b17-a036-0710b3ac2464 error: Timed out during operation: cannot acquire state change lock 17.06.11 13:04:02 LISTENER ( PROCESS ) : DVS undefined replaced virtual machine "e09f620c-9854-5b17-a036-0710b3ac2464": virsh undefine output: error: Failed to undefine domain e09f620c-9854-5b17-a036-0710b3ac2464 error: Requested operation is not valid: cannot delete active domain 17.06.11 13:04:02 LISTENER ( INFO ) : handler: dvs-suspend-
(In reply to comment #6) > Nochmal auf, > > ein paar mal (2 von ca. 10) hat das Löschen der Instanz auf dem ausgefallenem > Rechner nicht geklappt. Im Listener log sieht man folgendes: Wie besprochen, bitte nochmal testen, wenn das Netzwerkkabel gezogen wird. Ich denke das ist relevanter. Wenn es sich dann nicht reproduzieren lässt, dann bitte zu dem ifup/ifdown einen neuen Bug erstellen.
svn24962: Es wurde ein fehlendes %s im Formatstring ergänzt.
Könnte ein Problem der libvirt Version 0.8.x sein. Laut https://bugzilla.redhat.com/show_bug.cgi?id=676205 ist das Verhalten in 0.9.0 verbessert, allerdings lässt sich im changelog kein konkreter Hinweis dazu finden (http://libvirt.org/news.html). Falls das weiterhin problematisch ist, kann man als Workaround im Falle dieses virsh timeouts im listener den libvirtd (/etc/init.d/univention-virtual-machine-manager-node-common) restarten, kurz warten und dann noch einmal das virsh destroy/undefine versuchen.
Tritt nicht auf, wenn ich das Netzwerkkabel ziehe, anscheinend nur bei ifdown/up eth0.
Da es grundsätzlich funktioniert, sollten wir diesen Fall zur nächsten Version beheben.
Falls virsh destroy im Listener dvs-suspend-replyced-vm nicht erfolgreich verläuft, wird uvmmd-common neu gestartet und das virsh Kommando erneut ausgeführt.
Auf einem Testsystem hängt der libvirtd, auch ein Neustart hat hier nichts gebracht: -> strace -p 3945 Process 3945 attached - interrupt to quit futex(0x426019e0, FUTEX_WAIT, 4035, NULL^C <unfinished ...> Process 3945 detached
libvritd wird jetzt wie in comment 9 beschrieben manuell per sigkill beendet und dann per Initskript restartet falls virsh destroy nicht funktioniert.
(In reply to comment #13) > Auf einem Testsystem hängt der libvirtd, auch ein Neustart hat hier nichts > gebracht: > > -> strace -p 3945 Da "libvirtd" multi-threaded ist, ist ein strace auf dem Haupt-thread wenig aussagekräftig, da dieser i.d.R. nur auf das Beenden der gestarteten anderen Threads wartet. Von daher in so einem Fall zusätzlich "-f" angeben, um alle Threads zu tracen! (In reply to comment #9) > Könnte ein Problem der libvirt Version 0.8.x sein. Laut > https://bugzilla.redhat.com/show_bug.cgi?id=676205 ist das Verhalten in 0.9.0 > verbessert, allerdings lässt sich im changelog kein konkreter Hinweis dazu > finden (http://libvirt.org/news.html). Ich vermute mal "[libvirt] [PATCH 3/6] use virObject to manage reference-count of virDomainObj" aka "[PATCH] qemu: fix a dead-lock problem", weil das genau im Fehlerfall auftritt.
Die Instanzen auf den ausgefallenen Rechner wurden nun immer gelöscht.
Da der Workaround für Comment 6 in UCS-DVS erstmal ausreicht, im Plattform-Produkt UCS aber behoben werden sollte, gibt es jetzt Bug #22789.