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-1.fc18,systemd-197-1.fc18.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 <asegu...@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-1.fc18,systemd-197-1.fc18.2
>
> ----- Original Message -----
> > From: "Jeff Bailey" <bai...@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" <bai...@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.mazi...@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
> > >>
> > > _______________________________________________
> > > 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
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to