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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Oct 17, 2017 at 05:47:03PM +0200, Igor Mammedov wrote:
> On Tue, 17 Oct 2017 16:35:15 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
> 
> > 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.
> is there another alternative for usecase where one option values depends (-numa cpu)
> on values of another option values (-M + -smp + -cpu)?
>  so far we have 2 options on the table:
>    1: do configuration at runtime like in this series
>    2: start qemu 2 times
>         1st to query cpu layout and
>         2nd add -numa options using data from the 1st step

Conceptually the problem occurs in places where libvirt does not fully
specifiy the object being created, leaving QEMU todo some config internally.
The elephant in the room in this regard is '-machine', since the machine
baseboard implies creation of a variety of embedded devices. Libvirt has
embedded knowledge about what device buses are assocaited with each machine
type (ie ISA, PCI, PCI-X, etc).  In theory this information could be
introspectable ahead of time because the info about what controllers are
associated with 'pc' or 'q35' is static. In practical terms though, the
QEMU code for populating machines is not structured in a way that would
allow such introspection without instantiating the machine type.

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