[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] How do I redirect console IO for script use?
From: |
Alexei Colin |
Subject: |
Re: [Qemu-discuss] How do I redirect console IO for script use? |
Date: |
Tue, 5 Mar 2019 18:32:06 -0500 |
User-agent: |
Mutt/1.11.2 (2019-01-07) |
On Tue, Mar 05, 2019 at 11:10:23PM +0100, Joachim Durchholz wrote:
> Am 05.03.19 um 09:51 schrieb Peter Maydell:
> > On Mon, 4 Mar 2019 at 20:39, Joachim Durchholz <address@hidden> wrote:
> > > Anyway: I want to avoid in-VM configuration as much as possible.
> > > Instead, I want to interact with the PC console: A text-mode screen and
> > > a keyboard.
> > > I.e. no configuration for a serial console in the guest. (The guest
> > > isn't Linux, it's FreeBSD and I'm not familiar enough with that to
> > > confidently configure anything inside it.)
> >
> > Last time I did something similar with FreeBSD I went
> > for "do initial install with a graphic display, set
> > up ssh daemon, and then just have it boot blind and
> > ssh into it". This is also how upstream QEMU does its
> > "run build test on freebsd VM" setup.
>
> Well, that doesn't help me with controlling the guest from a bash script in
> the host.
By controlling the guest, you mean by interacting with a shell running
in the guest, correct? If so, you need cooperation from the guest
(i.e. setup on the guest). That shell process needs to be hooked up
to some kind of I/O out of the system.
* 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);
* if I/O via keyboard+video, then guest needs to spawn a getty
on the tty0 physical terminal (usually happens by default), but not a
good text-based I/O option that you're looking for.
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 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?