[libvirt-users] F14->F16 Upgrade Results in Win2003 Server Client BSOD 0x7f
Hello, I upgraded my kvm server from Fedora 14 to Fedora 16 and the only casualty was a Windows 2003 Server client that will no longer boot with and produces a BSOD. I admittedly know very little about Windows and this VM has been around - real hardware -> Parallels on a Mac -> linux kvm but it was working fine under Fedora 14. The client does boot fine under safe mode but anything higher than that (even safe mode with networking) results in the BSOD. I've tried explicitly setting the network driver to rtl8139 in virt-manager which appears to be what it was under F14 but it didn't help. Neither did just removing the NIC under Device Manager and letting it get recognized again. As you can guess given the description, this crusty old Win2003 server instance has some worth in that recreating it is very undesirable for all involved. I'd appreciate any tips on getting it working again. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb@unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | =======================================================================
On 05/09/2012 08:11 AM, Thomas J. Baker wrote:
Hello,
I upgraded my kvm server from Fedora 14 to Fedora 16 and the only casualty was a Windows 2003 Server client that will no longer boot with and produces a BSOD. I admittedly know very little about Windows and this VM has been around - real hardware -> Parallels on a Mac -> linux kvm but it was working fine under Fedora 14. The client does boot fine under safe mode but anything higher than that (even safe mode with networking) results in the BSOD. I've tried explicitly setting the network driver to rtl8139 in virt-manager which appears to be what it was under F14 but it didn't help. Neither did just removing the NIC under Device Manager and letting it get recognized again.
As you can guess given the description, this crusty old Win2003 server instance has some worth in that recreating it is very undesirable for all involved. I'd appreciate any tips on getting it working again.
(I apologize in advance for all the confusion caused by qemu hardware machine type vs. Fedora release number :-/). Was the KVM version of this guest perhaps created on a Fedora 13 server? If so, it may have been using the QEMU machine type "fedora-13", which was created during the lifecycle of Fedora 13 (in order to add support for some bit of hardware that wasn't supported by qemu at F13 release). That qemu machine type was deprecated, but still usable, in Fedora 14 (where qemu treated it equivalent to the "pc-0.13" machine type). (In Fedora 15, the "fedora-13" machine type was inadvertently made into a synonym for "pc-0.14" rather than "pc-0.13".) In Fedora 16, the "fedora-13" machine type is still treated as a synonym for "pc-0.14" by qemu, but libvirt automatically translates all occurrences of "fedora-13" in a guest's configuration to "pc-0.14" so that it doesn't rely on this qemu behavior. This is done because Fedora 17's qemu will completely remove support for the "fedora-13" machine type. The result of all this confusion is that anyone upgrading from Fedora 15 to Fedora 16 will have their "fedora-13" machine type translated into exactly the same machine type they've been effectively using anyway. But, in the case of upgrading directly from F14 to F16, pre-upgrade the guest will have been running inside a qemu "pc-0.13" machine type, and after the upgrade it will be running inside a qemu "pc-0.14" machine type. I really don't have any idea about the details in difference between these two machine types or whether it's enough of a difference to cause a BSOD, but on the off chance this could be the source of your problem, you can try this: Edit the configuration of your guest and look for a line like this: <type arch='x86_64' machine='pc-0.14'>hvm</type> Change 'pc-0.14' to 'pc-0.13' and save the config, then try starting your guest. (If the machine type is already 'pc-0.13', then this isn't your problem). If that doesn't help, possibly you could get better help if you included your guest's domain config and the information from the BSOD.
On May 17, 2012, at 3:04 PM, Laine Stump wrote:
On 05/09/2012 08:11 AM, Thomas J. Baker wrote:
Hello,
I upgraded my kvm server from Fedora 14 to Fedora 16 and the only casualty was a Windows 2003 Server client that will no longer boot with and produces a BSOD. I admittedly know very little about Windows and this VM has been around - real hardware -> Parallels on a Mac -> linux kvm but it was working fine under Fedora 14. The client does boot fine under safe mode but anything higher than that (even safe mode with networking) results in the BSOD. I've tried explicitly setting the network driver to rtl8139 in virt-manager which appears to be what it was under F14 but it didn't help. Neither did just removing the NIC under Device Manager and letting it get recognized again.
As you can guess given the description, this crusty old Win2003 server instance has some worth in that recreating it is very undesirable for all involved. I'd appreciate any tips on getting it working again.
(I apologize in advance for all the confusion caused by qemu hardware machine type vs. Fedora release number :-/).
Was the KVM version of this guest perhaps created on a Fedora 13 server? If so, it may have been using the QEMU machine type "fedora-13", which was created during the lifecycle of Fedora 13 (in order to add support for some bit of hardware that wasn't supported by qemu at F13 release). That qemu machine type was deprecated, but still usable, in Fedora 14 (where qemu treated it equivalent to the "pc-0.13" machine type).
(In Fedora 15, the "fedora-13" machine type was inadvertently made into a synonym for "pc-0.14" rather than "pc-0.13".)
In Fedora 16, the "fedora-13" machine type is still treated as a synonym for "pc-0.14" by qemu, but libvirt automatically translates all occurrences of "fedora-13" in a guest's configuration to "pc-0.14" so that it doesn't rely on this qemu behavior. This is done because Fedora 17's qemu will completely remove support for the "fedora-13" machine type.
The result of all this confusion is that anyone upgrading from Fedora 15 to Fedora 16 will have their "fedora-13" machine type translated into exactly the same machine type they've been effectively using anyway. But, in the case of upgrading directly from F14 to F16, pre-upgrade the guest will have been running inside a qemu "pc-0.13" machine type, and after the upgrade it will be running inside a qemu "pc-0.14" machine type.
I really don't have any idea about the details in difference between these two machine types or whether it's enough of a difference to cause a BSOD, but on the off chance this could be the source of your problem, you can try this:
Edit the configuration of your guest and look for a line like this:
<type arch='x86_64' machine='pc-0.14'>hvm</type>
Change 'pc-0.14' to 'pc-0.13' and save the config, then try starting your guest.
(If the machine type is already 'pc-0.13', then this isn't your problem).
If that doesn't help, possibly you could get better help if you included your guest's domain config and the information from the BSOD.
The machine was probably initially created under Fedora 12 but I'm not sure. The machine type before the upgrade was just 'pc'. I don't know what that would have been under Fedora 14. I tried 'pc-0.13' but that didn't work (same BSOD). The BSOD info is 0x7f (everything else was zeros.) The machine config was nothing extraordinary: <domain type='kvm'> <name>tam</name> <uuid>88b5c8e3-73fe-1dbb-1459-f4134e2b85a0</uuid> <memory>1048576</memory> <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='localtime'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <source file='/data/VMs/tam-win_c.img'/> <target dev='hda' bus='ide'/> </disk> <disk type='file' device='disk'> <source file='/var/lib/libvirt/images/tam-win_d.img'/> <target dev='hdb' bus='ide'/> </disk> <interface type='bridge'> <mac address='54:52:00:3b:43:1a'/> <source bridge='br242'/> </interface> <serial type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </serial> <console type='pty' tty='/dev/pts/4'> <source path='/dev/pts/4'/> <target port='0'/> </console> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes'/> <sound model='es1370'/> </devices> </domain> Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb@unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | =======================================================================
participants (2)
-
Laine Stump -
Thomas J. Baker