qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Image streaming and live block copy


From: Dor Laor
Subject: Re: [Qemu-devel] Image streaming and live block copy
Date: Mon, 27 Jun 2011 12:13:10 +0300
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10 ThunderBrowse/3.3.5

On 06/27/2011 10:48 AM, Kevin Wolf wrote:
Am 26.06.2011 14:50, schrieb Dor Laor:
On 06/24/2011 12:28 PM, Stefan Hajnoczi wrote:
On Sun, Jun 19, 2011 at 5:02 PM, Dor Laor<address@hidden>   wrote:
On 06/18/2011 12:17 PM, Stefan Hajnoczi wrote:

On Sat, Jun 18, 2011 at 10:15 AM, Stefan Hajnoczi<address@hidden>
   wrote:

On Fri, Jun 17, 2011 at 1:31 PM, Marcelo Tosatti<address@hidden>
   wrote:

On Thu, Jun 16, 2011 at 04:30:18PM +0100, Stefan Hajnoczi wrote:

On Thu, Jun 16, 2011 at 11:52:43AM -0300, Marcelo Tosatti wrote:
This approach does not use the backing file feature?

blkstream block driver:

- Maintain in memory whether given block is allocated in local image,
if not, read from remote, write to local. Set block as local.
Local and remote simply two block drivers from image streaming driver
POV.
- Once all blocks are local, notify mgmt so it can switch to local
copy.
- Writes are mirrored to source and destination, minding guest writes
over copy writes.

We open the remote file read-only for image streaming and do not want
to
mirror writes.

Why not? Is there any disadvantage of mirroring writes?

Think of the use case with a Fedora master image over NFS.  You want a
local clone of that master image and use the stream command to copy
the data from the master image into the local clone.

You cannot modify that master image because other VMs are using it too
and/or you want to be able to clone new VMs from it in the future.

BTW the workaround is to create two local images:
1. Local clone with master image as a backing file.  This is the live
block copy source image.
2. Local image without a backing file.  This is the live block copy
destination image.

But this is not very elegant.  Writes get mirrored so that crash recovery
works.

There is an easier work around for image streaming using live block copy
(mirror approach):
   - Create the dst VM as an empty new COW image of the src (even over
     the non shared storage, use some protocol tag for the src location
     like nbd://original_path/src_file_name)

Migration and non-shared storage has come up a few times in this
discussion.  But both live block copy and image streaming need access
to source and destination - they do not have explicit non-shared
storage support.  I think non-shared and using nbd:// is orthogonal to
the discussion.  Just want to check that you agree and I haven't
missed something?

You're right, I was mainly trying to be as general as possible.

I think there is one important point to consider for using NBD: You
always see a single image on the NBD client, which could in fact have a
backing file chain on the source. So bdrv_is_allocated() doesn't work
over NBD, which becomes interesting when you want to share a backing
file with the new copy.

What is we'll use iscsi? Will the client have a matching iscsi verb to detect whether a certain block is in fact a unallocated and we'll be able to use this for our benefit? Of course it will make the non shared storage case more complex.




Kevin






reply via email to

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