Re: proposal: deprecate -readconfig/-writeconfig

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, May 14, 2020 at 10:40:40AM -0400, John Snow wrote:
>> 
>> 
>> On 5/14/20 4:56 AM, Daniel P. Berrangé wrote:
>> > On Thu, May 14, 2020 at 10:09:21AM +0200, Paolo Bonzini wrote:
>> >> IMHO configuration files are in general a failed experiment.  In
>> >> practice, they do not add much value over just a shell script because
>> >> they don't allow configuring all QEMU options, they are very much fixed
>> >> (by their nature).  I think it's more or less agreed that they are not
>> >> solving any problem for higher-level management stacks as well; those
>> >> would prefer to configure the VM via QMP or another API.
>> >>
>> >> So, any objections to deprecating -readconfig and -writeconfig?
>> > 
>> > Libvirt would like to have a config file for QEMU, but it would have
>> > to be one that actually covers all the config options QEMU supports,
>> > and ideally using a data format in common with that used for runtime
>> > changes. So for libvirt's needs the current readconfig is entirely
>> > useless.
>> > 
>> 
>> Yeah. In this sense, would a json/yaml config file help, under the
>> premise that you could just cat it into the pipe to configure a machine?
>> 
>> (Assuming we had proper runtime configuration commands, of course.)
>
> Yeah, the key thing is that you really want to be able to provide the
> whole initial config in one go as an atomic action. I don't want to
> issue 100 individual QMP commands to load each initial device. With
> that in mind it doesn't really matter whether you do
>
>   $ qemu -qmp stdio
>   (qmp) load-config /some/file.yaml
>
> vs
>
>   $ qemu -qmp stdio -load-config /some/file.yaml
>
> though the latter is probably slightly nicer as it lets you grep
> for the VM based on the filename visible in the CLI. 

Once QEMU can do the former, providing the latter should be trivial.
Not providing it would be unadvisable.

Yes, a management application that talks QMP anyway can be expected to
be quite happy with having to do initial configuration via QMP, with or
without a load-config command.

But human users won't be happy.  Having to use a wrapper program to feed
their configuration file to QMP adds undue complexity.

[...]