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

[Daniel P. Berrange]

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.

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