On Mon, Aug 05, 2013 at 07:04:22PM +0300, Gleb Natapov wrote:
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 firstname.lastname@example.org > Cc: "Michael S. Tsirkin" email@example.com > Cc: Paolo Bonzini firstname.lastname@example.org > Cc: Gerd Hoffmann email@example.com > Cc: Eric Blake firstname.lastname@example.org > Cc: "Daniel P. Berrange" email@example.com > Cc: Andreas Färber firstname.lastname@example.org > Signed-off-by: Hu Tao email@example.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.
So that's what I'm saying basically. At the moment there's no way to remove this device from XML. That's just wrong. In QEMU, we have a standard way to specify devices with -device. That should be the interface for anything new really unless there's a very compelling reason for something else. *Not* building it into the PC machine type.
It should not be required though.
libvirt can pass -device pvpanic by default if nothing is specified in XML. That discussion really has to happen on libvirt list.