This is the 2nd attempt at solving the problem of virDomainDestroy
uncermoniously sending SIGKILL to the qemu process before it's had a
chance to flush its disk buffers. In v1, I altered the default
behavior of virDomainDestroy(), but that was rejected as changing
established API behavior. In v2, the default behavior is maintained,
and a new flag VIR_DOMAIN_DESTROY_GRACEFUL is added fo the
virDomainDestroyFlags API. If that flag is included in the call,
virDomainDestroyFlags will only send SIGTERM to the qemu process, and
if that is unsuccessful, it will return an error rather than sending
SIGKILL.
I've also included a 2nd patch which lengthens the timeout prior to
sending SIGKILL. Although there has been some sentiment against doing
this, my opinion is that it's the prudent thing to do because:
1) The original timeout of 1.6 seconds was arbitrarily selected, and
obviously isn't always adequate.
2) In the cases where the current timeout *is* adequate, there will be
exactly 0 change in behavior anyway. The only time behavior will
change (and that will just be in the form of a longer delay before the
API call returns) will be in those cases where we would otherwise have
caused guest disk corruption. I know which of those two options I
would choose if it was my guest.
3) Just adding a new flag to the libvirt API does not do anything to
help those who are stuck (if only temporarily) with an existing
version of an application that doesn't support the new API flag. Since
libvirt is the cause of the problem, we should try to mitigate the
problem as much as possible without requiring updates of other
packages.