[libvirt] [PATCH 1/2] qemuDomainUndefineFlags: Grab QEMU_JOB_MODIFY

[Michal Privoznik]

On 08/15/2017 03:00 AM, John Ferlan wrote:
> 
> 
> On 08/07/2017 08:20 AM, Michal Privoznik wrote:
>> This API is definitely modifying state of @vm. Therefore it
>> should grab a job.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>  src/qemu/qemu_driver.c | 23 ++++++++++++++---------
>>  1 file changed, 14 insertions(+), 9 deletions(-)
>>
> 
> Not sure which of or if this patch from the two undefine series is
> active, but I wonder how this "interacts or intersects" with:
> 
> https://www.redhat.com/archives/libvir-list/2017-July/msg00921.html

Oh right. This patch of mine can resolve the issue that you're linking.
The thing is, in qemuDomainCreateWithFlags() an async job is grabbed
(VIR_DOMAIN_JOB_OPERATION_START) and as such only certain type of sync
jobs is allowed. In this specific case just destroy is permitted.
Therefore, if undefine would grab a modify type of job it would be
suspended as long as the async job is set on the domain.

Good point! Thanks for catching that.

> 
> which was posted late last month... I looked at it, but really hadn't
> dug into yet.  The summary of the linked patch is it's possible to run
> an undefine while a define is occurring because locks are dropped during
> launch processing. However, if there's a job, then wouldn't that mean
> it'd be less likely or impossible to allow that undefine while the
> define job was happening?  Of course as Martin notes RemoveInactive
> cannot be run with a job, but the problem from the other patch is that
> the RemoveInactive is at least partially successful.
> 
> I guess I just wanted to be sure to note the link between the two just
> in case you were actively still thinking about this one (and had better
> ideas for the other patch where I went with the first thing that came to
> mind w/r/t using a flag).

Yeah, I'm gonna rework this one and resend. We can clearly see that
there's no excuse for an API to not grab a job!

Michal