Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[9fans] booting a terminal in qemu

90 views
Skip to first unread message

John Floren

unread,
Feb 27, 2007, 2:32:09 PM2/27/07
to
Hi everyone

I'm playing around with qemu a bit, and I'm hoping somebody can help
me with this. I'd like to set up a terminal that either boots entirely
from my server or at least mounts the root from it. Anyone with
experience in this kind of thing? I'm not quite sure where I need to
set things up, what kind of options to use with qemu, etc.


John Floren
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Steve Simon

unread,
Feb 27, 2007, 4:13:35 PM2/27/07
to
I don't know how you would use qemu to netboot plan9 as the server
uses the ethernet address of the client to decide who it is and which
kernel it give it. As this MAC is also assigned to the host machine
then things could get confused, perhaps there is some way of virtualising
MACs?

The cleanst way to boot a terminal is PXE as this means it can be
diskless. Failing this you can boot 9load locally, which will use
DHCP to get an IP address and the name of the kernel to fetch.
Finally you can boot moth 9load and the kernel from the local disk but
fetch your filesystem root from the remote server.

The only difference between these options is the extra hassle required to
keep the terminal's kernel up to date.

To boot from the network you will probably need to put some more detail into
/lib/ndb/local. if you can go the PXE route then put its plan9.ini /cfg/pxe/xxxxxxx
where xxxxxx is the MAC address of the terminal in lower case hex.

here is an example, though is relates to native plan9 rather than
qemu, but hopefully the recipe will be similar.
My file/auth/cpu server is felix, the terminal is glass

contents of /cfg/pxe/0002b31af559

bootfile=ether0!felix!/386/9pc
bootargs=tcp
nobootprompt=tcp
vgasize=1024x768x8
monitor=xga
mouseport=ps2
ether0=type=i82557 media=100BASE-FX

from /lib/ndb/local

sys=brick ether=0002b31af559
ip=192.168.0.7
bootf=/386/9pxeload

ipnet=myhome ip=192.168.0.0 ipmask=255.255.255.0
ipgw=192.168.0.1
dns=194.168.4.100 dns=194.168.8.100
dnsdomain=quintile.net
nntp=news.myisp.com
smtp=smtp.myisp.com
ntp=gb.public.ntp.get-time.net
authdom=home.quintile.net
auth=felix
cpu=felix
fs=felix
-Steve

William Josephson

unread,
Feb 27, 2007, 4:20:52 PM2/27/07
to
On Tue, Feb 27, 2007 at 09:12:21PM +0000, Steve Simon wrote:
> I don't know how you would use qemu to netboot plan9 as the server
> uses the ethernet address of the client to decide who it is and which
> kernel it give it. As this MAC is also assigned to the host machine
> then things could get confused, perhaps there is some way of virtualising
> MACs?

You can just assign one to the virtual NIC and use bridging.

John Floren

unread,
Feb 27, 2007, 5:48:07 PM2/27/07
to
Well, I tried the simplest thing--running qemu with -net nic -net user
and just selecting "root from" as tcp on my standalone terminal.
I typed "tcp -g 10.0.2.2 ether /net/ether0 10.0.2.15 255.255.255.0" (I
gathered this by booting normally, running ip/ipconfig, and reading
/net/ndb), then I entered my server's address at the prompts for file
and auth servers. However, after I give it my username and hit enter,
I get the following:
boot: can't connect to file server: connection refused
panic: boot process died: unknown
panic: boot process died: unknown
dumpstack disabled
cpu0: exiting

I had previously opened /srv/fscons and entered "listen tcp!*!564"
Is there a way to check if my requests are even getting through to the
file server?
Thanks

Russ Cox

unread,
Feb 27, 2007, 6:27:43 PM2/27/07
to
This should work as far as Plan 9 is concerned.
It's qemu that is troublesome. One possible approach
to debugging is to boot the live (install) CD and then
run ip/ipconfig -g 10.0.2.2 ether /net/ether0 10.0.2.15 255.255.255.0
and see if that's enough to get a working network (i.e.,
can you ping or telnet to port 567 or 9fs the remote machine).

I have this script as my /etc/qemu-ifup, though I can't
remember exactly why it is needed:

#!/bin/sh
sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1

Russ

ron minnich

unread,
Feb 28, 2007, 2:15:22 PM2/28/07
to
FWIW, the tiny horrible xen boots a terminal just fine. We've booted
from random places with 9grid.net as our fs etc. server.

ron

Armando Camarero

unread,
Feb 28, 2007, 2:45:06 PM2/28/07
to
Russ Cox escribió:
I'm trying to manually configure the NIC in a normal Plan 9 install on
QEMU. If I run ip/ipconfig (so it gets configured using DHCP) /net/ndb
looks:

ip=10.0.2.15 ipmask=255.255.255.0 ipgw=10.0.2.2
dns=10.0.2.3

and network works fine.

But if I run ip/ipconfig -g 10.0.2.2 ether /net/ether0 10.0.2.15
255.255.255.0 it looks:

ip=10.0.2.15 ipmask=/120 ipgw=10.0.2.2

and I can't use network. Is "ipmask=/120" correct?

Is this what makes Plan 9 not boot using network in QEMU?

Armando.

Gabriel Diaz

unread,
Feb 28, 2007, 2:56:24 PM2/28/07
to
hello

i think /120 is /24 in ipv6 address space, it seems correct to me.

gabi

Bakul Shah

unread,
Feb 28, 2007, 3:22:29 PM2/28/07
to
> This should work as far as Plan 9 is concerned.
> It's qemu that is troublesome. One possible approach
> to debugging is to boot the live (install) CD and then
> run ip/ipconfig -g 10.0.2.2 ether /net/ether0 10.0.2.15 255.255.255.0
> and see if that's enough to get a working network (i.e.,
> can you ping or telnet to port 567 or 9fs the remote machine).

In "qemu -net user" mode there are all sorts of restrictions
as qemu emulates the network layer + some userful services.
In particular all connections must be initiated from the VM
and ping won't work except to the port emulated by qemu.
Though, telnet from the VM should should work. if a p9
terminal needs to `listen' on a port, -net user won't work.

> I have this script as my /etc/qemu-ifup, though I can't
> remember exactly why it is needed:
>
> #!/bin/sh
> sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1

When you use -net tap, this script sets IP address for the
host side of the tap interface. Packets pushed on this
interface pop up in corresponding /dev/tapN device (to be
read by qemu) and vice versa.

A more useful thing to do is to bridge the tap interface to
host's physical interface (or the host has to be a router and
provide other necessary things in your enviroments, such as
dhcp daemon or relay etc.). Under FreeBSD-6 or later you can
have qemu-ifup do something like

#!/bin/sh
sudo sh -c "/sbin/ifconfig $1 up; /sbin/ifconfig bridge0 addm $1"

You don't need to give either bridge0 or the tap device any
IP address. Prior to invoking qemu run the following and
also add these lines to /etc/rc.local.

/sbin/ifconfig bridge0 create
/sbin/ifconfig bridge0 addm em0 up

Replace em0 with your machine's real ethernet interface name.
If you want to run more than one qemu instance on the same
machine, you will need to specify mac addresses for
additional instances.

I imagine similar instructions exist for a linux/windows/mac hosts.

erik quanstrom

unread,
Feb 28, 2007, 10:13:21 PM2/28/07
to
you learn something new every day. i didn't know about the -p option to ip/ipconfig.

the function that does the work for dhcp and ip/ipconfig is parseipmask(2).
parseipmask does not differentiate between "255.255.255.0" and "/120",
so it is not likely to be the problem.

the other difference in your ndb entries is the missing dns entry in
the second. how did you check that the network doesn't work? have you tried to
ping the gateway?
ip/ping 10.0.2.2
if that works, it's a dns problem.

- erik

Armando Camarero <arc...@arcepi.net> writes

Armando Camarero

unread,
Mar 1, 2007, 8:20:36 AM3/1/07
to
erik quanstrom escribió:

> you learn something new every day. i didn't know about the -p option to ip/ipconfig.
>
> the function that does the work for dhcp and ip/ipconfig is parseipmask(2).
> parseipmask does not differentiate between "255.255.255.0" and "/120",
> so it is not likely to be the problem.
>
> the other difference in your ndb entries is the missing dns entry in
> the second. how did you check that the network doesn't work? have you tried to
> ping the gateway?
> ip/ping 10.0.2.2
> if that works, it's a dns problem.
>
> - erik
I tried again and network works. I tried network using links the first
time, but it doesn't seem to understand that 172.26.0.4 shouldn't be
resolved via DNS. Ping to the QEMU gateway works and I can test that TCP
does too using ssh (well, I just see the error message that says it
doesn't support SSH2).

Armando.

0 new messages