Univention Bugzilla – Bug 21397
Sauberes herunterfahren von VMs per ACPI poweroff
Last modified: 2013-06-13 14:37:49 CEST
Derzeit bietet UVMM nur die Möglichkeit, einer VM den virtuellen Netzstecker zu ziehen. Läuft in der UCS-VM der acpid und sind die passenden Skripte in /etc/acpi/events hinterlegt, kann die VM per "virsh shutdown $VM" zu einem ordentlichen Herunterfahren veranlasst werden. # cat /etc/acpi/events/powerbtn-acpi-support event=button[ /]power action=/etc/acpi/powerbtn-acpi-support.sh # cat /etc/acpi/powerbtn-acpi-support.sh #!/bin/sh exec /sbin/shutdown -h -P now "Power button pressed" # /etc/init.d/acpid reload # acpi_listen button/power PBTN 00000080 00000000 Broadcast message from root@mas89 (Tue Feb 1 13:59:47 2011): Power button pressed The system is going down for system halt NOW! Für Windows ist ähnliches möglich, ggf. funktioniert das dort out-of-the-box bzw. realisieren das die GPL-PV-Treiber.
Das ist auch für unsere Demo Umgebung interessant.
Workaround funktioniert. Bzgl. Windows: Zumindest unter Windows7 mit VirtualBox muss man darauf achten, dass die Energiespareinstellung für das Drücken des Powerbuttons einen Shutdown auslöst. Wird sich unter UVMM wahrscheinlich ähnlich verhalten.
*** Bug 28938 has been marked as a duplicate of this bug. ***
ucs-3.1-2: univention-virtual-machine-manager-daemon_2.0.40-1.444.201305262039 svn40824...40826 \item Shutting down virtual machines using 'ACPI power off' was added (\ucsBug{21397}).
errata3.1-1: Backport: svn40866..40890 univention-virtual-machine-manager-daemon_2.0.36-7.445.201305271400 univention-xen_4.0.0-4.66.201305271359 xen-4.1_4.1.3-9+1.34.201305271402 yaml: r40895 ucs-3.1-1/doc/errata/2013-05-27-univention-virtual-machine-manager-daemon.yaml ucs-3.1-1/doc/errata/2013-05-27-univention-xen.yaml ucs-3.1-1/doc/errata/2013-05-27-xen-4.1.yaml
1. Bitte einen Dialog einbauen der immer Vor dem runterfahren angezeigt wird und nachfragt, ob der Rechner wirklich runtergefahren werden soll 2. Die Warnung, bzw. der Text daraus, kann dann möglicherweise in den anderen Dialog übernommen werden und dann die Warnung entfernen (vielleicht nochmal mit stefan absprechen) 3. Der Text in der Warnung Das Herunterfahren virtueller Maschinen benötigt die Kooperation der Gastbetriebssysteme. Für UCS Die Pakete "acpid" und "acpi-support-base" müssen installiert sein Für Windows ACPI muß aktiviert sein Wenn das Betriebssystem nicht kooperiert kann "Beenden" benutzt serden, um die virtuelle Maschine zwangsweise auszuschalten. 3.1 -> apt-get install acpi-support-base E: Paket »acpi-support-base« hat keinen Installationskandidaten 3.2 serden => werden 3.3 Statt Für UCS\nDie Pakete ... und Für Windows\n ACPI, fände ich besser: Das Herunter.... Unter Linux müssen die Pakete "acpid" und "acpi-support-base" (??, siehe 3.1) installiert und konfiguriert sein. Unter Windows muß ACPI aktiviert sein. Davon abgesehen hat es mit amd64 XEN UCS 3.1 (dom0) und amd64 UCS 3.1 (domU) funktioniert.
(In reply to comment #6) > 3.1 > -> apt-get install acpi-support-base > E: Paket »acpi-support-base« hat keinen Installationskandidaten That is Bug #31401
Beim Beenden bekomme ich gerade immer Die Anfrage konnte nicht ausgeführt werden. Fehlernachricht des Servers: Eine Option für domain_state hat den falschen Typ: Invalid domain state: SHUTOFF
(In reply to comment #7) > (In reply to comment #6) > > 3.1 > > -> apt-get install acpi-support-base > > E: Paket »acpi-support-base« hat keinen Installationskandidaten > > That is Bug #31401 ok, but we shouldn't mention a non-existing package, or?
(In reply to comment #6) > 1. Bitte einen Dialog einbauen der immer Vor dem runterfahren angezeigt wird > und nachfragt, ob der Rechner wirklich runtergefahren werden soll Der Dialog wird nun standardmäßig solange angezeigt, bis der Benutzer die CheckBox betätigt und den Dialog abschaltet. Die Einstellung wird in seinen persönlichem UMC-Einstellungen (UMC → Benutzer → Erweitere Einstellungen → UMC Einstellungen → uvmmShutdownSeen) gespeichert. Damit kann jeder Benutzer selber entscheiden, wie mündig er ist und wie sehr er von UMC genervt werden möchte. (Standardmäßig reagiert weder ein Windows noch ein UCS auf den Shutdown, von daher ist der saubere Shutdown lang nicht so schlimm wie ein unsauberes Stopp.) > 2. Die Warnung, bzw. der Text daraus, kann dann möglicherweise in den anderen > Dialog übernommen werden und dann die Warnung entfernen (vielleicht nochmal mit stefan absprechen) Entfällt damit. > 3. Der Text in der Warnung > 3.2 > serden => werden korrigiert. > 3.3 > Statt "..." fände ich besser: "..." Der Text wurde nochmals gründlich überarbeitet und dabei der Vorschlag umgesetzt. Der Button ist nun auch mit "Shutdown" beschriftet. "Cancel" hat übrigend nicht funktioniert und die VM trotzdem heruntergefahren; das wurde korrigiert. (In reply to comment #8) > Beim Beenden bekomme ich gerade immer > Invalid domain state: SHUTOFF Wurde hinzugefügt: svn41060 (In reply to comment #9) > ok, but we shouldn't mention a non-existing package, or? Die Pakete existiert derzeit leider nur in unmaintained. Man könnte zwar einen Hinweis auf unmaintained einfügen, aber dann stellt sich als nächstes die Frage, warum wie Pakete aus unmaintained empfehlen. Zudem ist auch nicht ausführlich aufgeführt, wie man in den verschiedenen Windows-Versionen jeweils ACPI aktiviert. Das sollte ggf. mal im Handbuch (oder sonstwo) dokumentiert werden. Stefan und ich waren der Meinung, daß eine standardmäßige Installation der Pakete eine nicht ungefährliche Änderungen ist, die wir nicht in einem Erratum machen wollen, sondern erst zu UCS-3.1-2 bzw. UCS-3.2 (es gibt gute Gründe dafür, einen Server nicht per Power-Knopf herunterfahren zu können). Die Möglichkeit des Herunterfahrens ist derzeit vorallem für Windows interessant und wurde nur deswegen als Erratum umgesetzt. Für UCS würden dann noch zwei Pakete (acpid, acpi-support) im Errata-Scope importiert, gebaut und bereitgestellt werden müssen, was dieses Erratum noch mehr verkompliziert. (das liegt vor allem daran, weil wir pro erratum nur ein Quellpaket angeben können: Bug #26836) Wenn das gewünscht ist, wären nachfolgend die beiden YAML-Dateien dafür (dankenswerterweise kann sich announce_errata inzwischen aus jedem beliebigen Scope die Pakete ziehen, was ein Neuübersetzten der Pakete erübrigt. Das sollte aber IMHO nicht gemacht werden, bevor nicht auch die Pakete in die Trigge-Liste für UCS-3.1-2 bzw UCS-3.2 aufgenommen wurden, was definitiv dann zu Bug #31401 gehört) $ cat 2013-05-27-acpi-support.yaml product: ucs release: "3.1" scope: ucs_3.0-0 src: acpi-support fix: 0.137-5.4.201104132204 note: version: [1] desc: | The sole purpose of this erratum is to provide "acpi-support" as a maintained package, which is needed to cleanly shutdown UCS running in a virtual machine. bug: [21397, 31401] $ cat 2013-05-27-acpi.yaml product: ucs release: "3.1" scope: ucs_3.0-0 src: acpid fix: 1.5-2.8.201104132123 note: version: [1] desc: | The sole purpose of this erratum is to provide "acpid" as a maintained package, which is needed to cleanly shutdown UCS running in a virtual machine. bug: [21397, 31401] Jede weitere (politische) Diskussion gehört meiner Meinung nach an Bug #31401. Package: univention-virtual-machine-manager-daemon Svn: 41055, 41060 Version: 2.0.40-4.448.201305291922 Scope: ucs3.1-2 Package: univention-virtual-machine-manager-daemon Version: 2.0.36-9.449.201305291922 Scope: errata3.1-1 Yaml: svn 41058, 41061
Bitte statt "Für UCS müssen die Pakete "acpid" und "acpi-support-base" installiert sein." "Für Linux müssen ..." Dann ist es allgemeiner gehalten und das Problem mit dem fehlendem "acpi-support-base" auch nicht mehr so dringlich.
getestet mit ucs3.1-2 Ich habe hier eine PV (bzw . ein HVM) UCS Instanz ohne acpi Pakete. Bei "Herunterfahren" im UVMM wird der Rechner auch ordentlich heruntergefahren. Das ist ja eigentlich gut, aber wieso funktioniert das ohne acpi Pakete? Bei einem WinXP habe ich jetzt nichts konfiguriert (plain installation) und es sieht so aus als würde der Rechner bei "Herunterfahren" direkt ausgeschaltet. Die VNC Verbindung ist jedenfalls sofort tot beim Klick auf "Herunterfahren" und im UVMM wird der Rechner sofort als aus angezeigt. Ich bin mir aber nicht ganz sicher, da beim Windows sich beim Restart nicht über unsauberes Herunterfahren beschwert hat.
(In reply to Felix Botner from comment #11) > Bitte statt "Für UCS ..." → "Für Linux ..." svn41143 Für ACPI muß ggf. folgender Registry-Eintrag gesetzt werden: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Shutdownwithoutlogon=1 (In reply to Felix Botner from comment #12) > Ich habe hier eine PV (bzw . ein HVM) UCS Instanz ohne acpi Pakete. Bei > "Herunterfahren" im UVMM wird der Rechner auch ordentlich heruntergefahren. > Das ist ja eigentlich gut, aber wieso funktioniert das ohne acpi Pakete? Bei Xen ist wieder alles anders: Xen implementiert kein ACPI event, sondern ... TADA .. seinen eigenen Mechanismus. Dort erkennt unser UCS-Kernel automatisch, daß er in einer Xen-VM läuft und aktiviert selbständig den Xen-Shutdown-Mechanismus (der hat nicht mit ACPI zu tun, sondern ist eigenständig) > Bei einem WinXP habe ich jetzt nichts konfiguriert (plain installation) und > es sieht so aus als würde der Rechner bei "Herunterfahren" direkt > ausgeschaltet. Die VNC Verbindung ist jedenfalls sofort tot beim Klick auf > "Herunterfahren" und im UVMM wird der Rechner sofort als aus angezeigt. Ich > bin mir aber nicht ganz sicher, da beim Windows sich beim Restart nicht über > unsauberes Herunterfahren beschwert hat. Bei Windows wird bei der Installation der GPLPV-Treiber auch der sog. "Shutdown-Monitor" mitinstalliert, der eine ähnliche Funktion wie der acpid übernimmt, nur eben auch hier wieder über den eigenen Xen-spezifischen Kanal. Es gibt Bericht darüber, daß dieser nicht richtig installiert und als Dienst gestartet wird; das kann von Hand korrigiert werden: (Windows 7) "cmd.exe" → Run as Administrator cd "\Program Files (x86)\Xen PV Drivers\bin" shutdownmon.exe -i Zu allem Überfluss probiert Xend zu erkennen, ob die Xen-PV-Treiber verwendet werden. Fall nicht, wird die VM einfach ausgeschaltet: xend/XendDomainInfo.py:535 # HVM domain shuts itself down only if it has PV drivers if self.info.is_hvm(): hvm_pvdrv = xc.hvm_get_param(self.domid, HVM_PARAM_CALLBACK_IRQ) hvm_s_state = xc.hvm_get_param(self.domid, HVM_PARAM_ACPI_S_STATE) if not hvm_pvdrv or hvm_s_state != 0: code = REVERSE_DOMAIN_SHUTDOWN_REASONS[reason] log.info("HVM save:remote shutdown dom %d!", self.domid) xc.domain_shutdown(self.domid, code)
Die Texte wurde nochmals überarbeitet: svn41188 errata3.1-1: 2.0.36-10.450.201306041745 yaml: svn41189 ucs-3.2-0: 2.0.40-5.451.201306041748
FAIL - YAML grep 21397 2013-05-27-univention-virtual-machine-manager-daemon.yaml FAIL - changelog wieso steht das nur in der XEN Sektion, das gilt doch auch für KVM OK - Rest funktioniert errata3.1-1 3.2-0 XEN UCS PV OK OK Win7 PV (+shutdown monitor) OK OK WinXP PV OK OK KVM UCS (+acpi) OK OK Win7 PV OK OK WinXP PV OK OK
(In reply to Felix Botner from comment #15) > FAIL - YAML > grep 21397 2013-05-27-univention-virtual-machine-manager-daemon.yaml -bug: [30897, 30897] +bug: [21397, 23394, 30897] > FAIL - changelog > wieso steht das nur in der XEN Sektion, das gilt doch auch für KVM Verschoben nach UVMM Fixed svn41253
OK
http://errata.univention.de/ucs/3.1/125.html