Re: Making QEMU easier for management tools and applications

[Kevin Wolf <kwolf@redhat.com>]

Am 24.01.2020 um 10:50 hat Daniel P. Berrangé geschrieben:
> On Thu, Jan 23, 2020 at 04:07:09PM -0500, John Snow wrote:
> > 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.

I don't see how this is sensible. QMP commands are something that I
reuse even less than VM configurations, so creating a one-off file for
each would take me a lot more time and I would still have to type the
same JSON code that I have to type with -qmp stdio.

The reason it is and should be an interactive shell is that I'm
interacting with it. Switching back and forth between a text editor and
a shell to actually send the command to QEMU would make things only even
more cumbersome than they already are.

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

If I wanted to program a QMP client, I would use Python. For me,
conditionals and loops are completely out of scope for a QMP shell. I
just want an easy way to tell QEMU to do something specific.

A command history already exists for qmp-shell. It's better than bash
because it doesn't mix QMP history with whatever else I do on my
computer.

Autocomplete in qmp-shell doesn't exist, as far as I know, but if
implemented, it could be a lot more useful than bash completion because
it could offer key completion based on the QMP schema.

This is in fact a big part of the problem that qmp-shell really needs to
solve before it can replace HMP: How to make writing commands at least
almost as simple as with HMP. If I can just press tab a few times to
cycle through the available options for the command, that would already
be a massive improvement over writing JSON manually (which you would
still have to do with your text-file based approach, without any
QMP-specific support).

The other part that it needs to solve is how to be available by default
without specifying anything on the command line. Basically, if I press
Ctrl-Alt-2, I want to get to a monitor shell. If that shell is
implemented internally or by an external Python process, I don't mind.

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

Speed would be the least of my concerns. This is about manual use, and
it already takes me a while to type in my commands.

> 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

Just to compare, this is what the human user oriented flow looks like
today:

1. qemu-system-x86_64 -M pc-q35-5.0 -drive if=virtio,... -cdrom ...

2. <Press Ctrl-Alt-2 to get to the HMP shell>
   (qemu) drive_add ...
   <Press Ctrl-Alt-1 to get back to the guest>

3. <Press Ctrl-Alt-2 to get to the HMP shell>
   (qemu) device_del ...
   <Press Ctrl-Alt-1 to get back to the guest>

This is what we're competing with, and honestly I don't see how your
qemu-runtime-*/qemu-client based flow comes even close to it in terms of
usability.

QMP, JSON and YAML may be nice machine interfaces, but having nice
machine interfaces doesn't mean that you shouldn't also have something
that is suitable for humans. qmp-shell is trying to be that, and while
it leaves much to be desired in its current state, replacing it with
even more machine-friendly stuff that is cumbersome for humans isn't the
right answer.

Kevin