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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Sep 29, 2021 at 02:46:56PM +0300, Michael Tokarev wrote:
> 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.

The libvirt gitlab issue there is closed as not-a-bug, as the
user had told libvirt <disk type="file" > instead of
<disk type="block">.

The same mistake is present in the XML shown in the debian bug.

Even before the QEMU change, this mistake would cause trouble with
certain areas of libvirt functionality too, especially around
migration and snapshotting.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|