"Richard W.M. Jones" <rjo...@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!
