On Fri, Dec 15, 2017 at 05:38:00PM +0100, Max Reitz wrote: > 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.
In terms of the I/O operations involved, image creation is a already a pretty slow process, particularly if pre-allocation is used which is common. So even QEMU's current slow (circa 300ms) startup time is a complete non-issue for image creation IMHO - it'll be dwarfed by the time to actually create the image. > On the other side, we can also add QAPI introspection to qemu-img. > (qemu-img already links to QAPI, so this should not be too hard.) > qemu-img will also need command-line introspection, though. I figure the qapi-ificiation is the hard & time consuming bit of work. Once that's done exporting it via both qemu-img & qemu-system* is quite straighforward. > Plan B: > libvirt can use qemu-img now with the currently supported options, > and as soon as libvirt needs anything better, we will have something > better done. > (Also, there is "qemu-img create -f $format -o help"! Because > parsing help texts has worked so well in the past.) 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 :|
