Well, since the system that will be running the umls *cannot* go down,
I'll go with tun/tap. Now the question is how easy is it to bridge the
uml hosts (which would be accessible via the tap device on the host),
with the LAN.
Just to make sure I'm going down the right path:
This would require me to setup umls with LAN IPs, the Host's tap device
with a different LAN IP, and then add host routes on the host for each
uml to the tap device. Then add an arp entry for the uml on the hosts
public interface (i.e. eth0). And finally enabling arp proxying and ip
forwarding on the host.
Will this then allow for the umls to be accessible on the LAN directly?
Thanks a ton.
On Tue, 2003-01-28 at 16:21, James Neal wrote:
> On Tue, 2003-01-28 at 15:18, Sean McAvoy wrote:
> > Hello,
> > I am looking at using uml to have several uml's running on a single host
> > to provide various services (mysql/postgres/apache) on the LAN. I am
> > trying to decide which method would be best, Tun/TAP or the switch
> > daemon.
> I'd say avoid uml_switch if you can.. Though I know nothing about its
> actual stability, it seems like just another piece that could fail, and
> if it does, it means rebooting (or just restarting networking on?) all
> the UMLs that are connected to it.
> > I would like to be able to easly add and remove umls to and from the
> > host, so a minimal amount of setup time would be ideal.
> > It seems like the switch daemon would be best for this, but I would also
> > like to make use of DHCP for assigning IPs (the host they would be
> > running on is also the dhcp server). Any suggestions would be much
> > appreciated. Thanks.
> The tradeoff for using DHCP to assign IP addresses to UML nodes is that
> you'll need to manually assign each UML a unique MAC address as an
> argument to the eth0= kernel option. This is because the MAC address of
> the interface is set to "fe:fd:0:0:0:0" on each UML before it's assigned
> an IP address, which confuses the DHCP server. ("What? You again?
> Didn't you just ask for an IP address? Well, here it is again.")
> I suppose given the choice between manually assigning it a MAC addr and
> letting it DHCP, and manually assigning it an IP addr on the command
> line, the DHCP option would probably work best. I've not tried
> assigning the IP address using arguments to the ethN kernel parameter.