Suspend und Resume von virtuellen Maschinen sollte von UVMM unterstützt werden. Im ersten Schritt reicht es aus, wenn es pro Machine nur einen Snapshot gibt.
Die libvirt-Funktionen werden folgendermaßen auf die xen-Funktionen abgebildet: libvirt: xen: suspens() pause() resume() unpause() save(fn) save(filename) restore(fn) restore(filename) Zusätzlich kennt xen auch noch selbst ein suspend() und resume() für Xend-Managed-Domains, bei denen kein expliziter Pfadname angegeben wird. Solche suspendierten Domains werden unter /var/lib/xend/domains/$UUID/ gespeichert und auch von dort geladen. Intern haben solche suspendierten Domains den Status 3 ("xm list -a" -> /domain/status). libvirt unterstützt diese Funktionalität allerdings nicht.
Das schieben wir zunächst.
(In reply to comment #0) > Suspend und Resume von virtuellen Maschinen sollte von UVMM unterstützt werden. > Im ersten Schritt reicht es aus, wenn es pro Machine nur einen Snapshot gibt. Dafür gibt es einen neuen Bug #19575
(In reply to comment #1) > Zusätzlich kennt xen auch noch selbst ein suspend() und resume() für > Xend-Managed-Domains, bei denen kein expliziter Pfadname angegeben wird. Solche > suspendierten Domains werden unter /var/lib/xend/domains/$UUID/ gespeichert und > auch von dort geladen. Intern haben solche suspendierten Domains den Status 3 > ("xm list -a" -> /domain/status). > libvirt unterstützt diese Funktionalität allerdings nicht. Inzwischen gibt es ein 'managedsave', daß den Zustand der VM in einer eindeutig benannten Datei speichert: <https://www.redhat.com/archives/libvir-list/2010-October/msg00984.html>
Suspendieren (speichern des Zustand auf der Platte) ist nun mit KVM möglich. Per "Suspendieren" kann der Zustand der VM gesichert werden, erneutes Starten erfolgt über das normale "Starten". Xen würde Suspendieren prinzipiell auch können (siehe Comment 1), allerdings spricht libvirt noch über das HTTP-Streaming-Protokoll (xend-http-server, xend-unix-server) mit dem Xend, in dem dieses Funktionalität nicht implementiert ist. Erst ab dem XMLRPC-Protokoll (xend-unix-xmlrpc-server, xend-tcp-xmlrpc-server) bzw. über die XenAPI (xen-api-server) ist diese neue Funktion ansprechbar. Für libvirt existiert auch der Anfang einer XenAPI-nutzenden Implementierung, jedoch basiert diese aus C-Bibliothek "libxenserver" aus dem XenServer-SDK <http://community.citrix.com/cdn/xs/sdks>; diese ist nicht in Debian paketiert, diff ist aber vorhanden. Diese bezieht sich allerdings vorwiegend auf den XenServer (Stichwort: Car), das den Xen-Hypervisor als "Engine" verwendet. Viele der Funktionen tun deswegen deswegen mit einem nur-Xen-Hypervisor-System nicht. Die Implemeniertung wurde deswegen erstmal abgebrochen. svn20646, univention-virtual-machine-manager-daemon_0.10.4-7.99.201011011555
Created attachment 2783 [details] libxenserver Paketierung
Created attachment 2784 [details] managedSuspend-Support für Xen in libvirt Der Patch klinkt sich in die xenUnified-Implementierung ein, die noch auf der Streaming-API basiert, welche suspend() und resume() nicht unterstützt. Von daher muß hier entweder das im Xend implementiert werden, oder das ganze aus die XenAPI umgestellt werden.
In 2.4-1 übernommen. Wir derzeit (noch) nicht von Xen unterstützt: Bug #20573 svn 21108+21113, univention-virtual-machine-manager-daemon_0.11.0-1 ChangeLog: \item KVM-Maschinen lassen sich nun suspendieren (\ucsBug{19172}).
Suspendieren finde ich unpassend, das wird als direkte Übersetzung so nicht verwendet. Es ist für den Benutzer auf Anhieb nicht klar, was der Unterschied zwischen Pausieren und Suspendieren ist. Unter Windows und MacOS heisst das Äquivalent "Ruhezustand" oder "Ruhemodus", ich denke der Button sollte am besten "Ruhemodus (Suspend to Disk)" heissen, das verbindet den allgemeinen Begriff und den Fachbegriff.
Bei meinen Tests ist mir mehrfach aufgefallen, daß das Starten einer "suspendierten" Maschine sehr schnell geht (verglichen mit dem sichern), sie danach aber nicht mehr funktioniert: * Man kann zwar anschließend ein VNC-Fenster öffnen, allerdings steht die Maschine. * libvirt zeit sie als laufend an. * Der Zustand aus /var/lib/libvirt/qemu/save/ war danach gelöscht. Aus der /var/log/libvirt/qemu/ucs24-71.log: LC_ALL=C PATH=/sbin:/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name ucs24-71 -uuid 441cd36a-4fc8-d55b-fa0f-1b728c41f9f0 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/ucs24-71.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot cd -drive file=/var/lib/libvirt/images/ucs24-71-0.qcow2,if=none,id=drive-ide0-0-0,boot=on,format=qcow2 -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/var/lib/libvirt/images/ucs_2.4-0-100829-dvd-i386.iso,if=none,media=cdrom,id=drive-ide0-0-1,readonly=on,format=raw -device ide-drive,bus=ide.0,unit=1,drive=drive-ide0-0-1,id=ide0-0-1 -device rl8139,vlan=0,id=net0,mac=52:54:00:62:af:1d,bus=pci.0,addr=0x3 -net tap,fd=22,vlan=0,name=hostnet0 -usb -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -k de -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 0+0 records in 0+0 records out 0 bytes (0 B) copied, 8.852e-06 s, 0.0 kB/s 10+12815 records in 10+12815 records out 492550511 bytes (493 MB) copied, 112.802 s, 4.4 MB/s Beim anschließenden Starten(=Resume) wird zusätzlich die Option -incoming exec:cat hinzugefügt. Anscheinend funktioniert da aber was nicht.
(In reply to comment #9) Den Konflikt in den Begriffen Pausieren/Suspendieren sehe ich auch, das ist nicht direkt klar. Ich würde aber begrifflich nicht auf die ACPI-Modi des Betriebssystems verweisen, da die dann ggf. erwartet werden (der Suspend to RAM des Betriebssystems kann auch per ACPI-Event/Tastendruck getriggert werden, der Anwender könnte erwarten dass das hier passiert). (In reply to comment #10) mhm, sollte man den Bug dann nicht wieder öffnen?
(In reply to comment #10) > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 8.852e-06 s, 0.0 kB/s > 10+12815 records in > 10+12815 records out > 492550511 bytes (493 MB) copied, 112.802 s, 4.4 MB/s Das ist normal: libvirt generiert eine eine Sicherungsdatei, die aus 2 Teilen besteht: Erst ein 4KiB-Header (in dem u.a. die XML-Beschreibung steht), danach das Qemu-Image. > Beim anschließenden Starten(=Resume) wird zusätzlich die Option > -incoming exec:cat > hinzugefügt. Anscheinend funktioniert da aber was nicht. Nach weiteren Tests funktioniert das prinzipiell schon, denn das Wiederherstellen funktioniert in einigen Fällen: Während seiner Installation von CD konnte die VM mehrfach suspendiert werden, erst später trat dann der Fehler wieder auf. Ein "strace -f -ff -p $(pidof libvirtd)" hat auch gezeigt, daß alles funktionieren sollte.
Unter KVM funktioniert es, in Xen wird es nicht angeboten.
UCS 2.4-1 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".