Bug 974199 - (rhelosp_serial_console) Virtual serial console access to openstack instances
Virtual serial console access to openstack instances
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
3.0
x86_64 Linux
high Severity low
: ga
: 6.0 (Juno)
Assigned To: Sahid Ferdjaoui
Gabriel Szasz
https://blueprints.launchpad.net/nova...
upstream_milestone_juno-rc1 upstream_...
: FutureFeature, Triaged
: 1041409 1114875 (view as bug list)
Depends On: 1223671
Blocks: 1077198 1115100 1145257 1158942 1158944 1182406
  Show dependency treegraph
 
Reported: 2013-06-13 11:56 EDT by Dave Sullivan
Modified: 2018-02-08 05:05 EST (History)
15 users (show)

See Also:
Fixed In Version: openstack-nova-2014.2-2.el7ost
Doc Type: Enhancement
Doc Text:
This feature exposes interactive web-based serial consoles to openstack VMs through a websocket proxy. Generally used as a debugging tool (for example, VMs can be accessed even if network configuration fails). A new service (websocket proxy) is now available that handles websocket connections to the serial consoles of the VMs. The websocket proxy can be deployed on a machine other than from the hypervisor.
Story Points: ---
Clone Of:
: 1115100 1182406 (view as bug list)
Environment:
Last Closed: 2015-02-09 09:57:19 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1172773 None None None Never
OpenStack gerrit 86418 None None None Never

  None (edit)
Description Dave Sullivan 2013-06-13 11:56:32 EDT
1. Proposed title of this feature request

Virtual serial console access to openstack instances

2. Who is the customer behind the request?
Account name: 		CME Group
Customer segment: 	FSI
TAM/SRM customer: 	yes
Strategic Customer: 	yes


3. What is the nature and description of the request?

We currently have all of our physical and virtual servers connected to either physical or virtual serial ports for console access.  It seems that openstack nova does not support this out of the box and we are required to use a VNC console. We are aware that nova automatically configures the hypervisor to redirect the serial port to a log file (which can be viewed via "nova console-log INSTANCE"), but this does not give us an interactive terminal.

This feature request is for an interactive serial console that works with openstack instances (preferably with similar functionality to "nova get-vnc-console" for VNC).

4. Why does the customer need this? (List the business requirements here)

They use conserver to access all of their servers throug physcial or virtual ports.

None of the service processors, ilo/drac/..., have IP connectivity.  Currently we rely on RS-232 serial connectivity from a terminal server to the server's external serial port.  The service processor is accessed by invoking its shell via special escape sequence over the serial port, e.g. HP and Dell use <ESC>+( .  conserver connects to the serial ports via ssh to the terminal server(dedicated tcp port per serial port).

5. How would the customer like to achieve this? (List the functional
requirements here)

RH would setup an environment to simulate the customers.

We already use conserver in house, so this shouldn't be too hard.

RH would implement functionality in OpenStack nova to allow communication via serial port and allow for that interaction to be interactive.


6. For each functional requirement listed in question 5, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

Basically implement and test what was described in Step 5.


7. Is there already an existing RFE upstream or in Red Hat bugzilla?

Not that I am aware of.


8. Does the customer have any specific timeline dependencies?

They are in initial stage of looking to move their existing virt/libvirt/kvm environment to OpenStack.  That goal is probably a year away, but they would need/want this functionaly fairly soon to test out and validate it meets their needs.


9. Is the sales team involved in this request and do they have any additional input?

Not really.


10. List any affected packages or components.

OpenStack nova


11. Would the customer be able to assist in testing this functionality if
implemented?
yes
Comment 5 Stephen Gordon 2013-11-19 14:46:28 EST
Upstream blueprint updated with proposed specification.
Comment 6 Stephen Gordon 2013-11-19 14:51:17 EST
The specification detail is here for review:

https://docs.google.com/document/d/1wqHoFGSdfy6VI5upQRpmXAqwVkBnuHzlehFnAv9Nxns/edit
Comment 7 Stephen Gordon 2013-12-06 17:28:35 EST
The current direction of that blueprint is to expose the serial port via a browser accessible page, similar to noVNC (it also currently doesn't appear to handle disconnect but that's another matter).

This doesn't seem to facilitate the use case described in this BZ, so I guess the question is how does the customer really need the serial ports exposed? As ports to SSH to on the compute nodes, or proxied somehow to a more central location?
Comment 9 Stephen Gordon 2014-01-14 09:47:07 EST
Removing the blueprint link as it was deemed inapplicable to the customers use case at least in its existing form.
Comment 13 Vladan Popovic 2014-02-25 10:10:44 EST
Created attachment 867464 [details]
screenshot of a conserver client (console) accessing a VM's serial console output throught TCP

I tried the nova libvirt setup with conserver and it seems to work. I only hope I've done everything right. If someone has more experience with conserver please let me know if I failed at something.

I did the following thigs:
 - set up a vm to do what nova should do in the libvirt config (bottom right)
 - configured a conserver console to connect on a TCP socket (top left)
 - started conserver (bottom left)
 - and got the output (top right)
Comment 18 Stephen Gordon 2014-02-28 08:23:04 EST
*** Bug 1041409 has been marked as a duplicate of this bug. ***
Comment 21 Pablo Iranzo Gómez 2014-07-01 08:22:19 EDT
*** Bug 1114875 has been marked as a duplicate of this bug. ***
Comment 25 Stephen Gordon 2014-09-19 21:12:17 EDT
----- Forwarded Message -----
> From: "Amit Shah" <amit.shah@redhat.com>
> To: "Zhang Haoyu" <zhanghy@sangfor.com>
> Cc: "qemu-devel" <qemu-devel@nongnu.org>, "kvm" <kvm@vger.kernel.org>
> Sent: Friday, August 29, 2014 10:38:49 AM
> Subject: Re: [Qemu-devel] [question] virtio-blk performance degradation happened with virito-serial
>
> On (Fri) 29 Aug 2014 [15:45:30], Zhang Haoyu wrote:
> > Hi, all
> >
> > I start a VM with virtio-serial (default ports number: 31), and found that
> > virtio-blk performance degradation happened, about 25%, this problem can
> > be reproduced 100%.
> > without virtio-serial:
> > 4k-read-random 1186 IOPS
> > with virtio-serial:
> > 4k-read-random 871 IOPS
> >
> > but if use max_ports=2 option to limit the max number of virio-serial
> > ports, then the IO performance degradation is not so serious, about 5%.
> >
> > And, ide performance degradation does not happen with virtio-serial.
>
> Pretty sure it's related to MSI vectors in use.  It's possible that
> the virtio-serial device takes up all the avl vectors in the guests,
> leaving old-style irqs for the virtio-blk device.
>
> If you restrict the number of vectors the virtio-serial device gets
> (using the -device virtio-serial-pci,vectors= param), does that make
> things better for you?
>
>
>                 Amit
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Comment 26 Stephen Gordon 2014-09-19 21:13:11 EDT
As part of QE need to confirm that we do not hit this performance degradation in OpenStack implementation when attaching serial and using virtio-blk.
Comment 27 Gabriel Szasz 2014-10-21 10:45:30 EDT
I am completely confused about final implementation of this feature in Juno. Is there any valid documentation to the current implementation?
Comment 28 Dave Sullivan 2014-10-21 10:50:03 EDT
Look at Comment #13 (uses conserver client side entry point) and this one below

https://docs.google.com/document/d/1ftVIfXZgb52CwJ0enyPNiqgnh8wfUgRQWnPOU6ppncQ/edit#

I think those two will get what you want, although I haven't had a chance to walk through it yet myself.
Comment 29 Sahid Ferdjaoui 2014-10-22 11:39:46 EDT
On a fresh fedora 20

INSTALL
 1. yum install http://rdo.fedorapeople.org/openstack-juno/rdo-release-juno.rpm
 2. yum install -y openstack-packstack
 3. packstack --gen-answer-file=answers.txt
 4. ''you can have to update some configurations like the network
    interface''
 5. packstack --answer-file=answers.txt

CONF
 1. start the process `nova-serialproxy` (we probably have to create
    service in the package)
 2. update the section serial_console in nova.conf to enable the
    feature serial console
    [serial_console]
    enabled = true
 3. restart services `openstack-nova-api`, `openstack-nova-compute`
    systemctl restart openstack-nova-compute
    systemctl restart openstack-nova-api

USE
 1. start an instance `nova boot --flavor 1 --image cirros test`
 2. get a websocket url `nova get-serial-console test`
 3. now you need a ws client to connect to this url - you can use this
    one for test purpose:
      https://gist.github.com/sahid/894c31f306bebacb2207
Comment 36 errata-xmlrpc 2015-02-09 09:57:19 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0152.html

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