tftp issue when starting 3 VMs

[Frank Mehnert]

On Tuesday 10 May 2005 12:18, Derick Swanepoel wrote:
> On 5/10/05, Frank Mehnert <fm3 at os.inf.tu-dresden.de> wrote:
> > On Tuesday 10 May 2005 11:01, Derick Swanepoel wrote:
> > > I'm trying to start three VMs from grub (one master and two slaves),
> > > but the tftp provider fails to load the third kernel. This file is the
> > > same as the second VM's kernel, which loads successfully.
> >
> > Hmm, no idea. Has your L4Linux a driver for your network card included
> > (it should not). Please post the full log file.
>
> The kernel used for the master VM has a driver for my network card,
> but the two slave kernels do not. Note that everything works fine if I
> start one master and one slave, or two slaves, but not one master and
> two slaves.
>
> However, sometimes it does work, but very infrequently.

This is exactly what I mean. If your master L4Linux instance grabs
the network card, the tftp task owns the network card no longer and
therefore is not able to load something. Note that tftp and L4Linux
access the same hardware device. This works as long as they do it
sequentially.

To overcome this problem, you could load the slave L4Linux instances
with grub, pass them to the bmodfs server and then start them using
the bmodfs server (see generic_fprov/examples/bmodfs).

> I've attached the boot log (it's very long and somewhat hard to make
> sense of because the messages of the master and slave kernel are
> interleaved :( )

Hmm. According that log it seems that the master L4Linux instance
initialized the netword card just while loading the seconds slave
instance, eth0 of Linux is up immediately after the tftp failed.

The right solution for this is to use only _one_ driver for your
network device and to share the driver between tftp and L4Linux.
Both tftp and L4Linux should also support the oshkosh backend.

Or you don't use tftp at all and load the binaries using bmodfs
(maybe this is easier to setup).

Frank
-- 
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## http://os.inf.tu-dresden.de/~fm3                                     ##
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20050510/3fb8b9d0/attachment-0001.sig>