Re: [libvirt] [RFC PATCH v2 0/3] Start fixing the pvpanic mess
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 21/08/2013 19:02, Eric Blake ha scritto:
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?
Perhaps <panic_notifier bus='isa'/> is better? Note that for s390
<on_crash> works without <pvpanic>.
Anyway yes, that's a possibility.
More precisely, you could still use <on_crash> for internal errors
even without having anything in <devices> (Xen conflates panics and
internal errors).
But then, "pause" and "ignore" are useful on-panic policies, yet they
do not make sense for internal errors. Hence my suggestion to
introduce a new element <on_panic>. We can still make <on_panic> a
no-op without the appropriate element under <devices>.
Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSFPSWAAoJEBvWZb6bTYbywvMP/3MKlED6Y69QM7Xt0aAKEtZp
RmcKUt1m4MAuV91eBmN5/fv+ui0yKzrnZWz0mgF+V3eWCJdnEiewkGocetpx+Mw7
V4wuGVkYUWXV/O8A6x3thENOoxaHYO4OP8dUgkWQLGHXRNTljAd4iyVxBiIbITod
fZvhVEbk8n9Mk3U61JxeMRB5PDjXRHcjgLgpR7htujpVBMTBFAsqxLzflsxsd/p7
UOZ0D3vk6m00DHdIzcJ5pc0dyqaylEaljs3Lf1MNbC/fN8I1sgrMWYMYnukU+moC
GRKS6OB1ySeq2MkMwe73RimtE8M8MNmtVUKle94bmymPdGD3V+qKmBq6o7Hzd+b7
l8Rkht9gWP7Z4T22ZOYVqHpRXaDivkHuRCL2Va3BpyYv48Atyk/G77uB1uSaGTj+
ooRNoEqO61e49JOM3NiEYRI6Gl2YJ5O560j7dK59mQ6OIrLMtuN6Wo1ZiubdKCOa
HB3e6qF0drAEQIBSdqQiU83F58ta634Rqy5R5kc1ad9cuiLMtUDPNbHlKsJtf+Th
Dyu301fxt/1IIxPheoBQNVLRoXtAfoqpxM1nasjRphQqnULpnl7q7MipAclEUadQ
Q7KE0YFPw38BYxl2FWhZOuTNI2kN921PGNiqYFFVpOWCf/aW/uqxU86LnJVSdvZs
T9sRlLpVL4LTGHbFDooI
=nCgT
-----END PGP SIGNATURE-----