[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redesign of QEMU startup & initial configuration
From: |
Markus Armbruster |
Subject: |
Re: Redesign of QEMU startup & initial configuration |
Date: |
Thu, 13 Jan 2022 17:10:48 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
"Richard W.M. Jones" <rjones@redhat.com> writes:
> Sorry for very delayed reply ...
>
> On Thu, Dec 02, 2021 at 07:57:38AM +0100, Markus Armbruster wrote:
>> 1. QMP only
>>
>> Management applications need to use QMP for monitoring anyway. They
>> may want to use it for initial configuration, too. Libvirt does.
>>
>> They still need to bootstrap a QMP monitor, and for that, CLI is fine
>> as long as it's simple and stable.
>
> libguestfs actually does not use the QMP monitor but manages to
> configure eveything from the command line just fine. I've attached
> below a typical example. (Of course we can use libvirt too, but still
> for many configurations libvirt causes problems unfortunately).
This is just the example I've been looking for: an application that
doesn't really need "QMP only". Thanks!
>> Human users struggle with inconsistent syntax, insufficiently expressive
>> configuration files, and huge command lines.
>
> One advantage of "huge command lines" is that they document the
> configuration of qemu quite well. I know it's only an approximation,
> but in many cases it's exactly what we want. It is frequently the
> case when troubleshooting that we ask the user "what is the qemu
> command line", and they can get that from the libvirt log file or
> through "ps".
Yes.
> So we need to consider this and make sure that everything is changed
> so we don't regress. libguestfs will need substantial changes and
I think we should try to accomodate how libguestfs wants to use QEMU.
> libvirt must dump the full configuration (qinfo or whatever) to the
> log file.
I believe the entire QMP traffic needs to be logged.
CLI + configuration files are all or nothing: if QEMU starts, all, else
nothing. When you configure via QMP, any command may fail, and these
failures are not fatal.
In general, we can also have run-time configuration changes via QMP,
such as hot plug. Another reason to log all QMP traffic.
> I don't really disagreee with anything else you wrote however.
Thanks!