qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] question about concurrent block job


From: Zhangleiqiang
Subject: Re: [Qemu-devel] question about concurrent block job
Date: Wed, 8 May 2013 03:54:31 +0000

Hi, Stefan:

> The tricky parts are:
> 
> 1. Extending the QMP API to support multiple block jobs.  Old clients
>    only know how to deal with 1 block job but they should continue to
>    work.

I think the block-job related qmp commands which are needed to change are as 
follows:

1. cmds for job control:  block-job-set-speed, block-job-cancel, 
block-job-pause, block-job-resume, block-job-complete
2. cmds for job query:   query-block-jobs

In order to make sure that old clients keep working, the job control cmds can 
add one optional argument of "job_id". If the arg of "job_id" is not assigned, 
then the cmd will affect all the running jobs. 
The "job_id" may be returned by the corresponding job start command and the 
"query-block-jobs" command.

For example:

-> drive-mirror device=drive0 target=/path/to/dest.snap sync=full
<- {u'return': {"job_id": 123}}

-> query-block-jobs
<- {u'return': [{u'busy': True, u'type': u'mirror', u'len': 8589934592, 
u'paused': False, u'io-status': u'ok', u'offset': 4483579904, u'device': 
u'drive0', u'speed': 1, u'job_id': 123}, {u'busy': True, u'type': u'commit', 
u'len': 1073741824, u'paused': False, u'io-status': u'ok', u'offset': 
1073741824, u'device': u'drive0', u'speed': 1, u'job_id': 122}]}

->block-job-cancel job_id=123
<- {u'return': {}}



----------
Leiqzhang

Best Regards


> -----Original Message-----
> From: Stefan Hajnoczi [mailto:address@hidden
> Sent: Thursday, April 25, 2013 8:12 PM
> To: Zhangleiqiang
> Cc: Paolo Bonzini; address@hidden
> Subject: Re: [Qemu-devel] question about concurrent block job
> 
> On Thu, Apr 25, 2013 at 01:59:23AM +0000, Zhangleiqiang wrote:
> >     May be the "in_use" flag of "bs" at the "drive" unit is too large. 
> > Perhaps
> the "in_use" flag should just lock at the unit of one or some "image(s)" in 
> the
> image chain, the "image(s)" needed to be locked are always the ones will be
> write during the job.
> >
> >     E.g. "drive_mirror" lock the "snapshot-file", "block-commit" lock the 
> > dst
> image of the commit job, etc.
> 
> Choosing a finer-grained approach is not too hard.
> 
> The tricky parts are:
> 
> 1. Extending the QMP API to support multiple block jobs.  Old clients
>    only know how to deal with 1 block job but they should continue to
>    work.
> 
> 2. Thinking through all block jobs and their possible interactions.
> 
> Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]