Re: [libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration
Am 07.09.2010 16:49, schrieb Anthony Liguori:
> Shouldn't it be a runtime option? You can use the very same
image with
> copy-on-read or copy-on-write and it will behave the same (execpt for
> performance), so it's not an inherent feature of the image file.
>
The way it's implemented in QED is that it's a compatible feature. This
means that implementations are allowed to ignore it if they want to.
It's really a suggestion.
Well, the point is that I see no reason why an image should contain this
suggestion. There's really nothing about an image that could reasonably
indicate "use this better with copy-on-read than with copy-on-write".
It's a decision you make when using the image.
So yes, you could have a run time switch that overrides the feature
bit
on disk and either forces copy-on-read on or off.
Do we have a way to pass block drivers run time options?
We'll get them with -blockdev. Today we're using colons for format
specific and separate -drive options for generic things.
> Doing it this way has the additional advantage that you need no
image
> format support for this, so we could implement copy-on-read for other
> formats, too.
>
To do it efficiently, it really needs to be in the format for the same
reason that copy-on-write is part of the format.
Copy-on-write is not part of the format, it's a way of how to use this
format. Backing files are part of the format, and they are used for both
copy-on-write and copy-on-read. Any driver implementing a format that
has support for backing files should be able to implement copy-on-read.
You need to understand the cluster boundaries in order to optimize
the
metadata updates. Sure, you can expose interfaces to the block layer to
give all of this info but that's solving the same problem for doing
block level copy-on-write.
The other challenge is that for copy-on-read to be efficiently, you
really need a format that can distinguish between unallocated sectors
and zero sectors and do zero detection during the copy-on-read
operation. Otherwise, if you have a 10G virtual disk with a backing
file that's 1GB is size, copy-on-read will result in the leaf being 10G
instead of ~1GB.
That's a good point. But it's not a reason to make the interface
specific to QED just because other formats would probably not implement
it as efficiently.
Kevin