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