Re: bhyve console question
HI Dan, Yes, the current bhyve-manual has that as a step in the configuration (http://bhyve.org/bhyve-manual.txt) which I guess is the culprit. I guess I just didn't expect that side effect but admit to not spending much time thinking about it first :-) I think it was done that way since /dev/console will always work, whereas the tty line to use changed at one point when we cut over from the ISA uart device to the PCI uart device resulting in a different tty device being used. However, it looks like we may switch back to using a PCI-ISA bridge device and that will change things again :( For now, you can edit the stock /etc/ttys as follows: -ttyu2 /usr/libexec/getty std.9600 dialup off secure +ttyu2 /usr/libexec/getty std.9600 vt100 on secure later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: bhyve console question
Ahh, cool. I wasn't paying attention I guess: uart2: 16550 or compatible port 0x3f8-0x3ff irq 4 at device 31.0 on pci0 uart2: console (9600,n,8,1) which maps to the bhyve argument given: '-S 31,uart,stdio' and subsequently the serial console getty on ttyu2. Nice. Thank you, It would be kind of cool to bind a guest's serial port to a named pipe on the host system (I think virtual box lets you do this too - an option when creating a guest serial port). This would make it easy to have each bhyve guest with serial console attached to a list of device files upon which we could attach a screen session to later if we wanted to login or look at the console. For now, I'll just spin up each vm guest within a separate screen window. Take care, Dan On Sun, 28 Apr 2013, Peter Grehan wrote: HI Dan, Yes, the current bhyve-manual has that as a step in the configuration (http://bhyve.org/bhyve-manual.txt) which I guess is the culprit. I guess I just didn't expect that side effect but admit to not spending much time thinking about it first :-) I think it was done that way since /dev/console will always work, whereas the tty line to use changed at one point when we cut over from the ISA uart device to the PCI uart device resulting in a different tty device being used. However, it looks like we may switch back to using a PCI-ISA bridge device and that will change things again :( For now, you can edit the stock /etc/ttys as follows: -ttyu2 /usr/libexec/getty std.9600 dialup off secure +ttyu2 /usr/libexec/getty std.9600 vt100 on secure later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: bhyve console question
Hi Dan, uart2: 16550 or compatible port 0x3f8-0x3ff irq 4 at device 31.0 on pci0 uart2: console (9600,n,8,1) which maps to the bhyve argument given: '-S 31,uart,stdio' Yes - the '-S' parameter instructs the PCI device to use a compatibility address so the console code can still access it. You could use any slot number that doesn't conflict (e.g. -S 11,...) FreeBSD reserves unit number 0 and 1 for ISA ports. When we have the PCI-ISA bridge code in place, it will show up as uart0, requiring ttyu0 to be edited in /etc/ttys. It would be kind of cool to bind a guest's serial port to a named pipe on the host system You bet. The intent was always to allow different back ends. The third parameter is to describe this e.g. in the future, there could be -s 10,uart,telnetd:4239 // telnet server on a given port -s 12,uart,pty05 // pseudo terminal -s 14,uart,exec:socat UNIX-LISTEN:/tmp/.bhye // exec an arbitrary program and use it's stdin/stdout On the TODO list :) later, Peter. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
