Description of problem: Usability problem with serial-console. It's impossible to know if someone is already logged in to the serial-console or not, there is no monitoring for the active session. I opened one serial-console session to the VM, then tried to open another session from different source, I could not get login prompt, and did not received that there is already active serial-console session, hence it's a usability bug. Version-Release number of selected component (if applicable): Engine: rhevm-3.6.0.3-0.1.el6.noarch ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch ovirt-engine-extension-aaa-jdbc-1.0.1-1.el6ev.noarch ovirt-host-deploy-1.4.0-1.el6ev.noarch ovirt-host-deploy-java-1.4.0-1.el6ev.noarch ovirt-vmconsole-1.0.0-1.el6ev.noarch Host: ovirt-vmconsole-host-1.0.1-0.0.master.20151105234454.git3e5d52e.el7.noarch ovirt-release36-snapshot-001-2.noarch ovirt-vmconsole-1.0.1-0.0.master.20151105234454.git3e5d52e.el7.noarch ovirt-release36-001-2.noarch How reproducible: 100% Steps to Reproduce: 1.Try to establish several serial-console connections to one guest-VM from same IP or from different IPs. 2. 3. Actual results: You're not receiving any warning message that there is already someone connected to the VM and you can't know if that session is active or even exist. Expected results: The monitoring of connected serial-console sessions should be implemented and there should be at least warning about active user is already connected to the VM via serial console. Additional info:
qemu does not reject new connections, when it will user will be notified/rejected. performing anything heuristic from our end will end up doing more harm than good.
(In reply to Alon Bar-Lev from comment #1) > qemu does not reject new connections, when it will user will be > notified/rejected. > > performing anything heuristic from our end will end up doing more harm than > good. Not sure I'm following, but currently when user tries to establish a second or third or any additional connection to the same VM, he/she not getting anything except the blank screen, not getting the login prompt, as it being received for the first serial-connection session, no warnings received for the second connection or any notification, that's our current status. I'm not quite understanding your saying here: - " qemu does not reject new connections, when it will user will be notified/rejected.", as I was not notified about rejected connection, I simply did not received nothing and got black screen being unable to get any input/output from the VM, the only thing I could do is: - "~." to gracefully exit the connection, the least I do expect is to have the warning that there is already active serial-console connection is in progress.
(In reply to Nikolai Sednev from comment #2) > (In reply to Alon Bar-Lev from comment #1) > > qemu does not reject new connections, when it will user will be > > notified/rejected. > > > > performing anything heuristic from our end will end up doing more harm than > > good. > > Not sure I'm following, but currently when user tries to establish a second > or third or any additional connection to the same VM, he/she not getting > anything except the blank screen, not getting the login prompt, as it being > received for the first serial-connection session, no warnings received for > the second connection or any notification, that's our current status. > > I'm not quite understanding your saying here: - " qemu does not reject new > connections, when it will user will be notified/rejected.", as I was not > notified about rejected connection, I simply did not received nothing and > got black screen being unable to get any input/output from the VM, the only > thing I could do is: - "~." to gracefully exit the connection, the least I > do expect is to have the warning that there is already active serial-console > connection is in progress. The problem here is that the piece of the software in the stack who owns the connection and which properly should reject the extra connections, is qemu. qemu should reject connections on console if there is already one client connection, so we should open one RFE on QEMU and depend on that. Once qemu does that, everything else will work transparently, and we will reach the desired goal. On our side, I agree with comment 1 from Alon: adding heuristic is fragile, and will likely do more harm than good.
pending development on qemu side, bug 1283159
This would require significant and risky effort for small benefit, so closing as wontfix. Please feel free to reopen if you feel this should be fixed.