Serial port support for VMs
- Thread starter jdw
- Start date
Huh, it seems I missed all the great follow-up to this.
Thanks for implementing that!
FWIW, we were going the args: route as well with the telnet interface, which does work great for sending breaks to the VM's serial console to drop to kernel debugger, etc. Never did get serial0: to work for that, it always said the serial port was invalid.
Thanks for implementing that!
FWIW, we were going the args: route as well with the telnet interface, which does work great for sending breaks to the VM's serial console to drop to kernel debugger, etc. Never did get serial0: to work for that, it always said the serial port was invalid.
This is the config line I use:
Code:
args: -serial telnet:localhost:6123,server,nowait(for VM ID 123)
If it is written as:
Code:
serial0: telnet:localhost:6123,server,nowaitthen the Proxmox web UI says the serial port number is invalid when starting the VM, and it fails to start.
How is serial break signal accomplished with the "serial0: socket" route?
Last edited:
Certainly, that can be done. Hopefully today.
In short, serial BRK is an out-of-band signal. The telnet protocol (RFC 854) is not just a bare TCP connection, it supports out-of-band data. You hit ^] to escape to the telnet client prompt and then type "send break" and hit enter and an escaped sequence to the server telling it what happened. The KVM "telnet" serial interface has special code to receive this notice and convert it to serial BRK for the guest.
Unfortunately, to the best of my knowledge the KVM "socket" serial interface does not have such a facility, nor does socat.
But my best knowledge is pretty limited so I am happy to try it a bit more and report back my findings.
Ok, here is an example of both methods.
First, for this config line:
And with this config instead:
The result is this:
In the second example, there is no way to access the guest's kernel debugger because serial BRK cannot be sent from socat or received by kvm over the Unix domain socket. (Unless it can and the only problem is I don't know how.)
Hope this helps!
Also the "vga: serial0" option was tested at the same time and works perfectly. Thank you very much!
First, for this config line:
Code:
args: -serial telnet:localhost:6123,server,nowait
Code:
root@testhost:~# telnet localhost 6123
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
... booting up messages ...
Sat Aug 24 00:43:18 UTC 2013
FreeBSD/amd64 (testguest) (ttyu0)
login:
telnet> send break
KDB: enter: Break to debugger
[ thread pid 11 tid 100005 ]
Stopped at kdb_break+0x55: movq $0,kdb_why
db> c
FreeBSD/amd64 (testguest) (ttyu0)
login:And with this config instead:
Code:
serial0: socketThe result is this:
Code:
root@testhost:~# qm terminal 123
starting serial terminal on interface serial0 (press control-O to exit)
... booting up messages ...
FreeBSD/amd64 (testguest) (ttyu0)
login:In the second example, there is no way to access the guest's kernel debugger because serial BRK cannot be sent from socat or received by kvm over the Unix domain socket. (Unless it can and the only problem is I don't know how.)
Hope this helps!
Also the "vga: serial0" option was tested at the same time and works perfectly. Thank you very much!
No, that is something completely different, CTRL-C is ASCII character code 3. Serial break is an out of band signal, representing holding the TX line to 0 for a whole frame. Hence it must be emulated.
The same, ASCII character code 26. CTRL-anything is just a character. Serial break is not a character, it is a signal. It is electrically different (on physical serial ports) and to virtualize it requires special agreement on how to encode it between both sender and recipient, as provided by the telnet protocol.
Sure, but as this is a documented feature of the KVM telnet backend and not listed for the socket backend, my hopes are not high.
Maybe nobody cares about this but me. If so, probably it is not worth the effort. Of course I would prefer you do the work of assigning and managing port numbers, but it is working for us now, so if no one else wants it, we will get by OK.
One request would be to make "serial0:
Maybe nobody cares about this but me. If so, probably it is not worth the effort. Of course I would prefer you do the work of assigning and managing port numbers, but it is working for us now, so if no one else wants it, we will get by OK.
One request would be to make "serial0:
telnet:localhost:6123,server,nowait" be recognized and handled properly, and respected by any web UI integration that you do for serial support.
If you want to be fancy, "qm terminal 123" could look at the kvm 123.conf and dispatch socat or telnet based on what it finds there, but that is just for show; calling telnet directly works fine.
If you want to be fancy, "qm terminal 123" could look at the kvm 123.conf and dispatch socat or telnet based on what it finds there, but that is just for show; calling telnet directly works fine.
You can also set the telnet option on the socket, that is not the problem here.
If you write a tcp port into the configuration, you need to manage port allocation cluster wide among all VM (VMs can migrate), so that is really not a trival task.
I guess it would be much easier to replace socat with a self written perl script which can send IAC (telnet) commands. Or maybe extend socat with that capability.
It's not clear to what you are referring. Here is the kvm(1) man page:
According to this, the telnet and unix backends are exclusive alternatives, not options. Does the kvm source say something different?
PORT_NUM = BASE_PORT + VMID seems to work for us as VMID's also share this cluster-wide property.
Certainly, whatever you think is best.