<div dir="ltr">I have posted a ready script and a VDSM hook for this exact use case a couple of years ago. <div><br></div><div><a href="http://www.ovirt.org/Features/Serial_Console_in_CLI">http://www.ovirt.org/Features/Serial_Console_in_CLI</a><br></div><div><br></div><div>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</div><div><br></div><div><br></div><div>Hope this helps,</div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 17, 2014 at 11:15 AM, Jiri Belka <span dir="ltr"><<a href="mailto:jbelka@redhat.com" target="_blank">jbelka@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
on KVM forum VM's serial console access was raised. I'd like to make<br>
some comments, hopefully it would help to think about how we would<br>
access VM's serial consoles in oVirt.<br>
<br>
1. encrypted access (ssh preferable) is a must<br>
<br>
2. not to type any automatically generated password to access<br>
serial console should be possible (like for spice)<br>
<br>
i can imagine a centralized console server could be used to<br>
manage all serial console accesses. usually such console servers are<br>
access via ssh and then a connection is spawned and sysadmin's ssh<br>
session is connected to remote serial console without any action<br>
<br>
3. not to see a interactive menu should be possible<br>
<br>
there can be serial console output parser/monitor persistently<br>
running to catch kernel outputs and alerts in console. if kernel<br>
crashes, the output is on console and thus a monitoring can catch it<br>
<br>
4. access to VM's serial console should not require to know where a VM<br>
is running (thus to know host fqdn/IP)<br>
<br>
this is obvious, a sysadmin wants to just get serial console without<br>
manual kung-fu<br>
<br>
5. multi-user access to one VM's serial console<br>
<br>
in some paranoid environment there must be two people working<br>
together, each controlling other. whatever. multi-user concurrency<br>
should be possible, there can be passive serial console output<br>
parser/monitor and sysadmin's interactive session<br>
<br>
Hopefully the above will contribute to implementation design. All above<br>
is possible with open source tools while using real hw serial consoles,<br>
thus it would be expected that implementation for VM's serial console<br>
would work similarly.<br>
<br>
FYI I created RFE for qemu for TLS mode for chardev socket<br>
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1154115" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1154115</a>, so there could be<br>
a way not to use ssh to host as this has been not preferred by<br>
alonbl@ for other functionality in the past :)<br>
<br>
j.<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br>
</blockquote></div><br></div>