On Mon, Jul 15, 2024 at 11:20:27AM +0200, Jocelyn Falempe wrote: > > On 15/07/2024 10:30, Zbigniew Jędrzejewski-Szmek wrote: > > > > There's just so many different and special ways in how people hook up > > console logging from VMs and other systems. Disabling VT_CONSOLE at > > compile time is hard to defend. > > For VM, you have an easy access to the serial output, where you can copy the > debug message and google them. Having the same thing on graphic output is > less appealing, because it starts later than serial, you can't copy/paste, > you can't scroll back, and you can't save it to a file. (And a boot video > recording is much less useful than a text log). Don't assume serial access is quiet that straightforward in all VMs. The serial console might be setup in interactive mode, rather than persistently logging all data. If you don't have the serial console open at the time the VM crashes, the kernel messages are easily lost forever. If you do have the serial console open, don't assume there is terminal scrollback to see the top of the trace, you might only see the bottom of it. If the crash scenario isn't reliably reproducible this is all rather a pain. In addition depending on permissions of the deployment, a user might have rights to access the graphical console (VNC/SPICE/RDP/etc), but have no access to the mgmt plane, thus preventing access to the serial console logs. While it is ultimately the VM owners job to fix the crash, it would still be nice if the VM user could see the info before escalating the issue to the VM owner. We do have the ability to provide a 'pstore' device to a VM, which is an area of NVRAM storage to record panic logs. Potentially better than the serial console, but access this data still has the permissions problem if the user only has graphical console access. IOW, I think it is interesting & useful to have this panic screen feature in VMs. With your QR code proposal, we could do something fun like having virt-manager auto-detect the QR code on the virtual screen, extract the information from it, and present it to the user in plain text once more. 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 :| -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
