[libvirt] [PATCH 1/2] qemuDomainUndefineFlags: Grab QEMU_JOB_MODIFY
mprivozn at redhat.com
Tue Aug 15 06:01:51 UTC 2017
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:
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!
More information about the libvir-list