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 <marce...@redhat.com> > > > > > > > Cc: "Michael S. Tsirkin" <m...@redhat.com> > > > > > > > Cc: Paolo Bonzini <pbonz...@redhat.com> > > > > > > > Cc: Gerd Hoffmann <kra...@redhat.com> > > > > > > > Cc: Eric Blake <ebl...@redhat.com> > > > > > > > Cc: "Daniel P. Berrange" <berra...@redhat.com> > > > > > > > Cc: Andreas Färber <afaer...@suse.de> > > > > > > > Signed-off-by: Hu Tao <hu...@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.
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. -- MST
