On Tuesday, December 09, 2014 02:26:24 PM thegeezer wrote: > On 08/12/14 22:17, lee wrote: > > "J. Roeleveld" <jo...@antarean.org> writes: > >> create 1 bridge per physical network port > >> add the physical ports to the respective bridges > > > > That tends to make the ports disappear, i. e. become unusable, because > > the bridge swallows them. > > and if you pass the device then it becomes unusable to the host
Pass device: It is unavailable to the host
Add it to a bridge: you can still have an IP on that network.
> >> pass virtual NICs to the VMs which are part of the bridges.
> >
> > Doesn't that create more CPU load than passing the port? And at some
> > point, you may saturate the bandwidth of the port.
>
> some forward planning is needed. obviously if you have two file servers
> using the same bridge and that bridge only has one physical port and the
> SAN is not part of the host then you might run into trouble.
Same is true when you have a single "dumb" switch with physical machines
instead of VMs.
> however,
> you can use bonding in various ways to group connections -- and in this
> way you can have a virtual nic that actually has 2x 1GB bonded devices,
> or if you choose to upgrade at a later stage you can start putting in
> 10GbE cards and the virtual machine sees nothing different, just access
> is faster.
+1, it really is that simple.
> on the flip side you can have four or more relatively low bandwidth
> requirement virtual machines running on the same host through the same
> single physical port
> think of the bridge as an "internal, virtual, network switch"... you
> wouldn't load up a switch with 47 high bandwidth requirement servers and
> then create a single uplink to the SAN / other network without seriously
> considering bonding or partitioning in some way to reduce the 47into1
> bottleneck, and the same is true of the virtual-switch (bridge)
The virtual-switch can handle more bandwidth then a physical one (unless you
pay for high-speed hardware)
> the difference is that you need to physically be there to repatch
> connections or to add a new switch when you run out of ports. these
> limitations are largely overcome.
>
> >> But it's your server, you decide on the complexity.
> >>
> >> I stopped passing physical NICs when I was encountering issues with newer
> >> cards.
> >> They are now resolved, but passing virtual interfaces is simpler and more
> >> reliable.
> >
> > The only issue I have with passing the port is that the kernel module
> > must not be loaded from the initrd image. So I don't see how fighting
> > with the bridges would make things easier.
>
> vif=[ 'mac=de:ad:be:ef:00:01,bridge=br0' ]
>
> am i missing where the fight is ?
I'm wondering the same. :)
> the only issue with bridges is that if eth0 is in the bridge, if you try
> to use eth0 directly with for example an IP address things go a bit
> weird, so you have to use br0 instead
Give br0 an IP instead of eth0 and it will work.
> so don't do that.
> perhaps you don't need a full bridge and you might just prefer to lookup
> macvlan instead.
> this lets you create a new virtual device that behaves much more like a
> secondary nic
> e.g. in /etc/conf.d/net
>
> macvlan_xenguest1="eth0"
> mode_xenguest1="private"
> mac_xenguest1="de:ad:be:ef:00:01"
> config_xenguest1="192.168.1.12/24"
> routes_xenguest1="default via 192.168.1.1"
> modules_xenguest1="!ifplugd"
>
> you can then
> /etc/init.d/net.xenguest1 start
>
> i'm not big into xen but i believe you should be able to pass this as a
> "physical" device to xen and it then comes out on network interface eth0
> this way you get to keep your port without it being eaten by the bridge
> do let me know if this works with xen i'll add it to my toolbox
I never heard of "macvlan" myself, but the networking I use is as follows:
****
# using the udev name randomizer names as the kernel-option is ignored
config_enp4s0="null"
config_enp5s0="null"
config_enp6s0="null"
config_enp7s0="null"
# Add all physical ports into a single bonded interface
slaves_bond0="enp4s0 enp5s0 enp6s0 enp7s0"
config_bond0="null"
rc_net_bond0_need="net.enp4s0 net.enp5s0 net.enp6s0 net.enp7s0"
# Split the bonded interface into seperate VLANs.
vlans_bond0="1 2 3 4"
vlan1_name="lan"
vlan2_name="gst"
vlan3_name="vm"
vlan4_name="net"
vlan_start_bond0="no"
rc_net_adm_need="net.bond0"
rc_net_lan_need="net.bond0"
rc_net_net_need="net.bond0"
# Configure the bridges
config_lan="null"
bridge_brlan="lan"
rc_net_brlan_need="net.lan"
config_gst="null"
bridge_brgst="gst"
rc_net_brgst_need="net.gst"
config_vm="null"
bridge_brvm="vm"
rc_net_brvm_need="net.vm"
config_net="null"
bridge_brnet="net"
rc_net_brnet_need="net.net"
# Configure the IP for the host
config_brlan="1.2.3.4 netmask 255.255.255.0 broadcast 1.2.3.255"
routes_brlan="default gw 1.2.3.1"
config_brgst="null"
config_brvm="null"
config_brnet="null"
****
--
Joost
