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: Mon, 28 Jul 2014 17:08:28 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 07/25/2014 02:12 AM, Markus Armbruster wrote:
> Stefan Hajnoczi <address@hidden> 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?

> 
> 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 (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'.

-- 
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]