qemu-devel
[Top][All Lists]
Advanced

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

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


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [Qemu-block] Raw notes from a small block layer/QAPI/something pre-christmas meeting
Date: Wed, 20 Dec 2017 13:40:18 +0000
User-agent: Mutt/1.9.1 (2017-09-22)

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.

> 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?

The complexity with creating an empty file externally, and then writing
the image format into it is figuring out the right size to use for the
empty "file".

We could just create an empty file and let it grow-on-demand but this
only works for things which really are file backed.

The problem still exists for qcow2-over-LVM or  LUKS-over-iSCSI, etc,
where there's no way for QEMU to ever create the underlying LVM or
iSCSI volume. Indeed libvirt probably can't create them either - the
higher level mgmt app (OpenSTack/OVirt) would have to. I guess this
is where the work Stefan did for a "measure" command would come into
play perhaps.

I'm inclined to say though that if libvirt has to create the base layer
externally with qemu-img, we might as well just crete the entire thing
externally. I'm not seeing the obvious benefit to creating the file
with qemu-img, and formatting it with a QMP command.

I think where QMP becomes interesting / useful, over qemu-img is when
populating the file with data (eg a qemu-img convert equiv), since we
can get proper API for progress monitoring & cancelling via block jobs.

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 :|



reply via email to

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