From: Eric Blake <eblake@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Andreas Faerber <afaerber@suse.de>,
qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] [PATCH 2/3] qemu-char: add -chardev exit-on-eof option
Date: Tue, 29 Jul 2014 06:58:50 -0600 [thread overview]
Message-ID: <53D79A8A.9060500@redhat.com> (raw)
In-Reply-To: <8761igy9qn.fsf@blackfin.pond.sub.org>
[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]
On 07/29/2014 12:12 AM, Markus Armbruster wrote:
>> 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?
Libvirt starts the destination with -S, and migration can't complete
until libvirt resumes the destination CPUs with 'cont'. Libvirt's
current timing of releasing auto-destruct is based on handshaking
between source and destination; it occurs after source claims migration
is done but before resuming CPUs on the destination, which satisfies the
atomicity that you correctly observed to be necessary.
>> 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 :)
Added in June 2013; and we *did* have a discussion on whether to hide
the transaction name at the time...
https://lists.gnu.org/archive/html/qemu-devel/2013-06/msg03281.html
> I don't really mind this instance, but I'm a bit concerned about rank
> ABI growth.
And that's a good position to maintain - it's always good to justify new
knobs, especially since once they are ABI, it's harder to refactor
around them.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]
next prev parent reply other threads:[~2014-07-29 12:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-24 16:39 [Qemu-devel] [PATCH 0/3] libqtest: solve QEMU process cleanup problem Stefan Hajnoczi
2014-07-24 16:39 ` [Qemu-devel] [PATCH 1/3] libqemustub: add qemu_system_shutdown_request() and no_shutdown Stefan Hajnoczi
2014-07-24 17:07 ` Peter Maydell
2014-07-25 9:42 ` Stefan Hajnoczi
2014-07-24 16:39 ` [Qemu-devel] [PATCH 2/3] qemu-char: add -chardev exit-on-eof option Stefan Hajnoczi
2014-07-25 8:12 ` Markus Armbruster
2014-07-25 9:39 ` Stefan Hajnoczi
2014-07-28 23:08 ` Eric Blake
2014-07-29 6:12 ` Markus Armbruster
2014-07-29 12:58 ` Eric Blake [this message]
2014-07-29 14:41 ` Markus Armbruster
2014-07-24 16:39 ` [Qemu-devel] [PATCH 3/3] libqtest: use -chardev exit-on-eof to clean up QEMU Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53D79A8A.9060500@redhat.com \
--to=eblake@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.