Fantastic.
As for a more appropriate hack, edit
/etc/sysconfig/network-scripts/interface-rename-data/60-net.rules.template
and make it look something like this:
----SNIP-HERE----
# Custom hack
ACTION!="add" GOTO="network-done"
SUBSYSTEM=="net" KERNEL=="eth*" SYSFS{address}=="3c:07:54:6a:3f:ed"
ID=="0000:02:00.0" NAME="eth0"
SUBSYSTEM=="net" KERNEL=="eth*" SYSFS{address}=="80:49:71:11:84:fc"
NAME="eth1"
GOTO="network-done"
# Rules generated from static configuration and last boot data
@@@PATCHME@@@
LABEL="network-done"
----SNIP-HERE----
Manually run interface-rename -r (dont worry about it complaining about
eth1)
Edit /etc/rc.sysinit and comment out the penultimate if clause which
runs interface-rename.py
This will cause the boot logic to bypass any renaming, and set eth0/eth1
correctly for your machine. You will need to substitue appropriate mac
addresses and PCI IDs to apply this workaround to different hardware.
~Andrew
On 05/07/13 12:23, Andrew Eross wrote:
> Easily done - all attached.
>
> thanks!
>
> On Fri, Jul 5, 2013 at 6:59 AM, Andrew Cooper
> <andrew.coop...@citrix.com <mailto:andrew.coop...@citrix.com>> wrote:
>
> All of that information from your current mac mini should be fine,
> even with your hack in place.
>
> specifically, given the last two attachments, I can give you a
> less fragile hack.
>
> ~Andrew
>
>
> On 05/07/13 11:56, Andrew Eross wrote:
>> Hi Andrew,
>>
>> Sure will -
>>
>> I've hacked/fixed up that one system already so it won't be as
>> helpful for logs/config - but on Monday I'm going to install a
>> clean XS 6.2 on our other identical Mac Mini + USB NIC and I'll
>> be glad to collect the requested data to send along.
>>
>> USB definitely wouldn't be the norm =) but we have this mirrored
>> pair of mac minis acting as our local office servers with the
>> built-in gigabit used for a dedicated DRBD cross-over, so hence
>> the USB network for the management interface - good fun.
>>
>> Cheers,
>> Andrew
>>
>>
>> On Fri, Jul 5, 2013 at 6:48 AM, Andrew Cooper
>> <andrew.coop...@citrix.com <mailto:andrew.coop...@citrix.com>> wrote:
>>
>> Hello,
>>
>> You are correct - I never considered USB ethernet devices
>> when writing interface-rename. I shall raise a ticket to
>> deal with this. This logic was substantially "improved" from
>> 6.0.2 -> 6.1, including much more careful control of what was
>> considered valid.
>>
>> In an effort to help (as we don't appear to have any in our
>> testing environment), could you collect the outputs of
>> "biosdevname -d", "lspci -tv", "lsusb", "lsusb -tv" and also
>> attach /var/log/interface-rename.log ?
>>
>> As for a temporary hack for this system, can you attach your
>> current /etc/udev/rules.d/60-net.rules and the output of
>> "udevinfo -a -p /sys/class/net/<bad eth>" ?
>>
>> ~Andrew
>>
>>
>> On 05/07/13 11:03, Rob Hoes wrote:
>>> Hi Andrew,
>>>
>>> The interface-rename script is intended to deal with
>>> situation where network cards are being replaced, removed or
>>> added, and tries to make sure that you still have the eth*
>>> names you would expect. For example, if you have a host with
>>> 2 NICs and replace eth1 with a new NIC in the same slot, the
>>> new NIC will again be called eth1 (and not eth2).
>>>
>>> However, this wasn't designed with USB interfaces in mind,
>>> because USB is not very common on the servers for which
>>> XenServer is normally used. So it is probably not going to
>>> work very well, as you have noticed.
>>>
>>> CC'ing Andrew Cooper, who worked on this. Andrew: do you
>>> think this is easy to address? A quick solution may be to
>>> give USB NICs a prefix other than "eth" to separate them
>>> from the regular PCI NICs, and to leave them alone after that?
>>>
>>> Cheers,
>>> Rob
>>>
>>> On 5 Jul 2013, at 00:52, Andrew Eross <er...@locatrix.com
>>> <mailto:er...@locatrix.com>> wrote:
>>>
>>>> Update to that -
>>>>
>>>> I've found there is kind of a work-around, although this
>>>> isn't a great idea.
>>>>
>>>> Since I know my simple system only has eth0/eth1 and one of
>>>> them is USB and is detected later in the boot process,
>>>> there's probably little chance of any race conditions with
>>>> the adapters, so basically if you
>>>> disable net-rename-sideways.sh, it can work for the moment.
>>>>
>>>> I temporarily
>>>> disabled /etc/udev/scripts/net-rename-sideways.sh by just a
>>>> hack:
>>>> if [[ "$1" =~ "^TEMPDISABLEDeth[0-9]+$" ]]
>>>>
>>>> And now it all works again after doing the usual to
>>>> introduce a physical interface,
>>>> etc: http://support.citrix.com/article/CTX121615
>>>>
>>>> Of course, I hope there's a real/better solution for the
>>>> future and I wouldn't be doing the above on important
>>>> production systems (well, I probably also wouldn't be using
>>>> a USB network adapter on a really important system, but I
>>>> digress).
>>>>
>>>> Cheers,
>>>> Andrew
>>>>
>>>> On Fri, Jul 5, 2013 at 9:33 AM, Andrew Eross
>>>> <er...@locatrix.com <mailto:er...@locatrix.com>> wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> I had a Mac Mini running XS 6.0.2 that used a USB
>>>> network adapter for it's management interface.
>>>>
>>>> Never any issues.
>>>>
>>>> I've installed a clean XS 6.2 over it this morning,
>>>> with no changes made to the hardware setup, just
>>>> installed the new software.
>>>>
>>>> Now the USB network adapter is no longer working
>>>> properly, and is named "side-48348-eth1" instead of "eth1".
>>>>
>>>> I've dug further into this and I think it's something
>>>> to do with
>>>> interface-rename.py/udev/net-rename-sideways.sh
>>>> <http://interface-rename.py/udev/net-rename-sideways.sh>
>>>>
>>>> net-rename-sideway.sh is correctly renaming the adapter
>>>> to 'side-<random number-eth1' at start-up, which is normal
>>>>
>>>> The problem seems to be that it doesn't get renamed
>>>> back to eth1 later on like it's supposed to be.
>>>>
>>>> I see "Later, an RC3 script will take these renamed
>>>> devices and rename them correctly." inside
>>>> net-rename-sideways.sh, but this doesn't seem to be
>>>> happening.
>>>>
>>>> I might've found a hint when I tried running
>>>> interface-rename.py manually just to see what happens:
>>>>
>>>> ./interface-rename.py --rename
>>>> ERROR [2013-07-05 09:30:46] Can't generate current
>>>> state for interface '{'Driver': 'asix', 'Bus Info':
>>>> 'usb-0000:00:1d.7-1.3', 'BIOS device': {'all_ethN':
>>>> 'eth1', 'physical': ''}, 'Assigned MAC':
>>>> '80:49:71:11:84:FC', 'Firmware version': 'ASIX AX88772
>>>> USB 2.0 Ethernet', 'Driver version': '14-Jun-2006',
>>>> 'Kernel name': 'eth1'}' - Unrecognised PCI address
>>>> 'usb-0000:00:1d.7-1.3'
>>>>
>>>> Maybe some sub-system doesn't like the PCI address
>>>> being a usb device? There must've been a change
>>>> somewhere between XS 6.0.2 to 6.2 related to this?
>>>>
>>>> Any ideas on a work-around / hopefully we can fix this
>>>> in a future release?
>>>>
>>>> Thanks!
>>>> Andrew
>>>>
>>>>
>>>> _______________________________________________
>>>> Xen-api mailing list
>>>> Xen-api@lists.xen.org <mailto:Xen-api@lists.xen.org>
>>>> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>>>
>>
>>
>
>
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
