Univention Bugzilla – Bug 21383
Windows 7 Ultimate lässt sich virtualisiert in UVMM nicht herunterfahren
Last modified: 2011-04-04 15:47:35 CEST
In der UVMM-Demoumgebung über ucscompany lässt sich eine erstellte Windows 7 Ultimate Installation nicht aus Windows heraus herunterfahren. Es kommt ein Bluescreen mit Fehlermeldung (siehe Anhang) und das System startet neu. Das Windows 7 System ist eine Samba4 Domäne gejoint (Vorversion der DVD vom 16. Januar). Welche Infos werden zur Fehlersuche benötigt?
Created attachment 2996 [details] Screenshot der Windows-Fehlermeldung
Xen oder Kvm? Host i386 oder amd64? Gast i386 oder amd64? Host: Ausgabe von virsh dumpxml "$VM_NAME" dpkg-query -W linux-image-`uname -r` xen-3.4 qemu-kvm \*univention-virtual-machine-manager\* dmesg Bei KVM: cat "/var/log/libvirt/qemu/$VM_NAME.log" Bei Xen: cat "/var/log/xen/qemu-dm-$VM_NAME.log"
(In reply to comment #2) > Xen oder Kvm? Voll-Virtualisierung mit KVM > Host i386 oder amd64? amd64 > Gast i386 oder amd64? i386 > Host: Ausgabe von > virsh dumpxml "$VM_NAME" Siehe Anhang samba4-win7-1_dumpxml.xml > dpkg-query -W linux-image-`uname -r` xen-3.4 qemu-kvm > \*univention-virtual-machine-manager\* linux-image-2.6.32-ucs21-amd64 2.6.32-24.21.201011241525 python-univention-virtual-machine-manager 0.9.124-2.122.201012081253 python2.4-univention-virtual-machine-manager qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 univention-virtual-machine-manager-daemon 0.9.124-2.122.201012081253 univention-virtual-machine-manager-node univention-virtual-machine-manager-node-common 0.1.18-2.21.201012071238 univention-virtual-machine-manager-node-kvm 0.1.18-2.21.201012071238 univention-virtual-machine-manager-node-xen univention-virtual-machine-manager-schema 1.0.18-1.17.201008161111 Kein Paket gefunden, das auf xen-3.4 passt. > dmesg Siehe Anhang dmesg.txt > Bei KVM: > cat "/var/log/libvirt/qemu/$VM_NAME.log" Siehe Anhang samba4-win7-1.log.1
Created attachment 3002 [details] Ausgabe dmesg auf host
Created attachment 3003 [details] Logfile für KVM Logfile samba4-win7-1.log ist leer.
Created attachment 3004 [details] virsh dumpxml der VM
Aus dem Screenshot: IRQL_NOT_LESS_OR_EQUAL 0x0000000A (0x00000000,0x000000FF,0x00000001,0x828BCD) Aus <http://www.tomstricks.com/how-to-fix-windows-stop-error-“stop-0×0000000a-or-irql_not_less_or_equal”/>: Parameter Description 1 Memory referenced 2 IRQL at time of reference 3 0: Read 1: Write 4 Address which referenced memory Schreibzugriff auf Adresse NULL. Das kann so fast alles sein, von einem kaputten Windows über einen Fehler in der ACPI-Implementierung von KVM bis hin zu irgendwas anderem. So ist das kaum zu debuggen. Bleibt eigentlich nur Abwarten und sehen, ob es auch noch bei anderen Instanzen auftritt.
Zweites Windows 7 System installiert. Gleiches Verhalten. Auch nach einem "harten" Beenden und aushängen des Installations-ISOs tritt das Problem weiterhin auf.
http://msdn.microsoft.com/en-us/library/ff560129(VS.85).aspx
Das Problem kann auch weiterhin mit der Vorab Version von UCS 2.4-2 reproduziert werden: ii libvirt-bin 0.8.7-1.54.201103141255 ii univention-virtual-machine-manager-daemon 0.9.180-1.184.201103110906 ii qemu-kvm 0.12.4+dfsg-1~bpo50+1.3.201010011432 # uname -a Linux xen13-kvm 2.6.32-ucs37-amd64 #1 SMP Fri Feb 4 00:46:18 UTC 2011 x86_64 GNU/Linux # virsh dumpxml win7-ult-stefan <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>win7-ult-stefan</name> <uuid>62b38b6d-7229-c59a-901e-4f6c1ecde96a</uuid> <memory>786432</memory> <currentMemory>786432</currentMemory> <vcpu>1</vcpu> <os> <type arch='i686' machine='pc-0.12'>hvm</type> <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/bin/kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/mnt/xen13/win7-ult-stefan-0.qcow2'/> <target dev='hda' bus='ide'/> <address type='drive' controller='0' bus='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/xen13/win_7_ult_32bit.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' unit='1'/> </disk> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <interface type='bridge'> <mac address='52:54:00:ea:6a:eb'/> <source bridge='eth0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' listen='0.0.0.0' keymap='de'/> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </memballoon> </devices> </domain>
Das Problem tritt nur dann aufzutreten, wenn kvm mit der Option "-cpu qemu32" gestartet wird. Wir sollten auch bei 32 Bit Profilen keine 32 Bit Prozessoren emulieren, sondern einfach die Option weglassen. Siehe auch Bug #19120, vielleicht sollten wir das Architektur Feld ganz entfernen.
(In reply to comment #11) > Das Problem tritt nur dann aufzutreten, wenn kvm mit der Option "-cpu qemu32" > gestartet wird. > > Wir sollten auch bei 32 Bit Profilen keine 32 Bit Prozessoren emulieren, > sondern einfach die Option weglassen. > > Siehe auch Bug #19120, vielleicht sollten wir das Architektur Feld ganz > entfernen. Vorschlag: - wir führen bei den Profilen neben 32bit und 64bit einen weiteren Wert ein, Host Architektur - im Update ändern wir die 32bit Profile auf den Wert Host Archtiektur - beim Hinzufügen eines Profils mit Host-Architektur wird dann auf einem amd64 System auch eine 64bit VM angelegt, auf einem i386 System entsprechend eine 32bit VM - das Feld Architektur belassen wir in den UVMM Einstellungen
Das ist jetzt so umgesetzt. \item In den UVMM Profilen kann die Architektur jetzt auch auf \ucsName{automatic} gesetzt werden. Dadurch wird immer die Hardware des physikalischen Servers auch der virtuellen Maschine angeboten und auf einem 64 Bit System muss nicht mehr eine 32 Bit CPU emuliert werden. Das kann bei Windows"=Betriebssystemen zu Problemen führen. In diesem Fall kann aber weiterhin auch ein 32 Bit Betriebssystem installiert werden. Alle Standard"=Profile werden während des Updates aktualisiert, sofern nicht die \ucsUCRV{uvmm/profile/autoupdate} vor dem Update auf \ucsName{false} gesetzt wird (\ucsBug{21383}.
Das Problem tritt nun nicht mehr auf, wenn die 32Bit Instanz als "64Bit Maschine" läuft - Windows 7 32Bit lässt sich ohne Bluescreen auf einem 64Bit Host herunterfahren. Die Anpassungen im Profil werden bei einem Update durchgeführt und für den Fall "Automatic" wird nun die Hostarchitektur angenommen. Im Changelog wurde ein Typo behoben - 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".