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
