qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/3] qemu-char: add -chardev exit-on-eof option


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 2/3] qemu-char: add -chardev exit-on-eof option
Date: Tue, 29 Jul 2014 06:58:50 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]