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. I don't think
the answer is to push policy logic from the apps into
libvirt via qemu.conf.
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.
With regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|