As I see it there are 3 possible ways of getting
networking going. Ordered from what I think is the
best to the worst. Although all should work, and
hence be considered good.
Note: In all cases the simulated NE2000 in the guest
sees a sanitised network with the only traffic being
between the host and the guest. Having the ability
to use tcpdump on the guest and see all network
activity is too complicated.
1) For each guest instance add an IP alias to the
main ethernet interface and use some mechanism
such as a netfilter (Linux) or bpf (BSD) or
divert sockets (FreeBSD) to reroute packets for
the guest IP address to Plex86. The host will
proxy ARP for the guest, so it essentially appears
as another machine on the LAN segment.
Pros:
The guest is assigned an IP address on the LAN
segment that can be directly routed to from
other devices, included the internet.
Doesn't require any special support to be added
to the kernel and can be fully implemented in
userland on most Unix (that support IP aliasing
and have some IP filtering capability/bpf) and
Windows (I think with the bpf port).
Cons:
Depends on bpf support on targeted hosts. Is
possibly classed as a hack as uses a couple
of kernel functions for unintended purposes.
Requires a process to handle the bpf interface
on behalf of all guests. If this fails then all
guests go off air. At least I think so, I don't
know if multiple processes can have bpf open
on the same interface at the same time.
2) Use the tun/tap standard interface to create a
private network (10.x.x.x address for example).
The host and all guests have their own IP
address in this network with the host routing
from the LAN to the private network.
Pros:
Doesn't require the use of hacks, standard
network devices can be used for their intended
function. Can be fully implemented from userland.
The guest can enable promiscuous mode on the NE2000
and see traffic between the host and all guests on
the private network.
Cons:
The guests will not be routable from the internet
unless you are willing to create subnets, or use
a full network, for the Plex86 network. Most
people will use a 10.x.x.x or 192.168.x.x address
which will require NAT on the host to provide
Internet access to the guests.
Requires a process to handle the network tun/tap
interface on behalf of all guests. If this fails
then all guests go off air.
3) Create virtual point to point devices in the kernel
for each Plex86 instance. Works like the VMware
vmnet devices. In essence the host has N p2p links
to each guest using pxnet0, pxnet1, pxnet2, etc.
Pros:
Each Plex86 instance has its own device to manage as
it sees fit without affecting other instances.
Cons:
Requires kernel modules for each OS to provide this
virtual network device.
The guests will not be routable from the internet
unless you are willing to create subnets, or use
a full network, for the Plex86 network. Most
people will use a 10.x.x.x or 192.168.x.x address
which will require NAT on the host to provide
Internet access to the guests.
Each guest cannot contact the other without a default
route (or network route or routing daemon) being added
to all guest OS configurations.
Resource waste by having a device for each instance.
P.S. My preference is for Plex86 to be portable
code that doesn't require kernel modules/patches
etc where practicle. However a small module that
is easily ported to another OS is acceptible where
it is the only solution or used as an optimisation
for a particular host OS even though a portable
mechanism exists for other host OSes.
__________________________________________________
John Saunders -- ResMed Limited
97 Waterloo Road, North Ryde NSW 2113, Australia.
Phone: +61-2-9886-5433� Email: [EMAIL PROTECTED]
