Red Hat Bugzilla – Bug 1283159
[RFE] reject multiple connections to console
Last modified: 2016-01-07 11:18:20 EST
Description of problem:
oVirt/RHEV 3.6.0 exposes guest console device in a friendlier manner, allowing admins to connect directly. To do so, we configure qemu to use a serial or virtio console device, and we bind this device to a unix domain socket on the host side. Other components of the oVirt/RHEV orchestrates the connection.
We would like to inform the user if the connection to a VM is already used by someone else, so that it is not possible to have more than N (usually 1) connections to the same console, like it happens with physical hardware (due to physical restrictions, e.g. only one physical serial port).
For out purposes, it is perfectly fine if QEMU just gains an option to refuse the connection beyond the first one, or beyond the first N (let's sya, two).
Version-Release number of selected component (if applicable):
100% of times
Steps to Reproduce:
1. run qemu vm with console device
2. make sure a getty is running in the guest on the console device (e.g /dev/ttyS0)
3. try to connect from the outside using the host side of the device
First connection works perfectly fine, second connection hangs because, in the guest side, the getty does not expect another connection.
If qemu is configured as such, only the first connection attempt should succeed, while the other should fail with something like -EBUSY (not sure it is the best error)
This is not a QEMU bug per se, but would greatly help the management application.
We considered different approaches to solve this, but each one seems suboptimal, because ultimately is qemu that owns the listening endpoint
- use special-purpose getty inside the guest:
could work, but we strongly prefer to avoid special-purpose software inside the guest
- perform euristic on the management layer (e.g oVirt/RHEV component): is fragile and error-prone.
(In reply to Francesco Romani from comment #0)
> Description of problem:
> oVirt/RHEV 3.6.0 exposes guest console device in a friendlier manner,
> allowing admins to connect directly. To do so, we configure qemu to use a
> serial or virtio console device, and we bind this device to a unix domain
> socket on the host side. Other components of the oVirt/RHEV orchestrates the
> Actual results:
> First connection works perfectly fine, second connection hangs because, in
> the guest side, the getty does not expect another connection.
Actually it's not the guest side. It's on the host. The inbound connections to a socket are queued up. Fun experiment: open multiple connections to the same chardev, then close the first one and try communicating with the 2nd one that was opened. The connection will continue as normal.
This is just some queueing of connections on the host side. The 'hang' you see is just the new socket waiting for the older one to go away.
What this bz request means is that we should stop accepting more connections after one successful connection - that's not what we always want: e.g. a client can lose its connection to qemu, and qemu won't be able to start a new listening socket again (or will have to have very convoluted code to get this).
Instead, will this suggestion be helpful: instead of opening qemu's sockets in server mode, open them in client mode (i.e. drop the 'server' option), and open the client in listening mode.
i.e. instead of
qemu ... -chardev socket,path=/some/socket,server,nowait,id=ch0
qemu ... -chardev socket,path=some/socket,reconnect=5,id=ch0
this will make qemu open the socket in 'connect' mode (as opposed to server or listening mode), and will attempt reconnections to the socket every 5 seconds after a client is closed.
Hope this is what you're looking for, and that this serves the purpose.
Amit, thanks for the explanation and the suggestion. We have a few pieces interacting in this flow, so I need to check few things before to report if your suggestion works for us. Keeping the NEEDINFO open for a few more days.
(In reply to Francesco Romani from comment #3)
> Amit, thanks for the explanation and the suggestion. We have a few pieces
> interacting in this flow, so I need to check few things before to report if
> your suggestion works for us. Keeping the NEEDINFO open for a few more days.
Sorry for the long wait. Looks like we can't directly implement this suggestions.
We will work with libvirt to see how to fix in a different way.
I think we can close this bug.
OK, thanks. I guess WONTFIX is the right resolution.