On 08/05/2013 09:19 PM, Eric Blake wrote:
On 08/05/2013 01:04 PM, Paolo Bonzini wrote:
Libvirt has no problem enabling -device pvpanic for all guests where <on_crash> is set to a non-default value, since the use of <on_crash> is a sufficient hint that the user expects the guest to be able to notify of a crash in the first place. But I definitely agree that it is more conservative to ask libvirt to always provide -device pvpanic than it is to blindly enable the device and hope that it never causes damage.
Changing guest ABI depending on <on_crash> is a much much worse cure than the disease.
I'm not sure I follow. If the user requests <on_crash> but qemu is too old to provide -device pvpanic, then libvirt can fail to create the guest by telling the user their request can't be honored. If the user requests <on_crash> and qemu is new enough, then libvirt requests the pvpanic device as part of starting the guest. If the user doesn't requst <on_crash> handling, then the presence or absence of the device doesn't matter, and it is more conservative to omit the device. The only time the guest ABI would change is if the user changes XML - but that's exactly what the user is already capable of doing in any number of other situations.
Not all XML changes are also changes to the guest hardware. The simplest case is perhaps changing the disk source; it doesn't change the hardware seen by the guest, only the contents.
Also, even with a default <on_crash> (is it "preserve"? that's the behavior without pvpanic) it is useful to have the device because libvirt then can properly mark the domain as "crashed" instead of "running".
Paolo