Re: [libvirt] [PATCH 05/11] libxl: use job functions in libxlDomainDestroyFlags

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(a)suse.com&gt; > --- > 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.

With this it looks like you're just going to wait indefinitely for any pending job to complete before attempting to kill the guest.

Is there anything you can safely do with the libxl APIs which would be equivalent to kill -9, outside the job block.

Then you just need the job to protect cleanup of the internal state on virDomainObjPtr.