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

[Anthony Liguori]

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
>