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. 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. > 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? So it's like plugging in several virtual cables into the same physical port, with a built-in firewall and router? -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
