[Users] vlan interface failed : Bridged network Internet is attached to multiple interfaces: <UNKNOWN> on Host node1.
Hi there Few weeks ago I report on the 3.2beta a problem to set a new Vlan tagged interface. I've sent logs to Antoni. Now on the stable release, fresh install, I try to add a vlan tagged interface, and I have exactly the same error. I don't understand how such a problem in a stable release is possible ? Does anyone success to had a vlan ? I can't use ovirtmgmt network to go to Internet, so that i can't use 3.2 release. I can send log again if needed, just ask :) Kevin -- Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr
Hi Kevin, I have a very recently installed 3.2 and I have several vlanned networks configured on a 3.2 host. Probably there is some difference between our configurations. I think it maybe could be useful to try to solve it over IRC at #ovirt at OFTC. Best, Toni ----- Original Message -----
From: "Kevin Maziere Aubry" <kevin.maziere@alterway.fr> To: "users" <users@ovirt.org> Sent: Tuesday, February 19, 2013 11:26:24 AM Subject: [Users] vlan interface failed : Bridged network Internet is attached to multiple interfaces: <UNKNOWN> on Host node1.
Hi there
Few weeks ago I report on the 3.2beta a problem to set a new Vlan tagged interface. I've sent logs to Antoni. Now on the stable release, fresh install, I try to add a vlan tagged interface, and I have exactly the same error. I don't understand how such a problem in a stable release is possible ? Does anyone success to had a vlan ? I can't use ovirtmgmt network to go to Internet, so that i can't use 3.2 release.
I can send log again if needed, just ask :)
Kevin
--
Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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 Thx to Antoni for is help Hi there Few weeks ago I report on the 3.2beta a problem to set a new Vlan tagged interface. I've sent logs to Antoni. Now on the stable release, fresh install, I try to add a vlan tagged interface, and I have exactly the same error. I don't understand how such a problem in a stable release is possible ? Does anyone success to had a vlan ? I can't use ovirtmgmt network to go to Internet, so that i can't use 3.2 release. I can send log again if needed, just ask :) Kevin -- Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr
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@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
Thx to Antoni for is help Hi there
Few weeks ago I report on the 3.2beta a problem to set a new Vlan tagged interface. I've sent logs to Antoni. Now on the stable release, fresh install, I try to add a vlan tagged interface, and I have exactly the same error. I don't understand how such a problem in a stable release is possible ? Does anyone success to had a vlan ? I can't use ovirtmgmt network to go to Internet, so that i can't use 3.2 release.
I can send log again if needed, just ask :)
Kevin
--
Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr
-- Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr
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@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:
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. Dan.
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@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.
Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@cs.kent.edu> To: users@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@cs.kent.edu> To: users@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 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@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
On 2/19/2013 5:34 PM, Dan Kenigsberg wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
They pushed a change to initscripts and systemd that should fix the issue: https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-... ----- Original Message -----
From: "Jeff Bailey" <bailey@cs.kent.edu> To: users@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@cs.kent.edu> To: users@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 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@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
On 2/19/2013 5:34 PM, Dan Kenigsberg wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi (it works) I've installed a fresh f18 netinstall. I've install all these rpm from https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-... : -rw-r--r--. 1 root root 123K 20 févr. 17:08 debugmode-9.42.2-1.fc18.x86_64.rpm -rw-r--r--. 1 root root 919K 20 févr. 17:08 initscripts-9.42.2-1.fc18.x86_64.rpm -rw-r--r--. 1 root root 192K 20 févr. 17:08 initscripts-debuginfo-9.42.2-1.fc18.x86_64.rpm -rw-r--r--. 1 root root 37K 28 janv. 20:06 libgudev1-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 49K 28 janv. 20:06 libgudev1-devel-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 2,2M 28 janv. 20:06 systemd-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 27K 28 janv. 20:05 systemd-analyze-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 7,0M 28 janv. 20:05 systemd-debuginfo-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 131K 28 janv. 20:05 systemd-devel-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 128K 28 janv. 20:06 systemd-libs-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 33K 28 janv. 20:06 systemd-python-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 25K 28 janv. 20:05 systemd-sysv-197-1.fc18.2.x86_64.rpm When installing vdsm from the manager, the node loose the network. In fact NetworkManager to no add the gateway, so I add it to /etc/sysconfig/network, and do a reinstall The node reboot and come back as non operationnal. In fact the ovirtmgmt was not attached to p1p1, so I attached it, and no issue. The node is up Then I attached my Vlan interface, and IT WORKS as requested !! Nice work guys, I have only set a gateway and installed required rpm, leave NetworkManager started, and no issue regarding network for the moment. Kevin 2013/2/21 Antoni Segura Puimedon <asegurap@redhat.com>
They pushed a change to initscripts and systemd that should fix the issue:
https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-...
----- Original Message -----
From: "Jeff Bailey" <bailey@cs.kent.edu> To: users@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@cs.kent.edu> To: users@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 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@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
On 2/19/2013 5:34 PM, Dan Kenigsberg wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr
Great to hear that! ----- Original Message -----
From: "Kevin Maziere Aubry" <kevin.maziere@alterway.fr> To: "Antoni Segura Puimedon" <asegurap@redhat.com> Cc: "users" <users@ovirt.org> Sent: Thursday, February 21, 2013 5:30:08 PM Subject: Re: [Users] vlan interface failed : Bridged network Internet is attached to multiple interfaces: <UNKNOWN> on Host node1.
Hi
(it works)
I've installed a fresh f18 netinstall. I've install all these rpm from https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-... :
-rw-r--r--. 1 root root 123K 20 févr. 17:08 debugmode-9.42.2-1.fc18.x86_64.rpm -rw-r--r--. 1 root root 919K 20 févr. 17:08 initscripts-9.42.2-1.fc18.x86_64.rpm -rw-r--r--. 1 root root 192K 20 févr. 17:08 initscripts-debuginfo-9.42.2-1.fc18.x86_64.rpm -rw-r--r--. 1 root root 37K 28 janv. 20:06 libgudev1-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 49K 28 janv. 20:06 libgudev1-devel-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 2,2M 28 janv. 20:06 systemd-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 27K 28 janv. 20:05 systemd-analyze-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 7,0M 28 janv. 20:05 systemd-debuginfo-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 131K 28 janv. 20:05 systemd-devel-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 128K 28 janv. 20:06 systemd-libs-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 33K 28 janv. 20:06 systemd-python-197-1.fc18.2.x86_64.rpm -rw-r--r--. 1 root root 25K 28 janv. 20:05 systemd-sysv-197-1.fc18.2.x86_64.rpm
When installing vdsm from the manager, the node loose the network. In fact NetworkManager to no add the gateway, so I add it to /etc/sysconfig/network, and do a reinstall
The node reboot and come back as non operationnal. In fact the ovirtmgmt was not attached to p1p1, so I attached it, and no issue. The node is up Then I attached my Vlan interface, and IT WORKS as requested !!
Nice work guys, I have only set a gateway and installed required rpm, leave NetworkManager started, and no issue regarding network for the moment.
Kevin
2013/2/21 Antoni Segura Puimedon < asegurap@redhat.com >
They pushed a change to initscripts and systemd that should fix the issue:
https://admin.fedoraproject.org/updates/FEDORA-2013-1590/initscripts-9.42.2-...
----- Original Message -----
From: "Jeff Bailey" < bailey@cs.kent.edu > To: users@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@cs.kent.edu > To: users@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 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@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
On 2/19/2013 5:34 PM, Dan Kenigsberg wrote: 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--
Kevin Mazière Responsable Infrastructure Alter Way – Hosting 1 rue Royal - 227 Bureaux de la Colline 92213 Saint-Cloud Cedex Tél : +33 (0)1 41 16 38 41 Mob : +33 (0)7 62 55 57 05 http://www.alterway.fr
participants (4)
-
Antoni Segura Puimedon -
Dan Kenigsberg -
Jeff Bailey -
Kevin Maziere Aubry