1 |
On 29/12/14 13:55, lee wrote: |
2 |
> thegeezer <thegeezer@×××××××××.net> writes: |
3 |
> |
4 |
>> On 08/12/14 22:17, lee wrote: |
5 |
>>> "J. Roeleveld" <joost@××××××××.org> writes: |
6 |
>>> |
7 |
>>>> create 1 bridge per physical network port |
8 |
>>>> add the physical ports to the respective bridges |
9 |
>>> That tends to make the ports disappear, i. e. become unusable, because |
10 |
>>> the bridge swallows them. |
11 |
>> and if you pass the device then it becomes unusable to the host |
12 |
> The VM uses it instead, which is what I wanted :) |
13 |
> |
14 |
>>>> pass virtual NICs to the VMs which are part of the bridges. |
15 |
>>> Doesn't that create more CPU load than passing the port? And at some |
16 |
>>> point, you may saturate the bandwidth of the port. |
17 |
>> some forward planning is needed. obviously if you have two file servers |
18 |
>> using the same bridge and that bridge only has one physical port and the |
19 |
>> SAN is not part of the host then you might run into trouble. however, |
20 |
>> you can use bonding in various ways to group connections -- and in this |
21 |
>> way you can have a virtual nic that actually has 2x 1GB bonded devices, |
22 |
>> or if you choose to upgrade at a later stage you can start putting in |
23 |
>> 10GbE cards and the virtual machine sees nothing different, just access |
24 |
>> is faster. |
25 |
>> on the flip side you can have four or more relatively low bandwidth |
26 |
>> requirement virtual machines running on the same host through the same |
27 |
>> single physical port |
28 |
>> think of the bridge as an "internal, virtual, network switch"... you |
29 |
>> wouldn't load up a switch with 47 high bandwidth requirement servers and |
30 |
>> then create a single uplink to the SAN / other network without seriously |
31 |
>> considering bonding or partitioning in some way to reduce the 47into1 |
32 |
>> bottleneck, and the same is true of the virtual-switch (bridge) |
33 |
>> |
34 |
>> the difference is that you need to physically be there to repatch |
35 |
>> connections or to add a new switch when you run out of ports. these |
36 |
>> limitations are largely overcome. |
37 |
> That all makes sense; my situation is different, though. I plugged a |
38 |
> dual port card into the server and wanted to use one of the ports for |
39 |
> another internet connection and the other one for a separate network, |
40 |
> with firewalling and routing in between. You can't keep the traffic |
41 |
> separate when it all goes over the same bridge, can you? |
42 |
> |
43 |
> And the file server could get it's own physical port --- not because |
44 |
> it's really needed but because it's possible. I could plug in another |
45 |
> dual-port card for that and experiment with bonding. |
46 |
> |
47 |
> However, I've changed plans and intend to use a workstation as a hybrid |
48 |
> system to reduce power consumption and noise, and such a setup has other |
49 |
> advantages, too. I'll put Gentoo on it and probably use containers for |
50 |
> the VMs. Then I can still use the server for experiments and/or run |
51 |
> distcc on it when I want to. |
52 |
> |
53 |
>>> The only issue I have with passing the port is that the kernel module |
54 |
>>> must not be loaded from the initrd image. So I don't see how fighting |
55 |
>>> with the bridges would make things easier. |
56 |
>>> |
57 |
>>> |
58 |
>> vif=[ 'mac=de:ad:be:ef:00:01,bridge=br0' ] |
59 |
>> |
60 |
>> am i missing where the fight is ? |
61 |
> setting up the bridges |
62 |
> |
63 |
> no documentation about in which order a VM will see the devices |
64 |
> |
65 |
> a handful of bridges and VMs |
66 |
> |
67 |
> a firewall/router VM with it's passed-through port for pppoe and three |
68 |
> bridges |
69 |
> |
70 |
> the xen documentation being an awful mess |
71 |
> |
72 |
> an awful lot of complexity required |
73 |
> |
74 |
> |
75 |
> Guess what, I still haven't found out how to actually back up and |
76 |
> restore a VM residing in an LVM volume. I find it annoying that LVM |
77 |
> doesn't have any way of actually copying a LV. It could be so easy if |
78 |
> you could just do something like 'lvcopy lv_source |
79 |
> other_host:/backups/lv_source_backup' and 'lvrestore |
80 |
> other_host:/backups/lv_source_backup vg_target/lv_source' --- or store |
81 |
> the copy of the LV in a local file somewhere. |
82 |
|
83 |
agreed. you have two choices, you can either use dd and clone the LV |
84 |
like a normal partition. |
85 |
alternatively you can use split mirrors and i do this to clone up |
86 |
physical devices: |
87 |
|
88 |
1. make a mirror of the lv you want to copy to /dev/usb1 |
89 |
2. # lvconvert --splitmirrors 2 --name copy vg/lv /dev/usb1 |
90 |
|
91 |
in 2 it says |
92 |
" split the mirror into two parts |
93 |
give the new version the name 'copy' |
94 |
leave this on the pv /dev/usb1 " |
95 |
|
96 |
you then need to remove it if you want from your voume group |
97 |
|
98 |
> Just why can't you? ZFS apparently can do such things --- yet what's |
99 |
> the difference in performance of ZFS compared to hardware raid? |
100 |
> Software raid with MD makes for quite a slowdown. |
101 |
sorry but that's just not true, if you choose the correct raid level and |
102 |
stripe it can easily compete, and be more portable (you don't have to |
103 |
find the identical raid card if the raid card goes bang); many raid card |
104 |
i would argue are even underpowered for their required iops |
105 |
> |
106 |
>> the only issue with bridges is that if eth0 is in the bridge, if you try |
107 |
>> to use eth0 directly with for example an IP address things go a bit |
108 |
>> weird, so you have to use br0 instead |
109 |
>> so don't do that. |
110 |
> Yes, it's very confusing. |
111 |
> |
112 |
>> perhaps you don't need a full bridge and you might just prefer to lookup |
113 |
>> macvlan instead. |
114 |
>> this lets you create a new virtual device that behaves much more like a |
115 |
>> secondary nic |
116 |
>> e.g. in /etc/conf.d/net |
117 |
>> |
118 |
>> macvlan_xenguest1="eth0" |
119 |
>> mode_xenguest1="private" |
120 |
>> mac_xenguest1="de:ad:be:ef:00:01" |
121 |
>> config_xenguest1="192.168.1.12/24" |
122 |
>> routes_xenguest1="default via 192.168.1.1" |
123 |
>> modules_xenguest1="!ifplugd" |
124 |
>> |
125 |
>> you can then |
126 |
>> /etc/init.d/net.xenguest1 start |
127 |
>> |
128 |
>> i'm not big into xen but i believe you should be able to pass this as a |
129 |
>> "physical" device to xen and it then comes out on network interface eth0 |
130 |
>> this way you get to keep your port without it being eaten by the bridge |
131 |
>> do let me know if this works with xen i'll add it to my toolbox |
132 |
> Hmm, and where's the other end of it? Some physical port? |
133 |
wherever you would like it to be. in the example above |
134 |
|
135 |
macvlan_xenguest1="eth0" |
136 |
|
137 |
it is eth0 |
138 |
|
139 |
> So it's like |
140 |
> plugging in several virtual cables into the same physical port, with a |
141 |
> built-in firewall and router? |
142 |
> |
143 |
> |
144 |
pretty much. |
145 |
i'd recommend you go find out more about bridging at [1] [2] [3] |
146 |
|
147 |
|
148 |
it's a bit difficult to describe a generic case that fits your case |
149 |
without knowing your case. |
150 |
a bridge is basically like a dumb network switch |
151 |
with openrc [3] you can easily |
152 |
create a bridge with /etc/conf.d/net as follows |
153 |
|
154 |
# bridge ports defined empty to avoid DHCP being run for their configuration |
155 |
config_eth0="null" |
156 |
config_eth1="null" |
157 |
|
158 |
# bridge |
159 |
config_br0="192.168.69.69/24" |
160 |
brctl_br0="setfd 0 |
161 |
sethello 10 |
162 |
stp off" |
163 |
bridge_br0="eth0 eth1" |
164 |
|
165 |
|
166 |
you can then setup /etc/init.d/net.br0 and start it |
167 |
from this point on everything that comes in to either eth0 or eth1 for |
168 |
IP address 192.168.69.69 gets accepted by the gentoo kernel. |
169 |
if there is a frame coming in on eth0 that is not for the gentoo kernel, |
170 |
but is for a mac address on eth1 then it gets forwarded on. |
171 |
if there is a frame comig in on eth0 that is not for the gentoo kernel |
172 |
but is for a mac address on eth0 then it is ignored. |
173 |
|
174 |
when you start to talk about virtual machines, then the same principles |
175 |
apply |
176 |
if you only have one virtual machine and one internet connection then |
177 |
yes perhaps it is not necessary to have a bridge, but if you have one |
178 |
network card and many virtual machines then it is necessary |
179 |
|
180 |
|
181 |
[1] http://www.tldp.org/HOWTO/Ethernet-Bridge-netfilter-HOWTO-3.html#ss3.1 |
182 |
[2] http://ebtables.netfilter.org/documentation/bridge-nf.html |
183 |
[3] http://wiki.gentoo.org/wiki/Network_bridge |