| 1 |
On 08/12/14 22:17, lee wrote: |
| 2 |
> "J. Roeleveld" <joost@××××××××.org> writes: |
| 3 |
> |
| 4 |
>> create 1 bridge per physical network port |
| 5 |
>> add the physical ports to the respective bridges |
| 6 |
> That tends to make the ports disappear, i. e. become unusable, because |
| 7 |
> the bridge swallows them. |
| 8 |
and if you pass the device then it becomes unusable to the host |
| 9 |
|
| 10 |
> |
| 11 |
>> pass virtual NICs to the VMs which are part of the bridges. |
| 12 |
> Doesn't that create more CPU load than passing the port? And at some |
| 13 |
> point, you may saturate the bandwidth of the port. |
| 14 |
|
| 15 |
some forward planning is needed. obviously if you have two file servers |
| 16 |
using the same bridge and that bridge only has one physical port and the |
| 17 |
SAN is not part of the host then you might run into trouble. however, |
| 18 |
you can use bonding in various ways to group connections -- and in this |
| 19 |
way you can have a virtual nic that actually has 2x 1GB bonded devices, |
| 20 |
or if you choose to upgrade at a later stage you can start putting in |
| 21 |
10GbE cards and the virtual machine sees nothing different, just access |
| 22 |
is faster. |
| 23 |
on the flip side you can have four or more relatively low bandwidth |
| 24 |
requirement virtual machines running on the same host through the same |
| 25 |
single physical port |
| 26 |
think of the bridge as an "internal, virtual, network switch"... you |
| 27 |
wouldn't load up a switch with 47 high bandwidth requirement servers and |
| 28 |
then create a single uplink to the SAN / other network without seriously |
| 29 |
considering bonding or partitioning in some way to reduce the 47into1 |
| 30 |
bottleneck, and the same is true of the virtual-switch (bridge) |
| 31 |
|
| 32 |
the difference is that you need to physically be there to repatch |
| 33 |
connections or to add a new switch when you run out of ports. these |
| 34 |
limitations are largely overcome. |
| 35 |
|
| 36 |
> |
| 37 |
>> But it's your server, you decide on the complexity. |
| 38 |
>> |
| 39 |
>> I stopped passing physical NICs when I was encountering issues with newer |
| 40 |
>> cards. |
| 41 |
>> They are now resolved, but passing virtual interfaces is simpler and more |
| 42 |
>> reliable. |
| 43 |
> The only issue I have with passing the port is that the kernel module |
| 44 |
> must not be loaded from the initrd image. So I don't see how fighting |
| 45 |
> with the bridges would make things easier. |
| 46 |
> |
| 47 |
> |
| 48 |
|
| 49 |
vif=[ 'mac=de:ad:be:ef:00:01,bridge=br0' ] |
| 50 |
|
| 51 |
am i missing where the fight is ? |
| 52 |
|
| 53 |
the only issue with bridges is that if eth0 is in the bridge, if you try |
| 54 |
to use eth0 directly with for example an IP address things go a bit |
| 55 |
weird, so you have to use br0 instead |
| 56 |
so don't do that. |
| 57 |
perhaps you don't need a full bridge and you might just prefer to lookup |
| 58 |
macvlan instead. |
| 59 |
this lets you create a new virtual device that behaves much more like a |
| 60 |
secondary nic |
| 61 |
e.g. in /etc/conf.d/net |
| 62 |
|
| 63 |
macvlan_xenguest1="eth0" |
| 64 |
mode_xenguest1="private" |
| 65 |
mac_xenguest1="de:ad:be:ef:00:01" |
| 66 |
config_xenguest1="192.168.1.12/24" |
| 67 |
routes_xenguest1="default via 192.168.1.1" |
| 68 |
modules_xenguest1="!ifplugd" |
| 69 |
|
| 70 |
you can then |
| 71 |
/etc/init.d/net.xenguest1 start |
| 72 |
|
| 73 |
i'm not big into xen but i believe you should be able to pass this as a |
| 74 |
"physical" device to xen and it then comes out on network interface eth0 |
| 75 |
this way you get to keep your port without it being eaten by the bridge |
| 76 |
do let me know if this works with xen i'll add it to my toolbox |
Archives