Bug 974199 (rhelosp_serial_console)

Upstream blueprint updated with proposed specification.

The specification detail is here for review:

https://docs.google.com/document/d/1wqHoFGSdfy6VI5upQRpmXAqwVkBnuHzlehFnAv9Nxns/edit

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?

Removing the blueprint link as it was deemed inapplicable to the customers use case at least in its existing form.

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)

*** Bug 1041409 has been marked as a duplicate of this bug. ***

*** Bug 1114875 has been marked as a duplicate of this bug. ***

----- Forwarded Message -----
> From: "Amit Shah" <amit.shah>
> To: "Zhang Haoyu" <zhanghy>
> Cc: "qemu-devel" <qemu-devel>, "kvm" <kvm.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.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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.

I am completely confused about final implementation of this feature in Juno. Is there any valid documentation to the current implementation?

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.

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

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

(In reply to Vladan Popovic from comment #13)
> 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)

Hi Vladan, this setup seems  to be promising. Can you inbox me full details on how you carried out this setup ? thanks.