qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] commit: Add top-node/base-node


From: Peter Krempa
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 1/2] commit: Add top-node/base-node options
Date: Wed, 5 Sep 2018 14:38:13 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

On Tue, Sep 04, 2018 at 17:34:36 +0200, Kevin Wolf wrote:
> Am 04.09.2018 um 17:00 hat Peter Krempa geschrieben:
> > On Tue, Sep 04, 2018 at 16:42:17 +0200, Alberto Garcia wrote:
> > > On Tue 04 Sep 2018 04:17:30 PM CEST, Peter Krempa wrote:

[...]

> > I remember being told some time ago to specify both layers explicitly.
> > Since it's not yet enabled in libvirt we theoretically could change to
> > one -blockdev for format+protocol but in that case we need some kind
> > of guarantee that every (even new) feature will work with it.
> > 
> > Switching between those approaches once we enable it upstream will not
> > be possible without adding a lot of compatibility code.
> 
> Yeah, I think specifying both layers explicitly is cleaner. This should
> probably be solved some way inside QEMU.
> 
> The read-only option for the backend isn't that useful anyway. Maybe we
> should do away with it, at least for its current purpose, and just rely
> on write permissions taken by parents. We could then either silently
> ignore (and deprecate) the read-only backend option or we could change
> its semantics to mean "never allow a writer on this node".

So I tried that approach and it seems to work just fine with files
including sharing part of the read-only backing chain with other VMs
without the image locking mechanism ruining the day.

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.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]