qemu-devel
[Top][All Lists]
Advanced

[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!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]