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
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
You can just assign one to the virtual NIC and use bridging.
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
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
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.
i think /120 is /24 in ipv6 address space, it seems correct to me.
gabi
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.
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.