[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] XS 6.2 USB Network Adapter Problems


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

# Rules generated from static configuration and last boot data


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.


On 05/07/13 12:23, Andrew Eross wrote:
Easily done - all attached.


On Fri, Jul 5, 2013 at 6:59 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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.


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.


On Fri, Jul 5, 2013 at 6:48 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:

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


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?


On 5 Jul 2013, at 00:52, Andrew Eross <eross@xxxxxxxxxxxx> 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).


On Fri, Jul 5, 2013 at 9:33 AM, Andrew Eross <eross@xxxxxxxxxxxx> 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

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?


Xen-api mailing list

Xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.