qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/4] block: add optional 'speed' parameter to bl


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH 0/4] block: add optional 'speed' parameter to block-stream
Date: Mon, 23 Apr 2012 11:33:27 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/23/2012 09:39 AM, Stefan Hajnoczi wrote:
> This series is based on Luiz' latest QMP pull request at
> git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
> (d980956d5bfa9f4fd56c00a0b168c3c0f67bc0d2).  This dependency is necessary
> because this series conflicts with the block_stream -> block-stream rename.
> 
> Eric Blake raised concerns about the inability to start block jobs with a 
> speed
> limit.  Current the user needs to follow up the block-stream command with
> block-job-set-speed.  There is a window of time while the new block job is
> running but block-job-set-speed has not been processed yet.
> 
> This series adds an optional 'speed' parameter to block-stream so streaming 
> can
> be started with a speed limit that takes effect immediately.
> 
> I considered several other approaches, including adding a
> default_block_job_speed field to BlockDriverState but ultimately the cleanest
> solution is to pass in a speed parameter on job creation.  This way we do not
> change semantics of existing commands, we only add an optional parameter.  We
> also do not need to add state to BlockDriverState, which is already huge and
> messy.

I like the approach of adding a new optional parameter; that is a
workable solution for libvirt (that is, libvirt can assume that if the
spelling 'block-stream' is available, then so is the optional 'speed'
parameter, if this patch is included in time for qemu 1.1).  I concur
with Paolo's review points about questioning whether a new error is
necessary, or whether the error case should be reusing existing errors,
but libvirt should be able to cope with whatever error actually gets
returned, so respinning things to address Paolo's concerns shouldn't
cause me any grief.

Paolo's proposed 'drive-mirror' command will need the same treatment,
especially if we get 'drive-mirror' added in time for qemu 1.1.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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