[libvirt] [PATCHv2 1/2] qemu: new GRACEFUL flag for virDomainDestroy w/ QEMU support
eblake at redhat.com
Fri Feb 3 17:11:22 UTC 2012
On 02/03/2012 01:12 AM, Daniel Veillard wrote:
> On Thu, Feb 02, 2012 at 12:54:28PM -0500, Laine Stump wrote:
>> When libvirt's virDomainDestroy API is shutting down the qemu process,
>> it first sends SIGTERM, then waits for 1.6 seconds and, if it sees the
>> process still there, sends a SIGKILL.
>> @@ -2233,10 +2233,22 @@ error:
>> * This does not free the associated virDomainPtr object.
>> * This function may require privileged access.
>> - * Calling this function with no @flags set (equal to zero)
>> - * is equivalent to calling virDomainDestroy. Using virDomainShutdown()
>> - * may produce cleaner results for the guest's disks, but depends on guest
>> - * support.
>> + * Calling this function with no @flags set (equal to zero) is
>> + * equivalent to calling virDomainDestroy, and after a reasonable
>> + * timeout will forcefully terminate the guest (e.g. SIGKILL) if
>> + * necessary (which may produce undesirable results, for example
>> + * unflushed disk cache in the guest). Including
>> + * VIR_DOMAIN_DESTROY_GRACEFUL in the flags will prevent the forceful
>> + * termination of the guest, and virDomainDestroyFlags will instead
>> + * return an error if the guest doesn't terminate by the end of the
>> + * timeout; at that time, the management application can decide if
>> + * calling again without VIR_DOMAIN_DESTROY_GRACEFUL is appropriate.
Should we also be mentioning the possibility of data loss in the
virDomainDestroy() documentation, as part of pointing to
virDomainDestroyFlags() as the solution?
> Except for the 2 nits that looks fine to me
This one can go in now - it is strict enhancement. That's true whether
or not we wait for more consensus on 2/2, where we are deciding whether
changing hueristics/timeout value is appropriate or backwards-incompatible.
Eric Blake eblake at redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 620 bytes
Desc: OpenPGP digital signature
More information about the libvir-list