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