Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
> The thread from yesterday has died off (perhaps also because of
> my inappropriate answer to Michael, for which I apologize to him
> and everyone). I took some time to discuss the libvirt requirements
> further with Daniel Berrange and Eric Blake on IRC. If anyone is
> interested, I can give logs. This is a suggestion for how to
> proceed in both QEMU and libvirt.
>
>
> == Builtin pvpanic ==
>
> QEMU will remove pvpanic from pc-1.5 in 1.6.1 and 1.5.4. This does not
> break migration.
pvpanic has been a failure. It's a poorly designed device with even
worse semantics. I applied it and I'll take the fault for merging it in
the first place.
We should simply scrap it and start over. It has so few users at this
point that this is still a realistic option. Using something based on
ISA that requires specific ACPI entries was a mistake.
We should just introduce a simple watchdog device based on virtio and
call it a day. Then it's cross platform, solves the guest enumeration
problem, and libvirt can detect the presence of the new device.
None of the plans outlined below give us a proper solution. I think
removing is our best option at this point.
Regards,
Anthony Liguori
>
>
> == Support in libvirt for current functionality ==
>
> libvirt will add a <panic-notifier/> element, and possibly a capability
> for it accessible via "virsh capabilities". There are two possibilities:
>
> 1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine type
> other than pc-1.5), <on_crash> will only work if the element is there.
> On QEMU 1.5.0->1.5.3, and on QEMU 1.6.0 with the pc-1.5 machine type,
> <on_crash> will be obeyed always, and may override e.g. reboot-on-panic
> if a guest driver exist.
>
> 2) On all versions, <on_crash> will only work if the element is there.
>
>
> In turn, there are two ways to implement (2):
>
> 2a) libvirt will always add -global pvpanic.iobase=0 to neutralize
> the builtin pvpanic device if present. <panic-notifier/>
> will create the device with -device pvpanic,iobase=0x505
>
> Advantage: no changes to QEMU
>
> Disadvantage 1: writes to port 0 with QEMU 1.{5.0,5.1,5.2,5.3,6.0}
> and pc-1.5 machine type will write to a pvpanic device instead of
> the DMA controller. Probably harmless, and limited to some QEMU
> versions.
>
> Disadvantage 2: libvirt has knowledge of the pvpanic port number
>
> 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.
>
> == Possible improvements to pvpanic ==
>
> The current implementation of pvpanic supports three modes: reset system
> on panic, destroy domain on panic, preserve domain with no possibility
> to resume it. (Optionally a domain can be dumped too).
>
> Long term, the choice to include pvpanic should not be on the guest
> admin's shoulders, but rather in libosinfo. Thus, it would be nice to
> have a fourth mode where the panic is logged but the guest otherwise
> keeps running. This mode would let libosinfo add pvpanic by default
> without affecting the guest's behavior on panic.
>
> With this change, <on_crash>ignore</on_crash> will behave as follows
> for the three possibilities above:
>
> (1) With QEMU 1.5.0 to 1.6.1, <on_crash> will _not_ obey the setting,
> never (even if no <panic-notifier/> is specified).
>
> libvirt will have to pick a fallback action.
>
> advantage of destroy as fallback: it is the default (but
> note that restart is the default for virt-install)
>
> advantage of preserve as fallback: lets the admin examine
> the panic
>
> advantage of restart as fallback: maximum availability of
> the VM, it is the default for virt-install
>
> (2a) With QEMU 1.5.0 to 1.6.1, <on_crash> will _not_ obey the setting
> if <panic-notifier/> is specified. libvirt has _no way_ to learn
> about this, so the capability would always be present with these
> QEMU versions and libosinfo would always add <panic-notifier/> with
> these versions. Given the libosinfo scenario being considered here,
> this is not very different from (1).
>
> (2b) With QEMU 1.5.0 to 1.6.1, the <panic-notifier/> element will not
> be available and not exposed in libvirt capabilities. Thus with
> this version libosinfo would omit <panic-notifier/> from the XML.
> Guest policy will always be followed correctly.
>
>
> The problem in both (1) and (2a) can be summarized as follows. First,
> libvirt will have to implement and document a fallback action for buggy
> QEMU. Second, even though the problems would be limited to some version
> of QEMU, they would be relatively hard to debug for a casual user, could
> start happening randomly by updating any one of QEMU, libvirt, libosinfo
> or the guest kernel, and there is no fallback action for libvirt that is
> always correct.
>
> Thus, considering future libosinfo support for pvpanic, (2b) is preferrable
> in my opinion.
>
> Now, making pvpanic reversible requires a change in QEMU (patch already
> posted). Andreas proposed using a pvpanic property to determine whether
> the panicked state is temporary or definitive. libvirt could piggyback
> on such a property to detect the "goodness" of machine types (as mentioned
> regarding solution 2b above). However:
>
> First, this would require a more intrusive patch, less appealing for
> 1.5 and 1.6 stable branches. Second, there is no reason why libvirt would
> want to make the panicked state definitive. To achieve the same effect,
> libvirt can just not issue the "continue" monitor command when the guest
> is panicked. Thus the new property would be useless except to communicate
> pvpanic behavior---and renaming the device still seems preferrable to me.
>
> Thanks for reading up to here!
>
> Paolo
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list