This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1283159 - [RFE] reject multiple connections to console
[RFE] reject multiple connections to console
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.1
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Amit Shah
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: 1282437
  Show dependency treegraph
 
Reported: 2015-11-18 06:55 EST by Francesco Romani
Modified: 2016-01-07 11:18 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-07 11:18:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Francesco Romani 2015-11-18 06:55:00 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):


How reproducible:
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

Actual results:
First connection works perfectly fine, second connection hangs because, in the guest side, the getty does not expect another connection.


Expected results:
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)


Additional info:
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.
Comment 2 Amit Shah 2015-11-20 02:29:21 EST
(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
> connection.

> 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

use

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.
Comment 3 Francesco Romani 2015-11-20 08:18:52 EST
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.
Comment 4 Francesco Romani 2016-01-07 08:22:52 EST
(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.
Comment 5 Amit Shah 2016-01-07 11:18:20 EST
OK, thanks.  I guess WONTFIX is the right resolution.

Note You need to log in before you can comment on or make changes to this bug.