Man that is exactly what I was thinking about 4-5 hours ago driving to work. I was thinking maybe it has something to do with Xserver only recognizing calling NIC names "ethx" The only reason I had not tried it was because I wanted to ensure functionality before renaming to something persistent. Will keep you posted. Because it does pull the same stats matching from my function NIC. Will attempt after lunch!
G
Offline
Best posts made by geant90
-
RE: RTL8153 Compile
Latest posts made by geant90
-
RE: RTL8153 Compile
Of course. Right now I just got enough information to start the modification on the script which I start tomorrow. In fact, all that is needed to get usbnics working properly in xapi is simply being able to identify usb locations. THAT'S IT! All NICs if you look in the logs are initially named side then because the rename script runs and after properly identifying it assigns a ethxx name which the api will work with. All this would take is an import command and a few if commands. I got the logic down so now it is just about editing, trial and error.
Question regarding:
import sys, logging from optparse import OptionParser, OptionGroup from os.path import join as joinpath, normpath, exists as pathexists from subprocess import Popen try: import cStringIO as StringIO except ImportError: import StringIO import xcp.logger as LOG from xcp.pci import PCI from xcp.net.biosdevname import all_devices_all_names from xcp.net.ip import ip_link_set_name from xcp.net.ifrename.logic import rename from xcp.net.ifrename.macpci import MACPCI from xcp.net.ifrename.static import StaticRules from xcp.net.ifrename.dynamic import DynamicRules from xcp.net.ifrename.util import niceformat from xcp.net.mac import MACfor the import command as my google fu was no help for the above xcp.net and xcp.pci what is it specifically referring to?
What I have that down we simply need to add and import for usb then modify a few existing calls with the first being if device location = usb format then run the modify version of the script that would have the edited fields to pull the proper usb locations etc. For the vendor and device it would be best and most simple if we refer to the usbvidpid list it can simply call the info from an already large existing database which can also be easily updated and/or modified for an entry. Functionality wise all that is needed is those if commands to make a usb location referable. Then any usb NIC (so long as drivers provided) would be truly plug and play and we could use the existing config to chose a specific ethxx name based on MAC so they survive reboots without further editing anything.Got it is referring to the python libary / libs
-
RE: RTL8153 Compile
Got it showing in lsusb properly now time to figure xapi
[root@CNP-MOBILE ~]# xe pif-param-list uuid=9212a2c9-b68c-9ac6-cb76-d9baa6af2c5e uuid ( RO) : 9212a2c9-b68c-9ac6-cb76-d9baa6af2c5e device ( RO): eth10 MAC ( RO): 50:3e:aa:85:b6:ae physical ( RO): true managed ( RO): true currently-attached ( RO): false MTU ( RO): 1500 VLAN ( RO): -1 bond-master-of ( RO): bond-slave-of ( RO): <not in database> sriov-physical-PIF-of ( RO): sriov-logical-PIF-of ( RO): tunnel-access-PIF-of ( RO): tunnel-transport-PIF-of ( RO): management ( RO): false network-uuid ( RO): 4a3277cb-f48b-47cc-ba69-7d73f02d814f network-name-label ( RO): Pool-wide network associated with eth10 host-uuid ( RO): af183f35-2629-4472-9538-90c2b37dca85 host-name-label ( RO): CNP-MOBILE IP-configuration-mode ( RO): None IP ( RO): netmask ( RO): gateway ( RO): IPv6-configuration-mode ( RO): None IPv6 ( RO): IPv6-gateway ( RO): primary-address-type ( RO): IPv4 DNS ( RO): properties (MRO): gro: on capabilities (SRO): io_read_kbs ( RO): 0.000 io_write_kbs ( RO): 0.000 carrier ( RO): false vendor-id ( RO): vendor-name ( RO): device-id ( RO): device-name ( RO): speed ( RO): 0 Mbit/s duplex ( RO): unknown disallow-unplug ( RW): false pci-bus-path ( RO): 2-1:1.0 other-config (MRW): igmp-snooping-status ( RO): unknown [root@CNP-MOBILE ~]# lsusb Bus 002 Device 002: ID 2357:0601 TP-LINK USB 10/100/1000 LAN Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub [root@CNP-MOBILE ~]# -
RE: RTL8153 Compile
Any one knows the file location for usb vendor and product ID?
Nevermind found it!
-
RE: RTL8153 Compile
Anyone knows where is the database for USB vendors and product ids? Would like to put an edit in there to see if that would generate proper info.
-
RE: RTL8153 Compile
Did not get to the script yet but I will. I just wanted to be 100 percent sure that the only reason its named side is because that script cannot handle it due to the unknown bus location. If we can get the script to recognize the location then that would likely be the end for all usb nic troubles as it will then be able to properly assign the ethx name for xapi to correctly pick up without any addition user interaction.Thus again putting XCP-NG ahead of the game. As we would not have to put a halt to dynamic naming for interfaces and the nic will be retained through a reboot.
-
RE: RTL8153 Compile
Check it out
Going to see if I can get it to call the vendor and device from the usb manu and product ids so it is all pretty and what not.
-
RE: RTL8153 Compile
In interface-rename python I see it imports xcp.pci and others. Maybe if it is edited to import usb as well then using an if command we can get it to also recognize a pci address for examaple 'usb-0000:00:14.0-2 (if usb-xxxx:xx:xx:x-x then refer to usb location. Will play around now. For now I wonder if a simple edit to the script would get it working. usb-0000:00:14.0-2 does in fact refer to to the proper pci address of the usb controller @ 00:14.0 I wonder if for reporting purposes using a if command to strip away usb-0000:00:14.0-2 to 0000:00:14.0-2 or possibly 0000:00:14.0 would be enough for it to comply with xapi then with a proper eth name it will report correctly refresh xcenter appropriately. Since it can be matched with permanent MAC it in theory would be able to function as that just displays NIC. Then if that is successful I can see if it would cause conflict with two reporting same PCI location. Which from looking at the script it should not as that is just reporting to the end user usable info which we really don't care as we are aware it is a usb device then could simply find out which to be specific. This does not effect the driver which is already communicating properly and the device is functioning fine it just cannot determine that bus location.
-
RE: RTL8153 Compile
Ladies and gentlemen we have struck gold.
[root@XenServer-TestNIC ~]# interface-rename --list ERROR [2018-11-05 12:36:24] Can't generate current state for interface '{'Driver': 'r8152', 'Permanent MAC': '50:3E:AA:85:B6:AE', 'Bus Info': 'usb-0000:00:14.0-2', 'BIOS device': {'all_ethN': 'eth1', 'physical': ''}, 'Assigned MAC': '50:3E:AA:85:B6:AE', 'Firmware version': '', 'Driver version': 'v2.10.00 (2018/03/16)', 'Kernel name': 'side-9065-eth1'}' - Unrecognised PCI address 'usb-0000:00:14.0-2' Name MAC PCI ethN Phys SMBios Driver Version Firmware eth0 a0:d3:c1:06:ed:a1 0000:00:19.0[0] eth0 em1 Onboard LAN e1000e 3.4.0.2-NAPI 0.13-4 [root@XenServer-TestNIC ~]#So it looks like it has a problem being a usb device. Time to find out what can be done to over come this.
Unrecognised PCI address 'usb-0000:00:14.0-2'
-
RE: RTL8153 Compile
Man that is exactly what I was thinking about 4-5 hours ago driving to work. I was thinking maybe it has something to do with Xserver only recognizing calling NIC names "ethx" The only reason I had not tried it was because I wanted to ensure functionality before renaming to something persistent. Will keep you posted. Because it does pull the same stats matching from my function NIC. Will attempt after lunch!
-
RE: RTL8153 Compile
[root@CNP-MOBILE ~]# ethtool -i side-373-eth0 driver: r8152 version: v2.10.00 (2018/03/16) firmware-version: bus-info: usb-0000:00:14.0-1 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: no supports-priv-flags: no [root@CNP-MOBILE ~]# ethtool side-373-eth0 Settings for side-373-eth0: Supported ports: [ MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 32 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x00007fff (32767) drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol Link detected: yes [root@CNP-MOBILE ~]#Hmm just noticed for my other interface that works fine where it says Ports for the result of #ethtool under the USB#Gig NIC it says MII and the other working NIC says Twisted pair!?!? I know what a MII but could it be that? Anyone has working media interface to rule that out?