6:36 p.m.
I have posted a ready script and a VDSM hook for this exact use case
a
couple of years ago.
http://www.ovirt.org/Features/Serial_Console_in_CLI
The actual locateVM.py script is missing from there, but it's an elementary
API script that will receive a VM name, find the VM's host location and
start the shell
Hi,
well this is no way IMHO.
1. libvirt/virsh doesn't provide concurrent access to console
2. during migration there would be probably some issue with pty device
3. looks scary to do ssh via root to host (ssh via root should be eliminated
as much as possible)
Avocent has been selling to enteprise customers their console servers for ages,
and they also have been selling a virtual console server appliance to operate
with VMWare vCenter technology. The way how they do it is that VM's IP-enabled serial
devices act as clients and connect to virtual serial port concentrator over network.
This way there's "active" session opened during migration and VSPC allows
temporary
disconnected IP-enabled serial devices from its clients.
I think we should do similar. If this is supposed to be a "standard" and
vendors
sell applicances for this, why not to use it?
There's OSS alternative to Avocent virtual serial port concentrator, but it
still acts only as plain concentrator, not as full console server.
Some reading:
https://github.com/isnotajoke/vSPC.py
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&...
http://www.emersonnetworkpower.com/en-US/Products/InfrastructureManagemen...
On Fri, Oct 17, 2014 at 11:15 AM, Jiri Belka
<jbelka(a)redhat.com> wrote:
> Hi,
>
> on KVM forum VM's serial console access was raised. I'd like to make
> some comments, hopefully it would help to think about how we would
> access VM's serial consoles in oVirt.
>
> 1. encrypted access (ssh preferable) is a must
>
> 2. not to type any automatically generated password to access
> serial console should be possible (like for spice)
>
> i can imagine a centralized console server could be used to
> manage all serial console accesses. usually such console servers are
> access via ssh and then a connection is spawned and sysadmin's ssh
> session is connected to remote serial console without any action
>
> 3. not to see a interactive menu should be possible
>
> there can be serial console output parser/monitor persistently
> running to catch kernel outputs and alerts in console. if kernel
> crashes, the output is on console and thus a monitoring can catch it
>
> 4. access to VM's serial console should not require to know where a VM
> is running (thus to know host fqdn/IP)
>
> this is obvious, a sysadmin wants to just get serial console without
> manual kung-fu
>
> 5. multi-user access to one VM's serial console
>
> in some paranoid environment there must be two people working
> together, each controlling other. whatever. multi-user concurrency
> should be possible, there can be passive serial console output
> parser/monitor and sysadmin's interactive session
>
> Hopefully the above will contribute to implementation design. All above
> is possible with open source tools while using real hw serial consoles,
> thus it would be expected that implementation for VM's serial console
> would work similarly.
>
> FYI I created RFE for qemu for TLS mode for chardev socket
> https://bugzilla.redhat.com/show_bug.cgi?id=1154115, so there could be
> a way not to use ssh to host as this has been not preferred by
> alonbl@ for other functionality in the past :)