| 1 |
On Tuesday, December 09, 2014 02:26:24 PM thegeezer wrote: |
| 2 |
> On 08/12/14 22:17, lee wrote: |
| 3 |
> > "J. Roeleveld" <joost@××××××××.org> writes: |
| 4 |
> >> create 1 bridge per physical network port |
| 5 |
> >> add the physical ports to the respective bridges |
| 6 |
> > |
| 7 |
> > That tends to make the ports disappear, i. e. become unusable, because |
| 8 |
> > the bridge swallows them. |
| 9 |
> |
| 10 |
> and if you pass the device then it becomes unusable to the host |
| 11 |
|
| 12 |
Pass device: It is unavailable to the host |
| 13 |
Add it to a bridge: you can still have an IP on that network. |
| 14 |
|
| 15 |
> >> pass virtual NICs to the VMs which are part of the bridges. |
| 16 |
> > |
| 17 |
> > Doesn't that create more CPU load than passing the port? And at some |
| 18 |
> > point, you may saturate the bandwidth of the port. |
| 19 |
> |
| 20 |
> some forward planning is needed. obviously if you have two file servers |
| 21 |
> using the same bridge and that bridge only has one physical port and the |
| 22 |
> SAN is not part of the host then you might run into trouble. |
| 23 |
|
| 24 |
Same is true when you have a single "dumb" switch with physical machines |
| 25 |
instead of VMs. |
| 26 |
|
| 27 |
> however, |
| 28 |
> you can use bonding in various ways to group connections -- and in this |
| 29 |
> way you can have a virtual nic that actually has 2x 1GB bonded devices, |
| 30 |
> or if you choose to upgrade at a later stage you can start putting in |
| 31 |
> 10GbE cards and the virtual machine sees nothing different, just access |
| 32 |
> is faster. |
| 33 |
|
| 34 |
+1, it really is that simple. |
| 35 |
|
| 36 |
> on the flip side you can have four or more relatively low bandwidth |
| 37 |
> requirement virtual machines running on the same host through the same |
| 38 |
> single physical port |
| 39 |
> think of the bridge as an "internal, virtual, network switch"... you |
| 40 |
> wouldn't load up a switch with 47 high bandwidth requirement servers and |
| 41 |
> then create a single uplink to the SAN / other network without seriously |
| 42 |
> considering bonding or partitioning in some way to reduce the 47into1 |
| 43 |
> bottleneck, and the same is true of the virtual-switch (bridge) |
| 44 |
|
| 45 |
The virtual-switch can handle more bandwidth then a physical one (unless you |
| 46 |
pay for high-speed hardware) |
| 47 |
|
| 48 |
> the difference is that you need to physically be there to repatch |
| 49 |
> connections or to add a new switch when you run out of ports. these |
| 50 |
> limitations are largely overcome. |
| 51 |
> |
| 52 |
> >> But it's your server, you decide on the complexity. |
| 53 |
> >> |
| 54 |
> >> I stopped passing physical NICs when I was encountering issues with newer |
| 55 |
> >> cards. |
| 56 |
> >> They are now resolved, but passing virtual interfaces is simpler and more |
| 57 |
> >> reliable. |
| 58 |
> > |
| 59 |
> > The only issue I have with passing the port is that the kernel module |
| 60 |
> > must not be loaded from the initrd image. So I don't see how fighting |
| 61 |
> > with the bridges would make things easier. |
| 62 |
> |
| 63 |
> vif=[ 'mac=de:ad:be:ef:00:01,bridge=br0' ] |
| 64 |
> |
| 65 |
> am i missing where the fight is ? |
| 66 |
|
| 67 |
I'm wondering the same. :) |
| 68 |
|
| 69 |
> the only issue with bridges is that if eth0 is in the bridge, if you try |
| 70 |
> to use eth0 directly with for example an IP address things go a bit |
| 71 |
> weird, so you have to use br0 instead |
| 72 |
|
| 73 |
Give br0 an IP instead of eth0 and it will work. |
| 74 |
|
| 75 |
> so don't do that. |
| 76 |
> perhaps you don't need a full bridge and you might just prefer to lookup |
| 77 |
> macvlan instead. |
| 78 |
> this lets you create a new virtual device that behaves much more like a |
| 79 |
> secondary nic |
| 80 |
> e.g. in /etc/conf.d/net |
| 81 |
> |
| 82 |
> macvlan_xenguest1="eth0" |
| 83 |
> mode_xenguest1="private" |
| 84 |
> mac_xenguest1="de:ad:be:ef:00:01" |
| 85 |
> config_xenguest1="192.168.1.12/24" |
| 86 |
> routes_xenguest1="default via 192.168.1.1" |
| 87 |
> modules_xenguest1="!ifplugd" |
| 88 |
> |
| 89 |
> you can then |
| 90 |
> /etc/init.d/net.xenguest1 start |
| 91 |
> |
| 92 |
> i'm not big into xen but i believe you should be able to pass this as a |
| 93 |
> "physical" device to xen and it then comes out on network interface eth0 |
| 94 |
> this way you get to keep your port without it being eaten by the bridge |
| 95 |
> do let me know if this works with xen i'll add it to my toolbox |
| 96 |
|
| 97 |
I never heard of "macvlan" myself, but the networking I use is as follows: |
| 98 |
|
| 99 |
**** |
| 100 |
# using the udev name randomizer names as the kernel-option is ignored |
| 101 |
config_enp4s0="null" |
| 102 |
config_enp5s0="null" |
| 103 |
config_enp6s0="null" |
| 104 |
config_enp7s0="null" |
| 105 |
|
| 106 |
# Add all physical ports into a single bonded interface |
| 107 |
slaves_bond0="enp4s0 enp5s0 enp6s0 enp7s0" |
| 108 |
config_bond0="null" |
| 109 |
rc_net_bond0_need="net.enp4s0 net.enp5s0 net.enp6s0 net.enp7s0" |
| 110 |
|
| 111 |
# Split the bonded interface into seperate VLANs. |
| 112 |
vlans_bond0="1 2 3 4" |
| 113 |
vlan1_name="lan" |
| 114 |
vlan2_name="gst" |
| 115 |
vlan3_name="vm" |
| 116 |
vlan4_name="net" |
| 117 |
vlan_start_bond0="no" |
| 118 |
rc_net_adm_need="net.bond0" |
| 119 |
rc_net_lan_need="net.bond0" |
| 120 |
rc_net_net_need="net.bond0" |
| 121 |
|
| 122 |
# Configure the bridges |
| 123 |
config_lan="null" |
| 124 |
bridge_brlan="lan" |
| 125 |
rc_net_brlan_need="net.lan" |
| 126 |
|
| 127 |
config_gst="null" |
| 128 |
bridge_brgst="gst" |
| 129 |
rc_net_brgst_need="net.gst" |
| 130 |
|
| 131 |
config_vm="null" |
| 132 |
bridge_brvm="vm" |
| 133 |
rc_net_brvm_need="net.vm" |
| 134 |
|
| 135 |
config_net="null" |
| 136 |
bridge_brnet="net" |
| 137 |
rc_net_brnet_need="net.net" |
| 138 |
|
| 139 |
# Configure the IP for the host |
| 140 |
config_brlan="1.2.3.4 netmask 255.255.255.0 broadcast 1.2.3.255" |
| 141 |
routes_brlan="default gw 1.2.3.1" |
| 142 |
|
| 143 |
config_brgst="null" |
| 144 |
|
| 145 |
config_brvm="null" |
| 146 |
|
| 147 |
config_brnet="null" |
| 148 |
|
| 149 |
**** |
| 150 |
|
| 151 |
-- |
| 152 |
Joost |
Archives