Re: [Qemu-devel] [Qemu-block] Raw notes from a small block layer/QAPI/something pre-christmas meeting

[Peter Krempa]

On Wed, Dec 20, 2017 at 13:40:18 +0000, Daniel Berrange wrote:
> On Wed, Dec 20, 2017 at 02:33:54PM +0100, Kevin Wolf wrote:
> > Am 20.12.2017 um 11:57 hat Daniel P. Berrange geschrieben:
> > > On Wed, Dec 20, 2017 at 11:44:36AM +0100, Kashyap Chamarthy wrote:
> > > > On Mon, Dec 18, 2017 at 11:11:00AM +0100, Markus Armbruster wrote:
> > > > > Max Reitz <address@hidden> writes:
> > > > 
> > > > [...]
> > > > 
> > > > Thanks, Max, for the detailed notes.
> > > > 
> > > > > > Image creation in qemu-system-* vs. qemu-img:
> > > > > >   In order to get proper introspection for qemu-img create, we need 
> > > > > > a
> > > > > >   QAPI schema.  If we have a QAPI schema, we might as well add
> > > > > >   blockdev-create to QMP.
> > > > > >   As long as we do not have a really-none (null, void, ...) machine 
> > > > > > type
> > > > > >   for qemu-system-*, launching such a process just for creating an 
> > > > > > image
> > > > > >   will bring quite a bit of overhead (e.g. with -M none -accel 
> > > > > > qtest).
> > > > > >   However, as for libvirt, this is not exactly a regression since
> > > > > >   libvirt currently cannot create images at all (apart from 
> > > > > > implicitly
> > > > > >   through drive-mirror etc.).  Further work on voidifying 
> > > > > > qemu-system-*
> > > > > >   will improve performance.
> > > > > 
> > > > > Another thought: do we want to give qemu-system-* the necessary
> > > > > privileges for creating images?  Two cases: running with and without a
> > > > > guest.
> > > > 
> > > > Related: Just curious -- was it an explicit design decision to not give
> > > > `qemu-system-*` permissions to create disk images?
> > > 
> > > Our security model considers QEMU broadly untrustworthy, and so any 
> > > resources
> > > it needs to use must either be passed in by libvirt, or have permissions
> > > explicitly assigned to permit usage by QEMU. QEMU is allowed to create tmp
> > > files, and create RAM files for memory backing, but in general we don't 
> > > want
> > > to have QEMU able to create arbitrary files, only open things that are
> > > already created.
> > 
> > Which kind of suggests that libvirt should use an external qemu-img
> > process rather than a QMP command to create images?
> 
> That is my gut feeling, though Peter K might have other opinions as the
> person doing most libvirt work in this area.

Well then we need a way to do capability probing for qemu-img. And also
libvirt will then need a way to override the qemu-img binary on a per-VM
basis as we do with qemu binaries, so that users can switch to a more
capable binary.

If that will not be possible, block jobs for a VM might be impossible if
an old qemu-img is installed system-wide.

Also I really doubt it will save any qemu work when forcing us to do it
via qemu-img, since qemu-img still needs to be improved to support e.g.
creating an image on a multi-host gluster server [1], which currently is
not possible (basically we need the same capabilities as when opening an
image).


Peter


[1] You could argue, that if you select the properly functioning volfile
server from the list of servers configured by the user only one is
necessary for creating the image. Libvirt has no way of nowing which one
works though, so let's just have gluster figure it out by themselves.

signature.asc
Description: PGP signature