Jiri Denemark <jdenemar@xxxxxxxxxx> writes: > On Fri, Feb 17, 2017 at 12:38:24 +0100, Milan Zamazal wrote: >> Jiri Denemark <jdenemar@xxxxxxxxxx> writes: >> >> > On Fri, Feb 10, 2017 at 21:50:19 +0100, Milan Zamazal wrote: >> >> Hi, is there a reliable way to find out to what kind of job does the >> >> information returned from virDomainGetJobStats or provided in >> >> VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event callback belong to? >> > >> > No, libvirt expects that the caller knows what job it started. All jobs >> > currently reported using virDomainGetJobStats API or >> > VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event are internally implemented as >> > migration in QEMU driver (either to a file or to a network socket), >> > which may confuse any heuristics for detecting the job type from the set >> > of fields returned by libvirt. >> >> I see, thank you for explanation. >> >> > What is the problem you are trying to solve? >> >> There are basically two problems: >> >> - When the job completion callback is called, I need to distinguish what >> kind of job was it to perform the appropriate actions. It would be >> easier if I knew the job type directly in the callback (no need to >> coordinate anything), but "external" job tracking is also possible. > > An immediate answer would be: "don't rely on the completion callback and > just check the return value of the API which started the job", but I > guess you want it because checking the return value is not possible when > the process which started the job is not running anymore as described > below. Well, avoiding using the completion callback is probably OK for me. (In case of the process restart, I don't expect having everything perfectly working, just some basic sanity.) >> - If I lost track of my jobs (e.g. because of a crash and restart), I'd >> like to find out whether a given VM is migrating. Examining the job >> looked like a good candidate to get the information, but apparently >> it's not. Again, I can probably arrange things to handle that, but to >> get the information directly from libvirt (not necessarily via job >> info) would be easier and more reliable. > > Apparently you are talking about peer-to-peer migration, Yes. > otherwise the migration would be automatically canceled when the > process which started it disappears. I'm afraid this is not currently > possible in general. You might be able to get something by checking > the domain's status, but it won't work in all cases. Too bad. Could some future libvirt version provide that information? Thank you for clarification, Milan _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users