Eric Blake <ebl...@redhat.com> writes: > On 07/25/2014 02:12 AM, Markus Armbruster wrote: >> Stefan Hajnoczi <stefa...@redhat.com> writes: >> >>> When QEMU is executed as part of a test case or from a script, it is >>> usually desirable to exit if the parent process terminates. This >>> ensures that "leaked" QEMU processes do not continue consuming resources >>> after their parent has died. > >>> ## >>> -{ 'type': 'ChardevHostdev', 'data': { 'device' : 'str' } } >>> +{ 'type': 'ChardevHostdev', 'data': { 'device' : 'str', >>> + '*exit-on-eof' : 'bool' } } >>> >>> ## >>> # @ChardevSocket: >> >> Any use cases beyond libqtest? > > Libvirt probably won't use it for normal guests (we don't want to kill > qemu just because the monitor disconnects), but does have the notion of > an autodestroy guest where it might be useful (we WANT the guest to go > away if libvirtd dies early). In fact, autodestroy guests are used > during migration - we want to kill qemu on the destination side if > libvirtd dies before the source side finishes sending the migration > stream. But in that scenario, once migration succeeds, libvirt has to > be able to convert an autodestroy guest back into a normal guest that no > longer disappears when libvirtd does; would this be something that QMP > can toggle the state of this attribute on the fly? Perhaps through qom-set?
After migration completes, execution moves from source to target. Wouldn't you want to switch off target auto-destruct together with that move, atomically? >> If no, should this be x-exit-on-eof? >> >> Hmm, looks like there's no precedence for x- in QAPI. > > Ah, but we do. For example, x-rdma-pin-all in MigrationCapability in > qemu 1.7; which has later been removed. > > However, we also have precedence of actions in QAPI that are very > unlikely to be used outside of qtest, but which are not marked > experimental; for example, the 'Abort' action in 'transaction' will > probably never be used by libvirt Arguably not a conscious decision to make it ABI forever, more a case of nobody thought about *not* making it ABI :) > (but as I type that, the thought in > the back of my mind is that I could possibly do some sort of feature > probing by setting up a transaction that will abort, and distinguish > between whether the transaction aborted or whether it errored out > because the feature I'm probing for isn't present). > > I'm fine leaving this as plain 'exit-on-eof'. I don't really mind this instance, but I'm a bit concerned about rank ABI growth.