Am 05.09.2018 um 16:02 hat Peter Krempa geschrieben:
> On Wed, Sep 05, 2018 at 08:48:15 -0500, Eric Blake wrote:
> > On 09/05/2018 07:38 AM, Peter Krempa wrote:
> > 
> > > block-commit is able to reopen the format layers and works as expected.
> > > 
> > > Unfortunately though the 'read-only' option is actually useful as the
> > > curl-driver does not work without it:
> > > 
> > > -blockdev {"driver":"http","url":"http://ftp.sjtu.edu.cn:80/ubuntu-cd/12.04/ubuntu-12.04.5-alternate-amd64.iso","node-name":"libvirt-2-storage","discard":"unmap"}: curl block device does not support writes
> > > 
> > > We obviously can encode that knowledge into libvirt but it will be hard
> > > to undo if qemu eventually supports writes in the curl driver.
> > > 
> > > Which other protocol drivers don't support writes? in case we have to go
> > > this way.
> > 
> > When an NBD server exported an image as read-only, the NBD block client
> > cannot request write permissions.  But that's a runtime discovery process,
> > not a limitation of the block driver itself.
> 
> Hmmm, that's unfortunate. Because in some cases we don't know this fact
> upfront in libvirt and we also don't know whether an user might attempt
> to block-commit at some time.
> 
> We probably do need a way to specify that we want
> 'read-write-if-possible' behaviour.

So after all, maybe we should try whether a read-only=auto is possible,
which would reopen the image file on demand (depending on whether some
user of the node requested BLK_PERM_WRITE etc.)

Kevin