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

[Kevin Wolf <kwolf@redhat.com>]

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).

> -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). 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)

> Or:
> 
> qemu -blockdev id=blk2,format=raw,file=/path/to/base.img,cache=writeback \
>            -blockdev 
> id=blk1,format=qcow2,file=/path/to/leaf.img,backing_dev=blk2 \
>            -device ide-disk,blockdev=blk1,bus=0,unit=0
> 
> Or:
> 
> qemu -hda /path/to/leaf.img
> 
> And if a user really feels they need to modify the defaults, they can do:
> 
> qemu -hda /path/to/leaf.img -writeconfig myconf.cfg
> 
> And edit from there.
> 
>>> But honestly, I'm thoroughly confused about the distinction between
>>> protocol and format.  I had thought that protocols were a type of format
>>> and I'm not sure why we're making a distinction.
>>>      
>> Technically, they are mostly the same. Logically, they are not. You have
>> one image format driver (raw, qcow2, ...) that accesses its image data
>> through one or more stacked protocols (file, host_device, nbd, http, ...).
>>
>> In the past we've had quite some trouble because there was no clear
>> distinction. raw and file was the same. If you had an image on a block
>> device, you were asking for trouble.
>>    
> 
> 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 sure prefer the latter.  The brackets look like noise.  You need to
>>>>     understand protocol stacking for them to make any sense.
>>>>
>>>>     Regarding confusion caused by mixing format and protocol options: yes,
>>>>     the brackets force you to distinguish between protocol options and
>>>>     other options.  But I doubt that'll reduce confusion here.  Either you
>>>>     understand protocols.  Then I doubt you need brackets to unconfuse
>>>>     you.  Or you don't understand protocols.  Then whether to put an
>>>>     option inside or outside the brackets is voodoo.
>>>>
>>>>        
>>> If the above is necessary just to create a raw image, then we're doing
>>> something wrong in the block layer.  If should be possible to just say:
>>>
>>> -blockdev id=blk1,format=raw,file=fedora.img
>>>      
>> I think we all agree on this (although it contradicts what you said
>> above, because file is a property of the protocol). The question is how
>> to specify protocols explicitly.
> 
> 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.

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.

Kevin