On Thu, Mar 20, 2025 at 08:56:04 +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. > > 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.
Yes, with the remote console support we have in virsh the console will be always proxied so direct approach would not work. Only if a client application decided to access the pty directly based on the path it gets from libvirt. > 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. virStream is universal; not used only for console but also for "uploading" files in the storage driver or for "tunnelled" migration. Thus apart from not being qemu-only it's not even used for similar features. > Furthermore, if we don't want to broadcast a QMP message to every > chardev, the handle needs to determine the alias with which the chardev > can be adressed in QMP. in qemuDomainOpenConsole the alias for the > console is set and added as the callback argument for the internal > close function. There doesn't seem to be a way to get the alias of a > console from virStream. It seems that I need to add an alias string > field to the virStream or the virStreamFDData. I could however be > mistaken and there is already a way to get the alias for a virStream, > hence this email We already support special messages with stream to transport holes for sparse files. You could implement new set of stream APIs similarly to virStreamSendHole which would send the console size. Then in virFDStreamThread you could issue ioctls on receive of the message. Libvirt supports console also for unix-socket backed chardevs. I presume that would require the QMP command approach instead. That will likely reuqire more plumbing because on the first glance we don't seem to have the access to the VM object from the stream code. A callback could potentially solve that. > > TLDR I have the following 2 questions: > - Should the resize handle be implemented in the virHypervisorDriver > directly or in the virStreamDriver? > - Is there a way to get the QMP alias of a chardev from a virStream? I'd suggest to either implement it as another type of data transported via the stream or a standalone API. The client application which uses the stream knows which console it opened so it does have enough data to issue the proper API call with parameters identical to how it opened the console. The approach of adding stream APIs looks a bit cleaner on the first glance but as I've noted I'm not sure how complicated it will be to access the VM object if QMP command will be needed.
