Daniel P. Berrange wrote: > On Thu, Feb 06, 2014 at 08:53:09PM -0700, Jim Fehlig wrote: > >> Modify operation that needs to wait in the queue of modify jobs. >> >> Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx> >> --- >> src/libxl/libxl_driver.c | 21 +++++++++++++++------ >> 1 file changed, 15 insertions(+), 6 deletions(-) >> > > >> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c >> index caabb44..bb574bc 100644 >> --- a/src/libxl/libxl_driver.c >> +++ b/src/libxl/libxl_driver.c >> @@ -1549,6 +1549,7 @@ libxlDomainDestroyFlags(virDomainPtr dom, >> libxlDriverPrivatePtr driver = dom->conn->privateData; >> virDomainObjPtr vm; >> int ret = -1; >> + bool remove_dom = false; >> virObjectEventPtr event = NULL; >> >> virCheckFlags(0, -1); >> @@ -1559,10 +1560,13 @@ libxlDomainDestroyFlags(virDomainPtr dom, >> if (virDomainDestroyFlagsEnsureACL(dom->conn, vm->def) < 0) >> goto cleanup; >> >> + if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_DESTROY) < 0) >> + goto cleanup; >> > > So there's one complication in the destroy method. You really, > really want destroy to succeed no matter what. In the QEMU driver > we will kill -9 the QEMU process from outside the job condition. > This should unblock any currently active jobs, so when we then > begin the destroy job there's no delay. In the libvirtd daemon > RPC dispatch code, the destroy method is also marked as high > priority so it gets processed in a dedicated thread pool for > high priority RPC calls. Again we don't want high priority > calls to be blocked by low priority calls. > Thanks for the info. > With this it looks like you're just going to wait indefinitely > for any pending job to complete before attempting to kill the > guest. > Well, wait for 30 seconds and then fail, but yes, you are right :). > Is there anything you can safely do with the libxl APIs which > would be equivalent to kill -9, outside the job block. I think libxl_domain_destroy() is the kill -9 equivalent. Adding Ian Jackson to confirm... > Then > you just need the job to protect cleanup of the internal state > on virDomainObjPtr. > Yep, makes sense. I'll adjust the patches accordingly. Regards, Jim -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list