[pve-devel] new bridge code doesn't work with redhat kernel

[Stefan Priebe]

HI,

right now i'm talking about bridge on top of a bond  NO VLAN involved. 
My commit / code change does not even touch that...

Could you please check? As far as i know this is working for you - isn't it?

Stefan

Am 11.02.2013 17:40, schrieb Alexandre DERUMIER:
> Mmmm, this is strange, I have just retested after reboot my test server,
>
> it doesn't work anymore too with new bridge code.
>
> (maybe an arp problem ?)
>
> I'm a bit scaried....
>
>
> ----- Mail original -----
>
> De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag>
> À: "Alexandre DERUMIER" <aderumier at odiso.com>
> Cc: pve-devel at pve.proxmox.com, "Dietmar Maurer" <dietmar at proxmox.com>
> Envoyé: Lundi 11 Février 2013 17:28:34
> Objet: Re: [pve-devel] new bridge code doesn't work with redhat kernel
>
> And how does you bridge look like? To me the tap devices attached to the bridge don't work at all.
>
> Stefan
>
> Am 11.02.2013 um 17:16 schrieb Alexandre DERUMIER <aderumier at odiso.com>:
>
>> Hi stefan, this is working for my with theses bond configs
>>
>> active-backup
>> --------------
>> auto bond0
>> iface bond0 inet manual
>> slaves eth0 eth1
>> bond_miimon 100
>> bond_mode active-backup
>> pre-up ifup eth0 eth1
>> post-down ifdown eth0 eth1
>>
>>
>> or lacp
>> -------
>> auto bond1
>> iface bond1 inet manual
>> bond-mode 4
>> bond-miimon 100
>> bond-lacp_rate fast
>> bond-xmit-hash-policy layer2+3
>> slaves eth0 eth1
>>
>>
>> ----- Mail original -----
>>
>> De: "Stefan Priebe - Profihost AG" <s.priebe at profihost.ag>
>> À: "Dietmar Maurer" <dietmar at proxmox.com>
>> Cc: "Alexandre DERUMIER" <aderumier at odiso.com>, pve-devel at pve.proxmox.com
>> Envoyé: Lundi 11 Février 2013 16:40:13
>> Objet: Re: [pve-devel] new bridge code doesn't work with redhat kernel
>>
>> Hello,
>>
>> please wait a bit i'll contact Patrick in a few minutes as i wanted to
>> switch to bonding today and it stops working again.
>>
>> Let's see how a real solution would look like. Right now i've the same
>> problem as alexandre that the VM is not reachable at all when using bond.
>>
>> Alexandre maybe you can tell me how you got your bonding working?
>>
>> My interfaces:
>>
>> auto bond0
>> iface bond0 inet manual
>> slaves eth0 eth1
>> bond_mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 10
>>
>> auto vmbr0
>> iface vmbr0 inet manual
>> bridge_ports bond0
>> bridge_stp off
>> bridge_fd 0
>>
>> But this results in no IP communication for the VM - even without using
>> any vlans.
>>
>> Stefan
>> Am 11.02.2013 09:42, schrieb Dietmar Maurer:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Alexandre DERUMIER [mailto:aderumier at odiso.com]
>>>> Sent: Freitag, 08. Februar 2013 08:12
>>>> To: Stefan Priebe; Dietmar Maurer
>>>> Cc: pve-devel at pve.proxmox.com
>>>> Subject: Re: [pve-devel] new bridge code doesn't work with redhat kernel
>>>>
>>>> Hi Stefan, Thanks it's working ! (I have not aware of vlan-raw-device syntax).
>>>>
>>>> Based of this, I have a better setup, putting ip addresse on vlan interface,
>>>> and not on a bridge.
>>>> So it's a small change.
>>>>
>>>> But I really think this change should not go in stable pve repo before a big
>>>> release like proxmox 2.3.
>>>> As It ll require reboot of the host to have clean bridges without mix of tagged
>>>> interfaces and tagged bridges interfaces.
>>>
>>> 2.3 release is the next release planned end of February. There is a new kernel, and
>>> a new kvm (1.4, including new backup code), so we need to recommend a reboot anyways.
>>>
>>> Here is a list of advantages and disadvantages:
>>>
>>> new code:
>>>
>>> + works with any number of physical interfaces
>>> + works with gvrp
>>> - only tested by a few people
>>> - not fully compatible with existing vlan setup
>>>
>>> old code:
>>>
>>> + works well for many users
>>> + also used by RHEV/libvirt
>>> - needs exactly one physical interface (should also work with 0 physical interfaces)
>>> - gvrp does not work (https://lkml.org/lkml/2013/2/7/107)
>>> + can use vlan hardware support (better performance?)
>>>
>>>
>>> Seems GVRP is a rarely used feature, because it is very dangerous security wise.
>>>
>>> So what is your opinion:
>>>
>>> A.) keep old VLAN code (revert change)
>>> B.) use new VLAN code
>>>
>>> Please can we vote on that? Also include a short explanation why you prefer something.
>>>
>>> - Dietmar
>>>
>>>