Re: [Qemu-discuss] How do I redirect console IO for script use?

[Joachim Durchholz]

Am 06.03.19 um 00:32 schrieb Alexei Colin:> By controlling the guest, 
you mean by interacting with a shell running
> in the guest, correct?
Sending commands and checking the output (via expect or something), yes.

> If so, you need cooperation from the guest
> (i.e. setup on the guest).
Not if I use the console. The console is already all set up.

> That shell process needs to be hooked up
> to some kind of I/O out of the system.
The console is hooked up by default.

> * If I/O via network, then guest needs to be setup to listen on a port
> (telnet, ssh, netcat -- which would spawn a shell upon connection);
>
> * if I/O via serial port, then need setup to listen on the serial
> port (usually a getty process, that would spawn a shell upon login);
Sure. That's why I don't want to do that.

> * if I/O via keyboard+video, then guest needs to spawn a getty
> on the tty0 physical terminal (usually happens by default),
That's exactly the point: it happens by default.

> but not a
> good text-based I/O option that you're looking for.
That's why I was wondering how -curses works.
The docs are a bit vague here. Is -curses looking at the console 
manipulation and transforming that into a stream of control codes? That 
would actually be fine, but I don't know whether it's even worth trying 
to validate the theory.

> How to accomplish this "without setup in the guest"? The only "way"
> I see is if the software that you happen to run in the guest happens to
> already do one of the above setups by default... which is not uncommon
It's already working on the console, i.e. keyboard & textmode screen.
That's why I'm even considering this approach. Everything else requires 
knowledge about device names and setup mechanisms on the guest OS.

This is problematic for my current project because I am not yet familiar 
enough with FreeBSD to confidently set that up. In particular, I don't 
yet know under what conditions FreeBSD device names are stable, and how 
to deal with instabilities. (E.g. the name of a network device depends 
on what driver is providing it, there's no eth0 in FreeBSD.)
Sure I could cobble something together and make it work in some way, but 
I want to try the console approach first.

Having experience with the console approach would also be a great 
enabler for experimenting with other operating systems, at least those 
that don't switch to graphics mode by default (so Windows isn't on the 
list, but I don't plan VM experiments with it anyway).

> It is possible that the default init in your BSD might happen to spawn
> gettys on all serial ports it finds automatically, and/or launch an
> ssh server. How else do you see this, though?
I already know enough of FreeBSD to know that it doesn't start anything 
by default.
That's a conscious decision. FreeBSD priorizes security pretty highly, 
and opening access options without user consent is a big no-no in this book.

Regards,
Jo