On 29/12/14 13:55, lee wrote:
> thegeezer <thegee...@thegeezer.net> writes:
>
>> 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
> The VM uses it instead, which is what I wanted :)
>
>>>> 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. 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.
>> 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 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.
> That all makes sense; my situation is different, though. I plugged a
> dual port card into the server and wanted to use one of the ports for
> another internet connection and the other one for a separate network,
> with firewalling and routing in between. You can't keep the traffic
> separate when it all goes over the same bridge, can you?
>
> And the file server could get it's own physical port --- not because
> it's really needed but because it's possible. I could plug in another
> dual-port card for that and experiment with bonding.
>
> However, I've changed plans and intend to use a workstation as a hybrid
> system to reduce power consumption and noise, and such a setup has other
> advantages, too. I'll put Gentoo on it and probably use containers for
> the VMs. Then I can still use the server for experiments and/or run
> distcc on it when I want to.
>
>>> 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 ?
> setting up the bridges
>
> no documentation about in which order a VM will see the devices
>
> a handful of bridges and VMs
>
> a firewall/router VM with it's passed-through port for pppoe and three
> bridges
>
> the xen documentation being an awful mess
>
> an awful lot of complexity required
>
>
> Guess what, I still haven't found out how to actually back up and
> restore a VM residing in an LVM volume. I find it annoying that LVM
> doesn't have any way of actually copying a LV. It could be so easy if
> you could just do something like 'lvcopy lv_source
> other_host:/backups/lv_source_backup' and 'lvrestore
> other_host:/backups/lv_source_backup vg_target/lv_source' --- or store
> the copy of the LV in a local file somewhere.
agreed. you have two choices, you can either use dd and clone the LV
like a normal partition.
alternatively you can use split mirrors and i do this to clone up
physical devices:
1. make a mirror of the lv you want to copy to /dev/usb1
2. # lvconvert --splitmirrors 2 --name copy vg/lv /dev/usb1
in 2 it says
" split the mirror into two parts
give the new version the name 'copy'
leave this on the pv /dev/usb1 "
you then need to remove it if you want from your voume group
> Just why can't you? ZFS apparently can do such things --- yet what's
> the difference in performance of ZFS compared to hardware raid?
> Software raid with MD makes for quite a slowdown.
sorry but that's just not true, if you choose the correct raid level and
stripe it can easily compete, and be more portable (you don't have to
find the identical raid card if the raid card goes bang); many raid card
i would argue are even underpowered for their required iops
>
>> 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
>> so don't do that.
> Yes, it's very confusing.
>
>> 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
> Hmm, and where's the other end of it? Some physical port?
wherever you would like it to be. in the example above
macvlan_xenguest1="eth0"
it is eth0
> So it's like
> plugging in several virtual cables into the same physical port, with a
> built-in firewall and router?
>
>
pretty much.
i'd recommend you go find out more about bridging at [1] [2] [3]
it's a bit difficult to describe a generic case that fits your case
without knowing your case.
a bridge is basically like a dumb network switch
with openrc [3] you can easily
create a bridge with /etc/conf.d/net as follows
# bridge ports defined empty to avoid DHCP being run for their configuration
config_eth0="null"
config_eth1="null"
# bridge
config_br0="192.168.69.69/24"
brctl_br0="setfd 0
sethello 10
stp off"
bridge_br0="eth0 eth1"
you can then setup /etc/init.d/net.br0 and start it
from this point on everything that comes in to either eth0 or eth1 for
IP address 192.168.69.69 gets accepted by the gentoo kernel.
if there is a frame coming in on eth0 that is not for the gentoo kernel,
but is for a mac address on eth1 then it gets forwarded on.
if there is a frame comig in on eth0 that is not for the gentoo kernel
but is for a mac address on eth0 then it is ignored.
when you start to talk about virtual machines, then the same principles
apply
if you only have one virtual machine and one internet connection then
yes perhaps it is not necessary to have a bridge, but if you have one
network card and many virtual machines then it is necessary
[1] http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO-3.html#ss3.1
[2] http://ebtables.netfilter.org/documentation/bridge-nf.html
[3] http://wiki.gentoo.org/wiki/Network_bridge
