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(a)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 |
=======================================================================