Re: [Qemu-devel] Re: RFC v2: blockdev_add & friends, brief rationale, QMP docs

[Anthony Liguori]

On 06/17/2010 03:20 AM, Kevin Wolf wrote:
> Am 16.06.2010 20:07, schrieb Anthony Liguori:
>    
> > >    But it requires that
> > > everything that -blockdev provides is accessible with -drive, too (or
> > > that we're okay with users hating us).
> > >
> > >        
> > I'm happy for -drive to die.  I think we should support -hda and
> > -blockdev.
> >      
> -hda is not sufficient for most users. It doesn't provide any options.
> It doesn't even support virtio. If -drive is going to die (and we seem
> to agree all on that), then -blockdev needs to be usable for users (and
> it's only you who contradicts so far).
>    

I've always thought we should have a -vda argument and an -sda argument 
specifically for specifying virtio and scsi disks.

> > -blockdev should be optimized for config files, not single
> > argument input.  IOW:
> >
> > [blockdev "blk2"]
> >    format = "raw"
> >    file = "/path/to/base.img"
> >    cache = "writeback"
> >
> > [blockdev "blk1"]
> >     format = "qcow2"
> >     file = "/path/to/leaf.img"
> >     cache="off"
> >     backing_dev = "blk2"
> >
> > [device "disk1"]
> >     driver = "ide-drive"
> >     blockdev = "blk1"
> >     bus = "0"
> >     unit = "0"
> >      
> You don't specify the backing file of an image on the command line (or
> in the configuration file).

But we really ought to allow it.  Backing files are implemented as part 
of the core block layer, not the actual block formats.  Today the block 
layer queries the block format for the name of the backing file but gets 
no additional options from the block format.  File isn't necessarily 
enough information to successfully open the backing device so why treat 
it specially?

I think we should keep the current ability to query the block format for 
a backing file name but we should also support hooking up the backing 
device without querying the block format at all.  It makes the model 
much more elegant IMHO because then we're just creating block devices 
and hooking them up.  All block devices are created equal more or less.

>   It's saved as part of the image. It's more
> like this (for a simple raw image file):
>
> [blockdev-protocol "proto1"]
>     protocol = "file"
>     file = "/path/to/image.img"
>
> [blockdev "blk1"]
>     format = "raw"
>     cache="off"
>     protocol = "proto1"
>
> [device "disk1"]
>     driver = "ide-drive"
>     blockdev = "blk1"
>     bus = "0"
>     unit = "0"
>
> (This would be Markus' option 3, I think)
>    

I don't understand why we need two layers of abstraction here.  Why not 
just:

[blockdev "proto1"]
  protocol = "file"
  cache = "off"
  file = "/path/to/image.img"

Why does the cache option belong with raw and not with file and why 
can't we just use file directly?As Christoph mentions, we really don't 
have stacked protocols and I'm

> > not sure they make sense.
> >      
> Right, if we go for Christoph's suggestion, we don't need stacked
> protocols. We'll have stacked formats instead. I'm not sure if you like
> this any better. ;-)
>
> We do have stacking today. -hda blkdebug:test.cfg:foo.qcow2 is qcow2 on
> blkdebug on file. We need to be able to represent this.
>    

I think we need to do stacking in a device specific way.  When you look 
at something like vmdk, it should actually support multiple leafs since 
the format does support such a thing.  So what I'd suggest is:

[blockdev "part1"]
  format = "raw"
  file = "image000.vmdk"

[blockdev "part2"]
  format = "raw"
  file = "image001.vmdk"

[blockdev "image"]
  format = "vmdk"
  section0 = "part1"
  section1 = "part2"

Note, we'll need to support this sort of model in order to support a 
disk that creates an automatic partition table (which would be a pretty 
useful feature).  For blkdebug, it would look like:

[blockdev "disk"]
  format = "qcow2"
  file = "foo.qcow2"

[blockdev "debug"]
  format = "blkdebug"
  blockdev = "disk"

> > I think raw doesn't make very much sense then.  What's the point of it
> > if it's just a thin wrapper around a protocol?
> >      
> That it can be wrapped around any protocol. It's just about separating
> code for handling the content of an image and code for accessing the image.
>
> Ever tried something like "qemu-img create -f raw /dev/something 10G"?
> You need the host_device protocol there, not the file protocol. When we
> had raw == file this completely failed. And it's definitely reasonable
> to expect that it works because the image format _is_ raw, it's just not
> saved in a file.
>    

No, I don't actually thing it's reasonable.  There's nothing meaningful 
that command can do.  Also, I've never understand creating qcow2 images 
on a physical device.  qcow2 needs to grow dynamically and physical 
devices can't.

I understand that we need to support the later use case but I don't 
think creating this layer of user-visible abstraction is the right thing 
to do.  This is an obscure use case and it shouldn't be the model that 
we force upon our users.

> Or the famous qcow2 images on block devices. Why did qemu guess the
> format correctly when qcow2 was saved in a file, but not on a host
> device? This was just inconsistent.
>
> I've had more than one bug report about things like this which are
> magically fixed when you do the layering right.
>    

Beyond qcow2 on physical devices, when does this issue actually come up?

Regards,

Anthony Liguori

> Kevin
>