Re: Making QEMU easier for management tools and applications

[Daniel P . Berrangé]

On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote:
> 
> 
> On 1/23/20 2:01 PM, Daniel P. Berrangé wrote:
> > IOW, the difficulty with configuring QEMU via JSON is not the fault
> > of JSON itself, it is the lack of knowledge amongst users and docs,
> > compounded by our never ending "improvements" to the human syntax.
> > There are other factors too, such as our only partial coverage of
> > config using JSON - some is only possible via the CLI still.
> > 
> 
> I'm fine with getting rid of HMP entirely, I think. It's a weird
> interface with bizarre behavior that's hard to support.
> 
> There's a few commands in there we just don't support at all, but maybe
> it's time to start deprecating one-by-one any of the individual commands
> that are better served by QMP these days, to send the message that HMP's
> days are numbered.
> 
> Bye-bye!
> 
> As for the CLI, well, that's part of the discussion at hand...
> 
> > 
> > I guess my point is that with a scrap & startover view point, we
> > should arguably completely ignore the design question of how to
> > flatten JSON for humans/command line, as it is the wrong problem.
> > Instead focus on the problem of making use of JSON the best way
> > to deal with QEMU both functionally and practically, for humans
> > and machines alike.
> > 
> 
> Well, sure. The context of this email was qmp-shell though, which is
> meant to help facilitate the entry of JSON commands so that you *can*
> indeed just forego the CLI/HMP entirely.
> 
> If you are of the opinion that every user of QEMU should be copy/pasting
> JSON straight into a socket and we should delete qmp-shell, that's
> certainly a fine opinion.

I think part of the pain of qmp-shell comes from the very fact that
it is trying to be an interactive shell. This points people towards
interactively typing in the commands, which is horrific when you get
anywhere near the JSON, or even dot-notation traditional commands.

If it was just a qmp-client that was single shot, we'd encourage
people to create the JSON in a sensible way - vim/emacs/whatever.

Bash/dash/zsh/$whatever is their interactive shell, with massively
more features than qmp-shell. You have command history, autocomplete,
conditional and looping constructs, and everything a normal shell
offers.

The only strong reason for qmp-shell to be interactive would be if
the initial protoocl handshake was too slow. I can't see that being
a problem with QMP. 

> I'm coming from the side that I love qmp-shell; I find it useful, but it
> has some syntax problems. How do I solve them? Is there a way to solve
> them? QAPI is here to stay, and QAPI involves hierarchical data. That
> data is usually best represented by something like json or yaml, but
> those are hard to type in a shell.
> 
> What do we do about that?

Here's one conceptual vision of how a better QEMU might look:

  * qemu-runtime-$TARGET

    A binary that contains the implementation for the machine
    emulator for $TARGET.

    This has no command line arguments except for a UNIX
    socket path which is a QMP server


  * qemu-launcher-$TARGET

    A binary that is able to launch qemu-runtime-$TARGET
    with jailers active.

    This has no command line arguments except for a pair
    of UNIX socket paths. One is a QMP server, the other
    is the path for the QMP of qemu-runtime-$TARGET.

    Commands it processes will be in automatically proxied
    through to the qemu-runtime-$TARGET QMP, with appropriate
    jailer updates being done in between.


  * qemu-client

    A binary that speaks QMP, connects, runs a single command,
    disconnects.

    It is used to talk to either qemu-runtime-$TARGET or
    qemu-launcher-$TARGET, depending on whether the mgmt app
    or user wants to be making use of the jailer facilities
    or not.  


  * qemu-system-$TARGET

    The current binaries that exist today.

    qemu-system-$TARGET should not be part of our formal
    stability promise. We won't gratuitously / knowingly
    break without good reason, but we will accept that
    breakage can happen. Stability is only offered by
    the qemu-{runtime,launcher}-$TARGET.

    Several choices for their future in long term:

      - Leave them as-is and basically ignore them
        whereever practical going forward, so we
        minimally worry about backcompat breakage

      - Plan to re-write them so that they are simply
        a shim the forks+execs qemu-runtime-$TARGET
        and does syntax translation from CLI/HMP/QMP.

      - Deprecate them with a view to deletion entirely
        in $NNN years. For some large-ish value of NNN,
        given how well known they are


Example usage:

1. Launch the QEMU runtime for the desired target

     $ qemu-runtime-x86_64 myvm.sock

2. Load the configuration to define the VM

   $ cat myvm.yaml
   commands:
     - machine_declare:
         name: pc-q35-5.0
         ...
     - blockdev_add:
         ...
     - device_add:
         ...
     - blockdev_add:
         ...
     - device_add:
         ...
   $ qemu-client myvm.sock myvm.yaml


3. Hotplug a disk

   $ cat mynewdisk.yaml
   commands:
     - blockdev_add:
         ...
     - device_add:
         ...
   $ qemu-client myvm.sock mynewdisk.yaml


3. Hotunplug a disk

   $ cat myolddisk.yaml
   commands:
     - device_del:
         ...
     - blockdev_del:
         ...
   $ qemu-client myvm.sock myolddisk.yaml

Using jailers, just means adding in a use of qemu-launcher-$TARGET
at the start.


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