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 :) j. _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

From: "Jiri Belka" <jbelka(a)redhat.com&gt; To: users(a)ovirt.org Sent: Friday, October 17, 2014 6:15:43 PM Subject: [ovirt-users] Thinking loud about VM's serial console access 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 :) j. _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

From: "Jiri Belka" <jbelka(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: users(a)ovirt.org Sent: Monday, October 20, 2014 2:40:01 PM Subject: Re: [ovirt-users] Thinking loud about VM's serial console access On Sat, 18 Oct 2014 14:39:12 -0400 (EDT) Alon Bar-Lev <alonbl(a)redhat.com&gt; wrote: > > Please read [1]. > > I am unsure about concurrent access, this should be done using ssh bridge > and now low level solution. > > Thanks, > Alon > > [1] http://www.ovirt.org/Features/Serial_Console How will it behave when: - VM is being snapshotted? - VM is being migrated? - VM is suspended? - VM is being (cold)rebooted? At least for last two I suppose the serial console session will be interrupted. VMWare uses extended communication to inform virtual serial port concentrator about various action of a VM, thus "proxy" doesn't drop serial connections.

http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/vsp41_usingpro... j.

From: "Jiri Belka" <jbelka(a)redhat.com&gt; To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; Cc: users(a)ovirt.org Sent: Monday, October 20, 2014 3:56:12 PM Subject: Re: [ovirt-users] Thinking loud about VM's serial console access On Mon, 20 Oct 2014 08:40:34 -0400 (EDT) Alon Bar-Lev <alonbl(a)redhat.com&gt; wrote: > > > ----- Original Message ----- > > From: "Jiri Belka" <jbelka(a)redhat.com&gt; > > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > > Cc: users(a)ovirt.org > > Sent: Monday, October 20, 2014 2:40:01 PM > > Subject: Re: [ovirt-users] Thinking loud about VM's serial console access > > > > On Sat, 18 Oct 2014 14:39:12 -0400 (EDT) > > Alon Bar-Lev <alonbl(a)redhat.com&gt; wrote: > > > > > > > > Please read [1]. > > > > > > I am unsure about concurrent access, this should be done using ssh > > > bridge > > > and now low level solution. > > > > > > Thanks, > > > Alon > > > > > > [1] http://www.ovirt.org/Features/Serial_Console > > > > How will it behave when: > > > > - VM is being snapshotted? > > - VM is being migrated? > > - VM is suspended? > > - VM is being (cold)rebooted? > > > > At least for last two I suppose the serial console session will be > > interrupted. > > > > VMWare uses extended communication to inform virtual serial port > > concentrator about various action of a VM, thus "proxy" doesn't drop > > serial connections. > > there is no reason why the proxy cannot retry for a while and reconnect to > the new instance. > however this will not be provided at first nor it is that important as > client can always implement reconnect at its side, and handle this just > like any other network failure. OK, I'm reading this as you haven't tested it with these actions.

With real serial console one doesn't need to re-plug cable to get the console... Thus I'm not interested anymore in the topic.