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