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

["Daniel P. Berrange" <berrange@redhat.com>]

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 <mreitz@redhat.com> 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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|