|
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
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]+$" ]]
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
<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".
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@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
|
