Bug 1283159

Summary:	[RFE] reject multiple connections to console
Product:	Red Hat Enterprise Linux 7	Reporter:	Francesco Romani <fromani>
Component:	qemu-kvm	Assignee:	Amit Shah <amit.shah>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.1	CC:	fromani, hhuang, huding, juzhang, rbalakri, virt-maint, xfu, zhguo
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-07 16:18:20 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1282437

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.