[rhelv6-beta-list] EXTERNAL: Interface numbering was Re: rhel6 remote installs not working

Wed Aug 11 22:20:17 UTC 2010

----- Original Message -----
From: rhelv6-beta-list-bounces at redhat.com <rhelv6-beta-list-bounces at redhat.com>
To: rhelv6-beta-list at redhat.com <rhelv6-beta-list at redhat.com>
Sent: Wed Aug 11 17:13:01 2010
Subject: EXTERNAL:[rhelv6-beta-list] Interface numbering was Re: rhel6 remote installs not working

rhelv6-beta-list-bounces at redhat.com wrote on 08/10/2010 09:22:05 PM:

> > So what gives with the weird interface numbering?
>
> Hi Greg,
>
> Thanks for your comments on this. I generally enjoy reading them :)
>
> If you mean to refer to the ordering difference with respect to RHEL5,
> this is a result of two important changes:
>
> 1). Kudzu has officially gone out to pasture.
> 2). Upstream introduced parallel udev but didn't solve the problems
> associated with doing that (boot time improvements are great on the
> desktop, but on the server we care a little more about consequence).
>
> The first issue means that, although enumeration is consistent, the
> devices may be detected in a different order from that of RHEL5. The
> second issue means that devices were coming up in a non-consistent
> order, depending upon which of several simultaneous driver loads
> succeeded first. I was the one who changed this - for RHEL6 - to ensure
> that udev performs driver loads sequentially. It's not /as/ fast, but it
> does mean that you get the benefit of consistency.
>
> Now, as to the longer term. Matt Domsch (Dell, very nice guy), myself,
> and others have had this on our collective radars for a while. Matt has
> actually done some things to advance this cause, including contributing
> to standardized SMBIOS extensions that system vendors can use in order
> to convey to the Operating System what port numbers (on the back of the
> system chassis in many cases) map to which devices. This is all great
> stuff, but the Linux community has not yet advanced on a common
> approach. Matt is at LinuxCon this week giving a talk. You might be able
> to watch it online, or at least get ahold of the presentation.

Very interesting, thanks for the heads up.  Further delving into the issue
in the little time I had to deal with it showed me why I ran into the
problem specifically.  I'm going to try to restate the issue more clearly
and then give my reasoning since I moved the thread since it is diverting a
bit, and I think they are possibly different problems or concerns.

The primary contributing factor to ending up where I was was because it was
such an odd install path:

      1: Install as xenpv via cobbler/koan to a raw disk (not image)
      2: xenpv won't boot post install for some as of yet to be resolved
reason
      3: Attempt install as xenfv via cobbler/koan to same raw disk as in
#1
      4: install fails cause it can't connect to a network (for the record,
it fails because its trying to dhcp for the PXE boot, even though koan
supposedly told it static information, which works for everything else)
      5: (I got to this step on accident initially) boot the install from
step 1 that exists on the raw image as a xenfv
      6: eth0 is automatically renumbered to eth1, so when eth1 is
configured i can get to the network.

So step 6 is because steps 1 and 3 created different MAC addresses in the
xen config file, and the new udev you mentioned hardcodes a rule saying mac
1 is eth0, thus the new mac is eth1.  Once I removed the rule, it recreated
as eth0, and is behaving as expected.

In the real world, this specific scenario is not as likely, but I can think
of two scenarios where it might be:

1: Baremetal system that changes out NICs
2: Clone of an existing virtual to another

These scenarios can easily be handled if you know why its doing this, but
its adding yet another thing to scrub from a system when doing these kinds
of tasks, or similar.

I'm very curious to see what the end results for this udev handling ends up
being.

Here is a bugzilla that mentions the same thing (closed as notabug):

https://bugzilla.redhat.com/show_bug.cgi?id=608485

-greg

_______________________________________________
rhelv6-beta-list mailing list
rhelv6-beta-list at redhat.com
https://www.redhat.com/mailman/listinfo/rhelv6-beta-list