-----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----- -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list