Re: [Qemu-devel] [RFC 4/6] CLI: add -paused option

[Daniel P. Berrange]

On Tue, Oct 17, 2017 at 05:21:13PM +0200, Laszlo Ersek wrote:
> On 10/17/17 16:48, Daniel P. Berrange wrote:
> > On Mon, Oct 16, 2017 at 07:01:01PM +0200, Paolo Bonzini wrote:
> >> On 16/10/2017 18:59, Eduardo Habkost wrote:
> >>>> +DEF("paused", HAS_ARG, QEMU_OPTION_paused, \
> >>>> +    "-paused [state=]postconf|preconf\n"
> >>>> +    "                postconf: pause QEMU after machine is 
> >>>> initialized\n"
> >>>> +    "                preconf: pause QEMU before machine is 
> >>>> initialized\n",
> >>>> +    QEMU_ARCH_ALL)
> >>> I would like to allow pausing before machine-type is selected, so
> >>> management could run query-machines before choosing a
> >>> machine-type.  Would that need a third "-pause" mode, or will we
> >>> be able to change "preconf" to pause before select_machine() is
> >>> called?
> >>>
> >>> The same probably applies to other things initialized before
> >>> machine_run_board_init() that could be configurable using QMP,
> >>> including but not limited to:
> >>> * Accelerator configuration
> >>> * Registering global properties
> >>> * RAM size
> >>> * SMP/CPU configuration
> >>
> >> Should (or could) "-M none" be changed in a backwards-compatible way to
> >> allow such preconfiguration?  For example
> >>
> >>   qemu -M none -monitor stdio
> >>   (qemu) machine-set-options pc,accel=kvm
> >>   (qemu) c
> > 
> > Going down this route has pretty major implications for the way libvirt
> > manages QEMU, and support / debugging of it. When you look at the QEMU
> > command line libvirt uses it will be almost devoid of any useful info.
> > So it will be more involved job to figure out just how QEMU is configured.
> > This also means it is difficult to replicate the config that libvirt has
> > used, outside of libvirt for sake of debugging.
> > 
> > I also think it will have pretty significant performance implications
> > for QEMU startup. To configure a guest via the monitor is going to
> > require a huge number of monitor commands to be executed to replicate
> > what we traditionally configured via ARGV. While each monitor command
> > is not massively slow, the round-trip time of each command will quickly
> > add up to several 100 milliseconds, perhaps even seconds in the the
> > case of very large configs. 
> > 
> > Maybe we ultimately have no choice and this is inevitable, but I am
> > pretty wary of going in the direction of launching bare QEMU and
> > configuring everything via a huge number of monitor calls.
> 
> Where's the sweet spot between
> - configuring everything dynamically, over QMP,
> - and invoking QEMU separately, for querying capabilities etc?

The key with the way we currently invoke & query QEMU over QMP to detect
capabilities is that this is not tied to a specific VM launch process.
We can query capabilities and cache them until such time as we detect
a QEMU binary change. So this never impacts on the startup performance
of individual VMs. The caching is critical, because querying capabilities
is actually quite time intensive already, taking many seconds to query
capabilities on all the different target binaries we have.

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