Description of problem: * Using libvirt/qemu/kvm on Fedora 11 x86_64 (8 process) * Two symptoms ... * a previously installed "Windows Server 2008 64-bit" machine I'll call VM_1 no longer works and bluescreens during startup (was installed under Fedora 11 libvirt/qemu) * an attempt to install a new "Windows Server 2008 64-bit" machine I'll call VM_2 does not work and bluescreens in the same way as the previously existing machine ... I'll call this VM_2 (again, attempt is with Fedora 11 libvirt/qemu) * Both these VMs were installed in past or were to be installed from Windows media listed here: [_MASTER_ root@porta01 ~]# virsh dumpxml JanelazChefe_aV1 | grep '.iso' <source file='/opt/standard_downloads/ThirdParty/Microsoft/OperatingSystems/en_windows_server_2008_datacenter_enterprise_standard_without_hyperv_x64_dvd_X14-27010.iso'/> [_MASTER_ root@porta01 ~]# * A Windows XP VM (not sure whether 32-bit or 64-bit, I believe 32-bit) did not suffer same badness after upgrade to Fedora 11's kernel/libvirt/qemu at some point Version-Release number of selected component (if applicable): [_MASTER_ root@porta01 ~]# rpm -qa | egrep "(kernel|libvirt|qemu|kvm)" | sort kernel-2.6.30.10-105.fc11.x86_64 <-- others installed, this is the one in use kernel-firmware-2.6.30.10-105.fc11.noarch libvirt-0.6.2-19.fc11.x86_64 libvirt-python-0.6.2-19.fc11.x86_64 qemu-0.10.6-9.fc11.x86_64 qemu-common-0.10.6-9.fc11.x86_64 qemu-img-0.10.6-9.fc11.x86_64 qemu-kvm-0.10.6-9.fc11.x86_64 qemu-system-m68k-0.10.6-9.fc11.x86_64 qemu-system-mips-0.10.6-9.fc11.x86_64 qemu-system-ppc-0.10.6-9.fc11.x86_64 qemu-system-sh4-0.10.6-9.fc11.x86_64 qemu-system-sparc-0.10.6-9.fc11.x86_64 qemu-system-x86-0.10.6-9.fc11.x86_64 qemu-user-0.10.6-9.fc11.x86_64 [_MASTER_ root@porta01 ~]# How reproducible: Always reproducible Steps to Reproduce: 1. Make sure above components installed 2. Make sure have previously good running Windows Server 2008 64-bit VM 3. Define new attempted Windows Server 2008 64-bit VM 4. Use hardware KVM acceleration 5. Try to start up previously good VM or run new VM 6. Get bluescreen (NOTE: sample VM definition below) Actual results: Get bluescreen with "STOP: 0x0000005C ..." message Expected results: VM's should run Additional info: === SAMPLE VIRTUAL MACHINE SPEC === [_MASTER_ root@porta01 ~]# virsh dumpxml AzosrWaipio_aV2 <!-- NOTE: using 'F12' at bootup to manually switch to CD/DVD boot instead of hard drive for case where trying to install Windows OS --> <domain type='kvm'> <name>AzosrWaipio_aV2</name> <uuid>bla bla bla</uuid> <memory>786432</memory> <currentMemory>786432</currentMemory> <vcpu>1</vcpu> <!-- NOTE: even happens in single-CPU case --> <os> <type arch='x86_64' machine='pc'>hvm</type> <boot dev='hd'/> <!-- NOTE: manually switching to DVD bootup if trying to install --> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <!-- using KVM --> <disk type='block' device='disk'> <source dev='/dev/NoRaidVolGroupC/AzosrWaipio_aV2_RootFs'/> <target dev='hda' bus='ide'/> </disk> <disk type='file' device='cdrom'> <source file='/opt/standard_downloads/ThirdParty/Microsoft/OperatingSystems/en_windows_server_2008_datacenter_enterprise_standard_without_hyperv_x64_dvd_X14-27010.iso'/> <target dev='hdc' bus='ide'/> <readonly/> </disk> <interface type='network'> <mac address='54:52:00:13:dc:61'/> <source network='azosr'/> <target dev='vnet0'/> </interface> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/> </devices> </domain> [_MASTER_ root@porta01 ~]#
Created attachment 384747 [details] virt-manager console screen showing Windows bluescreen
After further search, I found bug 549290 (BIOS update causes Vista bluescreen). Following the suggested remedy there and downgrading from bochs-bios-2.3.8-0.9.git04387139e3b.fc11.noarch to bochs-bios-2.3.8-0.6.git04387139e3b.fc11.noarch solved the immediate problem. I'm marking this a duplicate of the other bug. *** This bug has been marked as a duplicate of bug 549290 ***