Re: [ovirt-users] Thinking loud about VM's serial console access
On Sat, 18 Oct 2014 14:39:12 -0400 (EDT) Alon Bar-Lev alo...@redhat.com 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_usingproxy_virtual_serial_ports.pdf j. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Thinking loud about VM's serial console access
- Original Message - From: Jiri Belka jbe...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: users@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 alo...@redhat.com 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. http://www.vmware.com/support/developer/vc-sdk/visdk41pubs/vsp41_usingproxy_virtual_serial_ports.pdf j. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Thinking loud about VM's serial console access
On Mon, 20 Oct 2014 08:40:34 -0400 (EDT) Alon Bar-Lev alo...@redhat.com wrote: - Original Message - From: Jiri Belka jbe...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: users@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 alo...@redhat.com 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. j. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Thinking loud about VM's serial console access
- Original Message - From: Jiri Belka jbe...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: users@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 alo...@redhat.com wrote: - Original Message - From: Jiri Belka jbe...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: users@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 alo...@redhat.com 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. how can I test something that is not implemented? 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. once you tunnel serial over network protocol, every failure of network protocol applies to the tunnel. this is just like modem hangup or any other hardware failure. unless you wish to implement proprietary client side component instead of standard ssh utility, a component that retry to establish connection, this custom component can be provided regardless of the solution. a software that assumes that a connection is always available will fail to provide service after failure, at any medium. Alon ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Thinking loud about VM's serial console access
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 - Original Message - From: Jiri Belka jbe...@redhat.com To: users@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Thinking loud about VM's serial console access
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 Hope this helps, Dan On Fri, Oct 17, 2014 at 11:15 AM, Jiri Belka jbe...@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 :) j. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Thinking loud about VM's serial console access
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_UScmd=displayKCexternalId=1022303 http://www.emersonnetworkpower.com/en-US/Products/InfrastructureManagement/SerialConsoles/Pages/AvocentACSv6000VirtualAdvancedConsoleServer.aspx On Fri, Oct 17, 2014 at 11:15 AM, Jiri Belka jbe...@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 :) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
