qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] Raw notes from a small block layer/QAPI/so


From: Kevin Wolf
Subject: Re: [Qemu-block] [Qemu-devel] Raw notes from a small block layer/QAPI/something pre-christmas meeting
Date: Wed, 20 Dec 2017 14:33:54 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

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?

Or would libvirt only create an empty file externally and then use QMP
to create some image format in it? In other words, it would only ever
use the QMP command to create formats like qcow2, but it would never use
it to create the file-posix layer?

Kevin



reply via email to

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