On 10/09/2014 07:09 AM, Jiri Denemark wrote:
>
> virDomainJobType is a bit overloaded since it is mostly used to describe
> what kind of job is running and also about its state.
>
> - VIR_DOMAIN_JOB_NONE - no job is currently running
> - VIR_DOMAIN_JOB_BOUNDED - there is a job running and we know how much
> data we will need to process during the job. That is, apps may easily
> indicate its progress because we report the total amount of data and
> how much we already processed. Currently we don't have such jobs in
> libvirt.
Technically, some of the block jobs might fit this category; for
example, a block commit of an intermediate layer has a finite amount of
effort to perform. Active commit might be slightly unbounded, depending
on whether the guest is performing I/O faster than the merge can flush
it into the backing chain, but even then, it is like all other block
jobs in that it provides a x/y completion metric; even if y is growing
during the course of the operation, you can estimate progress by how
fast x is converging to the value of y. On the other hand, we haven't
(yet) merged block jobs and domain jobs into a common framework yet.
I'd also like to get to the point where we have storage volume jobs,
some of which may be bounded.
> - VIR_DOMAIN_JOB_UNBOUNDED - there is a job running and we have no idea
> how much data we will need to process. That is, while we are
> processing data, something we already processed gets changed and we
> need to process it again. This is a live migration, once all memory is
> processed, we need to process the memory that changed in the
> meantime...
Hmm, that also sounds like active commit :)
> - VIR_DOMAIN_JOB_COMPLETED - there was a job running and it has just
> finished (very hard to be seen externally until recently when we added
> support for explicitly querying statistics about a completed job)
> - VIR_DOMAIN_JOB_FAILED - there was a job running and it failed
> - VIR_DOMAIN_JOB_CANCELLED - there was a job running and it was
> cancelled either by libvirt itself or by a user/app
>
> Apps know VIR_DOMAIN_{UN,}BOUNDED job mean there is a job running. We
> can't change that without breaking them.
>
I agree that adding new states is not a very good idea at this point,
but we already know we need to someday enhance the job system to allow
parallel jobs. Having more details about a running job, such as whether
it is in first or second stage, may make sense. After all, for both
block copy and active commit, we DO report two different job states for
whether the job has moved between two stages.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list