RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1283159 - [RFE] reject multiple connections to console
Summary: [RFE] reject multiple connections to console
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1282437
TreeView+ depends on / blocked
 
Reported: 2015-11-18 11:55 UTC by Francesco Romani
Modified: 2016-01-07 16:18 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-07 16:18:20 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Francesco Romani 2015-11-18 11:55:00 UTC 
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 07:29:21 UTC 
(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 13:18:52 UTC 
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 13:22:52 UTC 
(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 16:18:20 UTC 
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.