Re: Questions regarding potential resize implementation in libvirt
On Thu, 2025-03-20 at 09:58 +0000, Daniel P. Berrangé wrote:
On Thu, Mar 20, 2025 at 08:56:04AM +0100, Maximilian Immanuel
Brandtner wrote:
> I've been working on an RFC patch-set to implement resizing for
> consoles in QEMU. Now that the patch-set is in review I've turned
> my
> attention to bringing this feature to libvirt.
Can you point to the QEMU patchset URL ?
It's not yet on the upstream mailing list as it's still in internal
review. It should soon be sent to the upstream mailing list.
> With the QEMU patch-set there are two ways to resize a pty chardev.
> 1. send a TIOCSWINSZ ioctl
> 2. send a QMP msg
>
> The first approach doesn't work under Libvirt. Pty chardevs are
> proxied
> over a FIFO meaning the ioctl wouldn't get to libvirt. Furthermore,
> this approach is incompatible with remote management which libvirt
> seems to go to great lengths to support.
So we have the flow
virsh console (or equiv mgmt equiv)
-> virStream
-> libvirtd/virtqemud
-> virStream
-> PTY
-> QEMU chardev
-> guest serial port / paravirt console
NB I've always wanted to extend our console stream handling to
support
UNIX socket / TCP socket chardev instead of the PTY, as the
connection
semantics are so much saner to deal with.
> Sending a QMP message is a QEMU specific feature. It seems to me
> that
> adding a new handle (something like domainResizeConsole) would have
> to
> be added to the virHypervisorDriver struct. It would be really
> nifty if
> the resize handle could be implemented in the virStream, however it
> seems that all the virStreamDriver handlers are common code (aka
> shared
> across all hypervisors). From what I've seen it seems that the only
> way
> to switch from common code to hypervisor specific code would be
> over
> the virHypervisorDriver. As it stands it seems to me that the best
> course of action would be adding a new handle to the
> virHypervisorDriver, but I'm unsure whether that's really the right
> call.
How is the window resize supposed to be passed to the QEMU chardev
backend for the different chardev backend types ?
For all chardevs that support chr_resize the QMP properties winsize_row
and winsize_col are added to the chardev. In HMP the request would look
as follows:
`qom-set /chardevs/console winsize_row 24`
`qom-set /charedvs/console winsize_col 80`
For now winsize_row and winsize_col are implemented as two seperate
integers for the sake of simplicity, however I would be open to
changing it.
These two QMP properties are the same for all chardevs whose backends
support resize so it doesn't matter if the chardev uses virtio or some
other backend when it comes to changing the winsize over QMP.
> TLDR I have the following 2 questions:
> - Should the resize handle be implemented in the
> virHypervisorDriver
> directly or in the virStreamDriver?
Unclear currently. I did think about this a long while back and tried
to hack something into virStream, but never completed it and it was
not as simple as it first seemed
> - Is there a way to get the QMP alias of a chardev from a
> virStream?
No, currently the stream only knows about the underlying host OS
channel,
nothing about the hypervisor
Would it make more sense to add the QMP alias to the virStream or the
virFDStreamData?
With regards,
Daniel