Re: [libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration
On 09/07/2010 10:39 AM, Kevin Wolf wrote:
Am 07.09.2010 17:30, schrieb Anthony Liguori:
> On 09/07/2010 10:20 AM, Kevin Wolf wrote:
>
>> Am 07.09.2010 17:11, schrieb Anthony Liguori:
>>
>>> Copy-on-read is, in many cases, a property of the backing file because
>>> it suggests that the backing file is either very slow or potentially
>>> volatile.
>>>
>>>
>> The simple copy-on-read without actively streaming the rest of the image
>> is not enough anyway for volatile backing files.
>>
>>
> But as a web site owner, it's extremely useful for me to associate
> copy-on-read with an image because it significantly reduces my bandwidth.
>
> I have a hard time believing this isn't a valuable use-case and not one
> that's actually pretty common.
>
As a web site user, I don't necessarily want you to control the
behaviour of my qemu. :-)
That's why I understand your argument about -blockdev and making sure
all compat features can be overridden. I'm happy with that as a
requirement.Okay, the only place I'm disagreeing slightly is that I
think an image
> format should be able to request copy_on_read such that the
default
> behavior if an explicit flag isn't specified is to do what the image
> suggests we do.
>
Maybe we can agree on that. I'm not completely decided yet if allowing
the image to contain such a hint is a good or a bad thing.
It's a tough space. We don't want to include crazy amounts of metadata
(and basically become OVF) but there's metadata that we would like to have.
backing_format is a good example. It's a suggestion and it's something
you really want to let a user override.
Regards,
Anthony Liguori
Kevin