Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On 08/02/2013 12:42 AM, Eric Blake wrote: On 08/01/2013 04:23 PM, Paolo Bonzini wrote: 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). 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? The user can still manually install a driver even for a device that is not exposed. Having to manually specify the pvpanic device would be yet another knob that nobody uses. Panic notification is a useful feature that should be supported with no particular intervention from the user. Paolo
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Fri, Aug 02, 2013 at 10:31:11AM +0200, Paolo Bonzini wrote: On 08/02/2013 12:42 AM, Eric Blake wrote: On 08/01/2013 04:23 PM, Paolo Bonzini wrote: 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). 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? The user can still manually install a driver even for a device that is not exposed. Having to manually specify the pvpanic device would be yet another knob that nobody uses. Panic notification is a useful feature that should be supported with no particular intervention from the user. Yep, that was the big motivation behind doing it as an I/O port that we could have enabled by default, as opposed to a virtio serial device or some other paravirt device that required explicit configuration. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
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 ... cheers, Gerd
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
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. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Thu, 2013-08-01 at 19:31 +0300, Michael S. Tsirkin wrote: On Thu, Aug 01, 2013 at 10:26:53AM -0600, 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. A natural way to do this would be with -device pvpanic. I'm not sure why it wasn't done like this from the beginning, but it shouldn't be hard to redo, hopefully we can fix this bug in time for 1.6. I'll come up with something, hopefully in time. Marcel
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Thu, Aug 01, 2013 at 10:26:53AM -0600, 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. A natural way to do this would be with -device pvpanic. I'm not sure why it wasn't done like this from the beginning, but it shouldn't be hard to redo, hopefully we can fix this bug in time for 1.6. -- MST
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
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
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On 08/01/2013 04:23 PM, Paolo Bonzini wrote: 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). 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? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Thu, Aug 01, 2013 at 04:08:57PM +0300, 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. Now what will happen 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. My point is that a device that requires a driver that is not inbox, should not be present by default. One possible solution is to add it manually with -device from command line. Any thoughts? Marcel Interesting. You are basically saying we should have a rule that no new builtin devices should be added without an explicit request from management interface? -- MST
Re: [Qemu-devel] pvpanic device should not be automatically included as an internal device
On Thu, 2013-08-01 at 16:32 +0300, Michael S. Tsirkin wrote: On Thu, Aug 01, 2013 at 04:08:57PM +0300, 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. Now what will happen 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. My point is that a device that requires a driver that is not inbox, should not be present by default. One possible solution is to add it manually with -device from command line. Any thoughts? Marcel Interesting. You are basically saying we should have a rule that no new builtin devices should be added without an explicit request from management interface? Basically, yes. The only builtin devices shall be devices that the operating systems know how to handle with the default drivers. Marcel
