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
