|
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.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.
~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.cooper3@xxxxxxxxxx>
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
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
|
