On 08/01/2013 06:26 PM, Eric Blake wrote:
On 08/01/2013 08:18 AM, Gerd Hoffmann wrote:
On 08/01/13 15:08, Marcel Apfelbaum wrote:
Hi,
The problem with pvpanic being an internal device is that VMs running
operating systems without a driver for this device will have problems
when qemu will be upgraded (from qemu without this pvpanic).
The outcome may be, for example: in Windows(let's say XP) the Device manager
will open a "new device" wizard and the device will appear as an unrecognized device.
Only happens when also changing the machine type on upgrade as it is
turned off on old machine types.
But, yes, pvpanic will show up as "Unknown device" without driver and
with the funky yellow exclamation mark in device manager in windows
guests. Newer windows versions don't kick the "new device" wizard. But
still I have my doubts that it is a good idea to add it unconditionally ...
Automatic devices with no command line argument have proven to be a
nightmare for libvirt as well. Although the just-released libvirt 1.1.1
now supports the <on_crash> element for controlling the command line
parameters of qemu related to how qemu will behave when the pvpanic
device is triggered, I would also welcome having the ability to control
whether the guest even has a pvpanic device exposed, just as we can
control whether a guest has a memballoon device exposed.
This is quite different from memballoon.
pvpanic is a single I/O port, it doesn't use up a PCI slot (thus
causing conflicts with other devices at the same address).
Perhaps this issue is simply fixed by making the _STA method
return 0x0B instead of 0x0F (i.e. turning off the "show in user
interface" bit).
Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list