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"
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