On Wed, Jan 11, 2023 at 04:49:14PM +0000, Richard W.M. Jones wrote:
On Wed, Jan 11, 2023 at 11:34:50AM -0500, Stefan Hajnoczi wrote:
On Sat, Jan 07, 2023 at 07:44:37PM +0000, Richard W.M. Jones wrote:
>
> This is upstream in nbdkit now:
> https://gitlab.com/nbdkit/nbdkit/-/tree/master/plugins/blkio
>
> Another question:
>
> (6) vhost-user + "read-only" property acts a bit strangely. After
> opening virtio-blk-vhost-user it throws an EROFS error if you try to
> "blkio_start" it. However if you set the "read-only" property to true
> then it's OK to start it, and subsequent read operations work too.
>
> I would expect that any device can be started without needing to set
> this property, and in general I don't understand why vhost-user is r/o
> since everything I read about it seems to indicate it's a general
> purpose writable protocol.
I guess the vhost-user-blk server is read-only and that's why it's
refusing to blkio_start() unless readonly was set to true.
If you're using qemu-storage-daemon, set the writable=on parameter on
the export.
So it turned out to be the case. Alberto pointed out that unless you
set writable=on explicitly, q-s-d makes the export read-only. This
was the reverse of what I expected. But it is covered in the q-s-d
man page.
But about libblkio: The problem is basically you must know if the
export is read-only or not before you connect. For a readonly
vhost-user export this is the observed behaviour:
blkio_create ==> OK
blkio_get_bool ("read-only") ==> returns false
blkio_connect ==> OK
blkio_get_bool ("read-only") ==> returns false
blkio_start ==> fails "Device is read-only"
At least after connecting it seems we should be able to find out that
the export is read-only.
Yes, indeed IIUC we could take this information, but currently
"read-only" property for virtio-blk is not filled by querying the
device.
At this point I wonder if for virtio-blk devices we should provide the
"read-only" property not writable (sorry for the confusion...) so that
it reflects whether the device is read-only or not.
Otherwise we could also leave it writable, but surely after the connect
we would have to set it with the value exported from the device and
allow the user to change it before the start (I think it's a bit
different from what we do in io-uring, or maybe it is comparable when we
use "fd" instead of "path" in the io-uring driver).
Thanks,
Stefano
_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
