| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Network-bridge script with bonding and vlan
----- Original Message -----
From: "Ewan Mellor" <ewan@xxxxxxxxxxxxx>
The new script allows for one bridge per outgoing interface, I think, so
in
your case one bridge per VLAN ought to be possible. Why do you need one
bridge per domain? What are you bridging in this case? The topology we
use
uses a bridge to plex all of the guests onto a specific outgoing
interface --
so what are you bridging to require one per domain?
The main outcome I'm trying to achieve is isolation between the domains.
Typically we would have this separation between our production servers (not
all lumped together on one LAN). Having the separation at layer 2 would
seem like to be a positive thing to maintain. Using the VLAN interfaces
gives the impression that the machine has many network adapters [this would
seem to me to be a good fit with a virtualisation technology].
In the trivial case the xen support is vif0.0->veth0, and vifN.0->eth0
(where N is a non-zero domain number).
Do your arrows refer to incoming packets? If so, I think that is right,
though veth0 is renamed to eth0 now, so that dom0 sees a "normal" eth0
interface.
Sorry, I wasn't very clear there. Yes, incoming packets, or
backend<->frontend.
The scripts seem to treat xen0 as a special case, and I'm not sure why.
Domain 0 is the privileged domain i.e. the one that manages the creation
of
other domains. It comes up on boot, and is where things like the script
in
question are running. That is why it is a special case. Also, it is
arranged
so that dom0's interface appears to have the MAC address of the underlying
NIC -- you can't do this with the guest domains, of course.
Got that. But could the part of the dom0 script that configures the dom0
vif0.0<->veth0 part of the networking be extracted/pluggable just like the
domU setup of the vifN.0 interface.
I've no idea whether that makes sense, but why are you trying to do it?
I guess it comes from the desire not to configure an interface one way, and
then moments later tear it all down and configure it another way. I can see
that the current way is great for development, and integrates well with an
existing machine - not sure I'd want to head in that direction on a
non-development system.
The bottom line, I think, is that Xen does not try to do everything with
network configuration. We are happy to help, and happy to provide example
Thanks very much for your feedback. I lot of my comments are probably due to
being a relative newbie.
Most of the configuration I have been doing has been with the fc4 init
scripts. I'm looking for less, rather than more. However I am having
problems getting packets forwarded/bridged correctly. ICMP pings seem to
work just fine, but the only way to get TCP/UDP packets to forward is to
attach tcpdump to the VLAN interface. I probably missing something very
obvious. I don't have the machine in front of me (and the networking isn't
working), so can't post the current config.
I'm unclear as to why the physical/bridge/backend interfaces need to have a
special mac address (fe:ff:ff:ff:ff:ff), and why they need arp disabled
(since they have no IP address). What is special about fe:ff:ff:ff:ff:ff?
Could it be any locally assigned unicast mac address?
Greg.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home