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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list