Re: blockdev driver=file,filename=/dev/block forbidden?

[Michael Tokarev]

29.09.2021 14:35, Daniel P. Berrangé wrote:
> On Wed, Sep 29, 2021 at 02:21:58PM +0300, Michael Tokarev wrote:
> > Commit 8d17adf34f501ded65a106572740760f0a75577c
> > "block: remove support for using "file" driver with block/char devices"
> > explicitly forbids usage of file driver for block devices.
> >
> > But _why_?
> >
> > Hasn't we always used file for everything on *nix? And what's the _actual_
> > difference between file and host_device?
>
> There are various things QEMU does differently for plain files vs
> block devices. The check for read-only volume, determining data
> transfer size, media geometry, supporting discard. This is seen
> in the BlockDriver structs that have different callbacks for each.

Well, I took a look at file-posix.c meanwhile.
And I see no actual reason to require the user to change driver.
It definitely is not user-friendly :)

It can open the file (with 'file' driver) and check if it is a
regular file or a block (or char) device, and use corresponding
callbacks in each case. Or just remember the "blockiness" of the
underlying file and do a simple if() around it.

Having the user to *require* to change driver like this is.. strange.

I often use symlinks in our VM scripts which points to file or a block
device - eg, a vm with a name grabs all /guest/name-foo.img - be these
regular files or symlinks to /dev/mapper/foo..  And while it is
not that big issue to change a script to add detection of blkdev/file,
it is definitely not as easy for a user. And the thing is again - why
qemu can't do that automatically, this is exactly the place where computers
are good for..

Yes, some "sub-parameters" are different.  There, we can either error-out
for a given parameter when it can't be used for a given file "type", or
can have some relaxed warning instead.  But when there's no such specific
parameters are given, I for one see no reason to require the user to
change configuration when qemu itself can trivially figure it out..

I can (try to) produce a patch of this theme.

> > Please note this change has been added to qemu long before libvirt has
> > been adapted (I guess there's no released libvirt can be used with
> > qemu 6.0+).
>
> Can you show your libvirt guest XML config that is causing trouble, as
> it has done the right thing here for  a long while AFAIK, so I suspect
> a mis-configuration.

This started as https://bugs.debian.org/993688 which leads to
https://gitlab.com/libvirt/libvirt/-/issues/212 which created only
3 weeks ago. While the commit in question has been committed
in February.

Thanks!

/mjt