From: "Jeff Bailey" <bailey(a)cs.kent.edu>
To: users(a)ovirt.org
Sent: Wednesday, February 20, 2013 11:26:33 AM
Subject: Re: [Users] vlan interface failed : Bridged network Internet is attached to
multiple interfaces: <UNKNOWN>
on Host node1.
On 2/20/2013 4:56 AM, Antoni Segura Puimedon wrote:
> There's a systemd hackfest this week on occasion of the developers
> conference in Brno. I'll try to see what can be done about this.
>
> @Kevin. Did you try the 60-net.rules that Lukas Nykryn proposed?
> ACTION=="add", SUBSYSTEM=="net", ATTRS{type}=="1",
> PROGRAM="/lib/udev/rename_device", RESULT=="?*",
NAME="$result"
I had tried this and it didn't help. It seems that the vlan
interface
has type 1 (/sys/class/net/em1_1.538/type contains 1) and the rename
still happens.
> Best,
>
> Toni
>
> ----- Original Message -----
>> From: "Jeff Bailey" <bailey(a)cs.kent.edu>
>> To: users(a)ovirt.org
>> Sent: Wednesday, February 20, 2013 3:38:28 AM
>> Subject: Re: [Users] vlan interface failed : Bridged network
>> Internet is attached to multiple interfaces: <UNKNOWN>
>> on Host node1.
>>
>> On 2/19/2013 8:04 PM, Jeff Bailey wrote:
>>> On 2/19/2013 5:34 PM, Dan Kenigsberg wrote:
>>>> On Tue, Feb 19, 2013 at 11:12:42PM +0100, Kevin Maziere Aubry
>>>> wrote:
>>>>> Hi
>>>>>
>>>>> I've just found a workaround ... rm
>>>>> /usr/lib/udev/rules.d/60-net.rules and
>>>>> reboot
>>>>> Then I can add vlan to physical interface.
>>>>>
>>>>>
>>>>>
>>>>> 2013/2/19 Kevin Maziere Aubry <kevin.maziere(a)alterway.fr>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> Today on IRC we worked on this issue and I will try to
>>>>>> summarized the
>>>>>> results of our troubleshooting :
>>>>>>
>>>>>> Current stable systemd rpm has a bug with device mapper which
>>>>>> cause
>>>>>> all
>>>>>> device created on a fibrechannel to have wrong access right.
>>>>>> So the workaround is to replace systemd with the one on the
>>>>>> testing
>>>>>> repo.
>>>>>>
>>>>>> But the testing release as also a bug with udev which rename
>>>>>> network
>>>>>> interface so that each new network interface is named
>>>>>> renameX@interface.
>>>>>>
>>>>>> We test some udev workaround unsucessfully. (
>>>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=907365 )
>>>>>> Now I think a patch on systemd testing rpm should fix the
>>>>>> issue,
>>>>>> waiting
>>>>>> for it
>>>>>>
>>>>>> Reference:
>>>>>>
>>>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=912323
>>>> Last word that I've heard about this bug ^^^ ("Bug 912323 -
>>>> Adding
>>>> a
>>>> VLAN Device does not Work ") is that Muli can no longer
>>>> reproduce
>>>> it on
>>>> his host.
>>>>
>>>> If this does reproduce on your system, would you provide more
>>>> data
>>>> as
>>>> requested on
>>>>
https://bugzilla.redhat.com/show_bug.cgi?id=912323#c2
>>>> ?
>>>> Note that I've just called the systemd cavalry to our
>>>> assistance.
>>> I thought I had a simple (if inconvenient) work around but it
>>> looks
>>> like something (either the deploy or syncing the management
>>> network)
>>> puts the HWADDR line back in ifcfg-em1_1. I'm going to do some
>>> more
>>> testing... Yep, it's the network sync that adds HWADDR back
>>> which
>>> then triggers udev to rename em1_1.538 to em1_1 which doesn't
>>> work
>>> and
>>> I end up with "rename??@em1_1". I can live without the sync I
>>> suppose. I'll try leaving the manual config of the management
>>> network
>>> alone and then config the other networks and see what happens.
>>>
>> Well, that didn't work. I can't seem to find any combination that
>> plays
>> nicely together. Looks like Kevin's solution of ripping out
>> udev's
>> ability to rename interfaces may be the only quick fix. It does
>> get
>> us
>> the ability to change ownership of LVs back which is more
>> important.
>> So
>> far, I've seen no ill effects and everything (networking and
>> storage)
>> seems to be working as it should.
>>
>>>> Dan.
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users(a)ovirt.org
>>>>
http://lists.ovirt.org/mailman/listinfo/users
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>>
http://lists.ovirt.org/mailman/listinfo/users
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/users
>>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users