Re: [libvirt] pvpanic plans?

Il 31/10/2013 16:09, Michael S. Tsirkin ha scritto: > On Thu, Oct 31, 2013 at 03:56:42PM +0100, Paolo Bonzini wrote: >> Il 31/10/2013 15:52, Michael S. Tsirkin ha scritto: >>>>> Yes, it does. >>> What does it break exactly? >> >> The point of a panicked event is to examine the guest at a particular >> moment in time (e.g. host-initiated crash dump). If you let the guest >> run, it may reboot and prevent you from getting a meaningful dump. > > Well we trust guest anyway, so I think we can trust it to call halt. No, we cannot. Reboot-in-guest-after-dump-on-host is a perfectly fine configuration. >>>>> But I think that, once we make the pvpanic device is >>>>> optional, to a large extent there is no bug. Adding the pvpanic >>>>> device to the VM will make libvirt obey <oncrash> instead of the >>>>> in-guest setting, and that's it. >>>>> >>>>> Two months have passed and no casualties have been reported due to >>>>> pvpanic. Let's just remove the auto-pvpanic from all machine types in >>>>> 1.7 (yes, that's backwards incompatible in a strict sense), document >>>>> it in the release notes, and hope that the old QEMU versions with >>>>> mandatory pvpanic die of old age. >>> >>> Nod. I'm fine with that. >>> >>> I think we still need to do get rid of the PANICKED state somehow. >>> If we can't replace it with RUNNING state, let's replace it with PAUSED. >>> >>> For example, you can't continue from panicked for some reason. >>> You can't do a reset. But you can pause and then continue. >> >> We need to keep the PANICKED state, but we can make it a normal >> "resumable" state. > > If it's resumable how is it different from PAUSED? If the guest panics while for some reason libvirtd went down, libvirt can see what happened. It is similar to the "I/O error" state in this respect. > Looks like all transitions from paused state should be allowed from panicked > state. So why keep it separate? Because you can poll for the state instead of watching an event. Paolo