Re: [libvirt] [RFC PATCH v2 0/3] Start fixing the pvpanic mess

On 08/21/2013 10:51 AM, Paolo Bonzini wrote: Let's expand on that statement: Libvirt's default for <on_crash> is 'destroy'. But virt-install (and thus virt-manager) have been setting explicit 'restart' for AGES now. Arguably, this is YET ANOTHER reason why virt-manager should be using libosinfo to make sane choices about new guest XML, based on known capabilities of the guest it will be installing. But that only affects newly created guests after we fix the virt stack. In the meantime, you have a point that we have a back-compat mess - we promise ABI stability (guests shall not see hardware changes when upgrading versions of libvirtd but leaving the XML unchanged - the only way to change hardware seen by an existing guest is to explicitly modify XML). Yes, so we need the back-compat code to leave pvpanic out of pre-existing guests, if we can find a way to sensibly do that. So, this boils down to a question of what SHOULD the valid states for <on_crash> be? Generically, we want <on_crash>destroy</on_crash> to not invalidate a guest, but also to not instantiate a pvpanic device; since that covers the libvirt defaults. We also want <on_crash>restart</on_crash> to not invalidate a guest, but also to not instantiate a pvpanic device, since so many existing guests have that setting thanks to virt-install. Maybe that means we add attributes/sub-elements to <on_crash> that express whether pvpanic device is permitted; and the absence of that attribute means the status quo (the <on_crash> tag is effectively ignored because without pvpanic device, there is no way for libvirt to learn if a guest panicked). Or does it mean we expose a new sub-element of <devices>, similar to how we have a <memballoon> subelement that controls whether the memballoon device is show to the guest, and just document that for qemu, <on_crash> is a no-op without the <pvpanic> subelement? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org