Il 22/08/2013 19:15, Laszlo Ersek ha scritto: >> 2) On all versions, <on_crash> will only work if the element is there. > > I like this, because, if on_crash doesn't work without panic_notifier > *at all*, then we can just drop panic_notifier, and make on_crash mean > (on_crash && panic_notifier) in the original sense. > > IOW, drop "panic_notifier", and make "on_crash" work *always*.
No, we cannot because of backwards compatibility. VMs could have no on_crash element (which means <on_crash>destroy</on_crash>) and yet the guest admin could expect them to reboot on panic. >> 2b) QEMU will provide a way for libvirt to detect that no machine type >> has the builtin pvpanic. If some machine type may have the builtin >> pvpanic, and <panic-notifier/> is absent, libvirt will add >> "-global pvpanic.iobase=0" to neutralize it. Otherwise, libvirt >> will create the device normally. >> >> A possible way for libvirt to detect "good" machine types is a >> dummy property. This is a bit ugly in that the property would not >> affect the behavior of the device. The property would remain in >> the long term. >> >> Another possibility is for QEMU to rename the device, e.g. to >> isa-pvpanic. This is also somewhat gross, but not visible in the >> long term when the "pvpanic" name will be lost in history. >> >> Advantage 1: libvirt has no knowledge of the pvpanic port number >> >> Disadvantage 1: same as above >> >> Disadvantage 2: need a somewhat gross change in QEMU >> >> >> This method also provides an (also somewhat gross on the QEMU side) >> way to detect other changes in the pvpanic semantics. One example >> mentioned below, is making the panicked state temporary. > > Too much work in qemu, in order to introduce ugliness, to hide older > ugliness. Is it too much work? s/"pvpanic"/"isa-pvpanic"? Paolo -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
