[PATCH v2] qemu: add append mode config for serial file

[Oleg Vasilev]

On 10.01.2023 16:35, Daniel P. Berrangé wrote:
> On Tue, Jan 10, 2023 at 04:20:59PM +0600, Oleg Vasilev wrote:
>>
>>
>> On 10.01.2023 15:09, Martin Kletzander wrote:
>>> On Tue, Jan 10, 2023 at 09:03:40AM +0000, Daniel P. Berrangé wrote:
>>>> On Tue, Jan 10, 2023 at 02:42:34PM +0600, Oleg Vasilev wrote:
>>>>> Serial log file contains lots of useful information for debugging
>>>>> configuration problems. It makes sense to preserve the log in between
>>>>> restarts, so that one can later figure out what was going on. Before
>>>>> that, we could do that on a per-domain basis, now we can configure it
>>>>> once for all domains.
>>>>
>>>> IMHO this is the job of the mgmt app that is using libvirt.
>>>>
>>>> We've got a few places in qemu.conf that interact with the
>>>> guest config, but I largely consider them to be historical
>>>> mistakes that shouldn't be added to.
>>>>
>>>> Adding this setting specifically for serial devs is opening
>>>> up a can of worms IMHO. eg what if you have multiple serial
>>>> ports and only want one of them in append mode. There are
>>>> many other devices with chardev backends which log to files,
>>>> but this setting only touches serial ports.
>>
>> What would be other cases with chardev file backends worth considering?
> 
> I don't want to consider adding even more cases to the qemu.conf.
> 
>>>> Ultimately append/truncate is a policy decision for the
>>>> mgmt app to make, not a libvirt host level tunable.
>>>>
>>>
>>> I agree with that since it allows for more configurability and it is
>>> concentrated in one place, the mgmt app.  Defaulting to a value is
>>> something that should not be difficult to implement in any controlling
>>> application that uses libvirt, so I don't really see the benefit for
>>> other mgmt apps either.
>>
>> The issue here is that we have a 5 different management apps, and we would
>> have to introduce this change to all of them. These are in different
>> technology stacks, different languages, so it would be more complex to
>> duplicate the implementation of this feature.
> 
> If you have 5 different mgmt apps then I feel a simple boolean
> flag for the <serial> console configuration when provisioning
> a guest should be negligible in the big picture. 

You are right, that's not the biggest thing, but it still would take 
time to develop across different teams.

> I don't think
> the answer is to push policy logic from the apps into
> libvirt via qemu.conf.

Why not? I remember the concern of trying to make user's expectation for 
importing a configuration into any libvirt installation and expecting 
the same guest-facing behavior, but:
  - This is not observable from guest
  - The idea of having some way to configure policy on meta-domain level 
seems valuable to me, as this would make libvirt more wholesome without 
the need of even existence of the management app. This way could provide 
a way for interoperability of different setups, meaning people don't 
have to learn the specifics of every mgmt app configuration. They just 
need to know how to flip a flag in qemu.conf (or some other place for 
this meta-domain policy configuration we could devise)

> 
>> Another use case for this, similar to the one I had during my previous
>> experience in Huawei. I was given multiple libvirt's XMLs to debug issues
>> with boot. No management app was involved, except initial creation through
>> virt-install by third party. It would be beneficial to automatically retain
>> serial logs to ease the debugging process.
> 
> If debugging a VM without a mgmt app being involved, it is trivial
> to use 'virsh edit' add the flag to the XML.

That's true when you have a single VM. When there are multiple, it 
becomes tedious.

Another case is when support takes over the machine from the customer, 
flips the flag to 'on', restarts the VM and can expect the logs to be 
preserved.

> 
> With regards,
> Daniel