[Top][All Lists]

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

Re: [Qemu-devel] live block copy/stream/snapshot discussion

From: Adam Litke
Subject: Re: [Qemu-devel] live block copy/stream/snapshot discussion
Date: Tue, 12 Jul 2011 12:47:49 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110419 Lightning/1.0b2 Thunderbird/3.1.9

On 07/12/2011 10:45 AM, Stefan Hajnoczi wrote:
> On Tue, Jul 12, 2011 at 9:06 AM, Kevin Wolf <address@hidden> wrote:
>> Am 11.07.2011 18:32, schrieb Marcelo Tosatti:
>>> On Mon, Jul 11, 2011 at 03:47:15PM +0100, Stefan Hajnoczi wrote:
>>>> Kevin, Marcelo,
>>>> I'd like to reach agreement on the QMP/HMP APIs for live block copy
>>>> and image streaming.  Libvirt has acked the image streaming APIs that
>>>> Adam proposed and I think they are a good fit for the feature.  I have
>>>> described that API below for your review (it's exactly what the QED
>>>> Image Streaming patches provide).
>>>> Marcelo: Are you happy with this API for live block copy?  Also please
>>>> take a look at the switch command that I am proposing.
>>>> Image streaming API
>>>> ===================
>>>> For leaf images with copy-on-read semantics, the stream commands allow the 
>>>> user
>>>> to populate local blocks by manually streaming them from the backing image.
>>>> Once all blocks have been streamed, the dependency on the original backing
>>>> image can be removed.  Therefore, stream commands can be used to implement
>>>> post-copy live block migration and rapid deployment.
>>>> The block_stream command can be used to stream a single cluster, to
>>>> start streaming the entire device, and to cancel an active stream.  It
>>>> is easiest to allow the block_stream command to manage streaming for the
>>>> entire device but a managent tool could use single cluster mode to
>>>> throttle the I/O rate.
>> As discussed earlier, having the management send requests for each
>> single cluster doesn't make any sense at all. It wouldn't only throttle
>> the I/O rate but bring it down to a level that makes it unusable. What
>> you really want is to allow the management to give us a range (offset +
>> length) that qemu should stream.
> I feel that an iteration interface is problematic whether the
> management tool or QEMU decide what to stream.  Let's have just the
> background streaming operation.
> The problem with byte ranges is two-fold.  The management tool doesn't
> know which regions of the image are allocated so it may do a lot of
> nop calls to already-allocated regions with no intelligence as to
> where the next sensible offset for streaming is.  Secondly, because
> the progress and performance of image streaming depend largely on
> whether or not clusters are allocated (it is very fast when a cluster
> is already allocated and we have no work to do), offsets are bad
> indicators of progress to the user.  I think it's best not to expose
> these details to the management tool at all.
> The only reason for the iteration interface was to punt I/O throttling
> to the management tool.  I think it would be easier to just throttle
> inside the streaming function.
> Kevin: Are you happy with dropping the iteration interface?
> Adam: Is there a libvirt requirement for iteration or could we support
> background copy only?

There is no hard requirement for iteration in libvirt.  However, I think
there is a requirement that we report some sort of progress to an end
user.  These operations can easily take many minutes (even hours) and
such a long-running operation needs to report progress.  I think the
current information returned by 'query-block-stream' is appropriate for
this purpose and should definitely be maintained.

Adam Litke
IBM Linux Technology Center

reply via email to

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