qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive options
Date: Wed, 17 Jul 2013 14:58:10 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 17.07.2013 um 14:36 hat Paolo Bonzini geschrieben:
> Il 17/07/2013 11:42, Fam Zheng ha scritto:
> > This option allows overriding backing hd of drive. If the target drive
> > exists, it's referenced as the backing file and refcount incremented.
> > 
> > Example:
> >     qemu-system-x86_64 -drive \
> >         file.filename=foo.qcow2,if=none,id=foo \
> >         -drive file=bar.qcow2,backing=foo
> 
> I guess this is where we need the soft reference.
> 
> This has a _lot_ of potential for misuse, I think Kevin bashed me and
> Federico very heavily when we tried to do something similar.

Not sure what exactly I "bashed" you for, but I think this is really the
right thing to do, and it's the general direction we're headed for with
blockdev-add. The user manages his BlockDriverStates and connects them
as he sees fit. The defaults of qemu are only used when the user doesn't
override them (and libvirt is going to override most to use fd passing).

My expectation is, admittedly, that it's hard to get right from where we
stand today, because of the coupling of BlockDriverStates with guest
devices, but with the refcounting patches (which I haven't reviewed
yet), maybe one of the biggest concerns is addressed.

This is basically restarting the discussion where I suggested to give
the targets of a block job names so that they can be reused. It's about
the same kind of misuse that becomes possible and that we need to
protect against.

Kevin



reply via email to

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