[libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration

[Anthony Liguori]

On 09/07/2010 10:20 AM, Kevin Wolf wrote:
> Am 07.09.2010 17:11, schrieb Anthony Liguori:
>    
>> On 09/07/2010 10:02 AM, Kevin Wolf wrote:
>>      
>>> 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.
>>>
>>>        
>> 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.

>> IOW, let's say I'm an image distributor and I want to provide my images
>> in a QED format that actually streams the image from an http server.  I
>> could provide a QED file without a copy-on-read bit set but I'd really
>> like to convey this information as part of the image.
>>
>> You can argue that I should provide a config file too that contained the
>> copy-on-read flag set but you could make the same argument about backing
>> files too.
>>      
> No. The image is perfectly readable when using COW instead of COR. On
> the other hand, it's completely meaningless without its backing file.
>    

N.B. the whole concept of compat features in QED is that if the features 
are ignored, the image is still perfectly readable.  It's extra 
information that let's an implementation to smarter things with a given 
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.
>>>
>>>        
>> That's right.  I think I'd rather wait for -blockdev.
>>      
> Well, then I consider -blockdev a dependency of QED (the copy-on-read
> part at least) and we can't merge it before we have -blockdev.
>    

If we determine that having copy-on-read be a part of the image is 
universally a bad idea, then I'd agree with you.  Keep in mind, I don't 
expect to merge the cor or streaming stuff with the first merge of QED.

I'm still not convinced that having cor as a compat feature is a bad 
idea though.

>> You really can't do as good of a job in the block layer because you have
>> very little info about the characteristics of the disk image.
>>      
> I'm not saying that the generic block layer should implement
> copy-on-read. I just think that it should pass a run-time option to the
> driver - maybe just a BDRV_O_COPY_ON_READ flag - instead of having the
> information in the image file. From a user perspective it should look
> the same for qed, qcow2 and whatever else (like copy-on-write today)
>    

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.

Regards,

Anthony Liguori

> Kevin
>