On Mon, Aug 05, 2013 at 06:03:34PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 12:20:44PM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 12:18:26PM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 11:16:17AM +0300, Gleb Natapov wrote:
On Mon, Aug 05, 2013 at 11:10:55AM +0300, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2013 at 03:47:23PM +0800, Hu Tao wrote:
pvpanic device is an internal default device in qemu. It may cause problem when upgrading qemu from a version without pvpanic.
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. On a cluster with hundreds of such VMs, If that cluster has a health monitoring service it may show all the VMs in a "not healthy" state.
This patch is a workaround to not show pvpanic in UI to avoid the problem in Windows.
Cc: Marcel Apfelbaum marcel.a@redhat.com Cc: "Michael S. Tsirkin" mst@redhat.com Cc: Paolo Bonzini pbonzini@redhat.com Cc: Gerd Hoffmann kraxel@redhat.com Cc: Eric Blake eblake@redhat.com Cc: "Daniel P. Berrange" berrange@redhat.com Cc: Andreas Färber afaerber@suse.de Signed-off-by: Hu Tao hutao@cn.fujitsu.com
Quoting from this discussion:
That may "fix" the issue of a windows guest showing the yellow ! mark, but what if, down the road, someone writes an actual windows driver that is aware of that port and how to make a windows BSOD write a panic notification to the port? How does a user go about installing such a driver if the device is not exposed in the user interface list of devices?
I think the correct way to address this is:
- don't create the device by default, only when -device pvpanic is present
- teach management to supply said -device pvpanic for guests which support the pvpanic device
That's just pushing the problem elsewhere. How management suppose to know if guest support pvpanic device?
Same as any PV device really. It's exactly the same problem as with virtio: user configures the XML properly.
Virtio has alternatives.
I don't see why does it matter. In any case, only *some* virtio devices have alternatives. What about the balloon device? VIRTIO_9P? There are more examples. What about e.g. ivshmem?
They take very limited pci resources and/or provide functionality that should not be available for all guests. We do provide ACPI hotplug device unconditionally.
What if initially guest did not have a driver, but the it was installed?
You can reconfigure XML and reboot.
Will it cause Windows reactivation? Maybe after adding several devices?
I don't think it will. https://en.wikipedia.org/wiki/Microsoft_Product_Activation says: Display adapter SCSI adapter IDE adapter Network adapter MAC address RAM amount range (e.g. 0-512 MB) Processor type and serial number Hard drive device and volume serial number Optical drive (e.g. DVD-ROM)
As you see we do let people change many parameters that do affect activation.
By editing XML user can shoot himself in the foot, we should not prevent that. It should not be required though.
If device appears for old machine models this is bug, otherwise I fail to see any problem.
Care answering the question that Eric Blake posed (above)?
Which one? About how to install driver if device is not shown in the gui? I suppose clicking on device driver installer should do the job.
Did you try?
I do not see any reasonable doubt to even question the possibility :) But see Paolo's reply.
I think this requires an EXE installer. Being prompted for driver makes it possible to install one from INF.
AFAIK INF is clickable file, but regardless I do not think even _this_ patch is needed. What is needed is Windows driver for the device.
How about changing drivers? Selecting one driver from multiple variants? How do you disable it if it's causing trouble, or for testing?
Again, as Paolo says you can see it if you really wish.
-- Gleb.