"J. Roeleveld" <jo...@antarean.org> writes:
>> with firewalling and routing in between. You can't keep the traffic
>> separate when it all goes over the same bridge, can you?
>
> Not if it goes over the same bridge. But as they are virtual, you can make as
> many as you need.
I made as few as I needed. What sense would it make to, necessarily,
use a physical port for a pppoe connection and then go to the lengths of
creating a bridge for it to somehow bring it over to the VM? I found it
way easier to just pass the physical port to the VM.
>> > am i missing where the fight is ?
>>
>> setting up the bridges
>
> Really simple, there are plenty of guides around. Including how to configure
> it
> using netifrc (which is installed by default on Gentoo)
Creating a bridge isn't too difficult; getting it work is.
>> no documentation about in which order a VM will see the devices
>
> Same goes for physical devices.
That doesn't make it any better.
> Use udev-rules to name the interfaces
> logically based on the MAC-address:
> ***
> # cat 70-persistent-net.rules
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:16:3e:16:01:01", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="lan"
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:16:3e:16:01:02", ATTR{dev_id}=="0x0", ATTR{type}=="1",
> KERNEL=="eth*", NAME="dmz"
> ***
Who understands udev?
>> a handful of bridges and VMs
>
> Only 1 bridge per network segment is needed.
Yes, and that makes for a handful.
>> a firewall/router VM with it's passed-through port for pppoe and three
>> bridges
>
> Not difficult, had that for years till I moved the router to a seperate
> machine.
> (Needed something small to fit the room where it lives)
It's extremely confusing, difficult and complicated.
>> the xen documentation being an awful mess
>
> A lot of it is outdated. A big cleanup would be useful there.
Yes, it tells you lots of things that you find not to work and confuses
you even more until you don't know what to do anymore because nothing
works.
>> an awful lot of complexity required
>
> There is a logic to it.
If there is, it continues to escape me.
>> 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.
>
> What do you consider "hardware raid" in this comparison?
A decent hardware raid controller, like an HP smart array P800 or an IBM
ServeRaid 8k --- of course, they are outdated, yet they work well.
> Most so-called hardware raid cards depend heavily on the host CPU to do all
> the calculations and the code used is extremely inefficient.
> The Linux build-in software raid layer ALWAYS outperforms those cards.
You mean the fake controllers? I wouldn't use those.
> The true hardware raid cards have their own calculation chips to do the heavy
> lifting. Those actually stand a chance to outperform the linux software raid
> layer. It depends on the spec of the host CPU and what you use the system for.
With all CPUs, relatively slow and relatively fast ones, I do notice an
awful sluggishness with software raid which hardware raid simply doesn't
have. This sluggishness might not be considered or even noticed by a
benchmark you might run, yet it is there.
> ZFS and BTRFS runs fully on the host CPU, but has some additional logic built-
> in which allows it to generally outperform hardware raid.
I can't tell for sure yet; so far, it seems that they do better than md
raid. Btrfs needs some more development ... ZFS with SSD cache is
probably hard to beat.
> I could do with a hardware controller which can be used to off-load all the
> heavy lifting for the RAIDZ-calculations away from the CPU. And if the stuff
> for the deduplication could also be done that way?
Yes, I've already been wondering why they don't make hardware ZFS
controllers. There doesn't seem to be much point in making "classical"
hardware raid controllers while ZFS has so many advantages over them.
>> > 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.
>
> It's just using a different name. Once it's configured, the network layer of
> the
> OS handles it for you.
I understand things by removing abstractions. When you remove all
abstractions from a bridge, there isn't anything left. A network card,
you can take into your hands and look at it; you can plug and unplug the
wire(s); these cards usually have fancy lights to show you whether
there's a connection or not, and the lights even blink when there's
network traffic. A bridge doesn't exist, has nothing and shows you
nothing. It's not understandable because it isn't anything, no matter
how it's called or handled.
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
