You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Missing Storage Adaptor (FiberChannel) from vcenter sync #343
That's possible. The issue here is I don't have an environment with this configuration to implement a solution.
would you be able to provide me a dump from the API with -l DEBUG3 which includes the host with the unsynced interfaces?
Hi,
Did you receive the log file from clemenTal? I am also interested in your program detecting FC HBA cards with their WWN addresses installed in hosts and adding them to NetBox. I can send you a dump from the API with -l DEBUG3 from my environment.
The log file after compression is more than 40MB so I sent you an invitation to a directory on my Google Drive. I also put there CSV files with lists of HBA adapters from several of my hosts visible in VCenter. There is also a text file with the names and uuid of these hosts. I anonymized the log file by removing the domains and parts of the IP addresses from the file.
I hope this data will help you add new feature to your program.
Thank you for the log output, this is very helpful. I looked through the output and found that the FibreChannel Adapters are listed as StorageAdapters, not Network Interfaces. That's one reason why they don't show up.
It seems to me that the interface name, interface type and WWN assigned to the device are sufficient for HBA adapters.
I was wondering how you can guess the type of interface and I think there aren't too many options. The first one that comes to my mind is parsing the model field and looking there for the speed at which the interface can work. In the data dump you sent from my infrastructure: 2600 Series 16Gb Fibre Channel to PCI Express HBA = 16gfc-sfpp If we don't find the speed there then we should use the speed field. However, from the VCenter API description, it appears that this field contains the current operational speed of the interface. It's not the best choice but there probably isn't another one to add this type of interface to Netbox. Perhaps it would be a good idea that when a new interface is added to NetBox, the script does not change its type if it is changed in the NetBox GUI to the correct one.
For WWN, in my opinion we should assign a portWorldWideName to the interface in NetBox. We also need to keep in mind that the VCenter API returns the WWN as a decimal notation and it needs to be converted to hexadecimal notation which is acceptable to NetBox.
Implemented in development (#591), in the image ghcr.io/bb-ricardo/netbox-sync:development. sync_host_fc_adapters = True creates an interface per Fibre Channel HBA of each host: the device name (vmhba3), an FC type derived from the adapter model (32gfc-sfp28 for the QLE2700/QLE2800 adapters in my capture; the port speed is only used when the model names none), the port WWN, model and driver as description, enabled from the link state. Block and PCIe HBAs are left out. I only have a vcsim capture of QLogic adapters to test with, so Emulex or Broadcom model strings are the thing I would most like to hear about.
Could you try it against your vCenter? Run with -n first, then a real run and a second one (the second should change nothing in NetBox), and say what came out, here or in the call for testing: #592. Nothing changes unless the option is set, so pulling the image is safe. It goes into 1.10.0, the next feature release.
Tested sync_host_fc_adapters from development (24b796d, same code as the development image) against our test NetBox. So far only a dry run (-n); the real run and the second run will follow.
Setup
vCenter 8.0.3, NetBox 4.7.2
51 ESXi hosts, about 1,970 VMs; 6 of the hosts have FC HBAs
FC HBAs: 2 × HPE SN1100Q (QLogic QLE2690, single port 16Gb, driver qlnativefc) per host
Options: only sync_host_fc_adapters = True added to our 1.9.1 settings. A check_redfish source reads the iLO inventory of the same hosts.
Result of the dry run
Type, WWN and description come out as expected: model QLE2690 Single Port 16Gb Fibre Channel to PCIe Adapter gives 16gfc-sfpp, even though the ports currently run at 8G, and the WWN is converted to 51:40:2E:C0:12:C8:98:A2.
What surprised me: each host gets 4 FC interfaces for its 2 physical ports. With FC-NVMe enabled, ESXi lists an extra adapter per QLogic port, and both adapters are vim.host.FibreChannelHba:
device
storageProtocol
pci
portWorldWideName
vmhba1
scsi
0000:12:00.0
51402ec012c898a2
vmhba2
scsi
0000:37:00.0
51402ec012c89898
vmhba64
nvme
0000:12:00.0
51402ec012c898a2
vmhba65
nvme
0000:37:00.0
51402ec012c89898
So vmhba64 and vmhba65 become interfaces with the same WWN, model and type as vmhba1 and vmhba2, on every host with FC-NVMe enabled. The iLO inventory confirms 2 single-port FC HBAs per host. A suggestion: create one interface per port WWN, and if several adapters report the same WWN, use the scsi one. storageProtocol and pci are there to tell them apart.
Follow-up: real run and second run against the same test NetBox (NetBox 4.7.2, vCenter 8.0.3).
First run: 24 FC interfaces created on the 6 hosts, no FC-related warnings or errors. Read back from NetBox: type 16gfc-sfpp, WWN 51:40:2E:C0:12:C8:98:A2 etc., enabled = True (ports online), description QLE2690 Single Port 16Gb Fibre Channel to PCIe Adapter (qlnativefc). This includes the FC-NVMe duplicates vmhba64/vmhba65 from my previous comment, with the same WWN as vmhba1/vmhba2.
Second run: no changes to any FC interface.
The run also logs changes and errors on every run that aren't FC-related and aren't new in development. #593, #594 and #595 cover some of them, and I'll report the rest separately.
Thanks a lot for testing this on real hardware, and for the table. You're right, and it's in our own capture too: the vc001 hosts have FC-NVMe enabled and the test even asserted 8 interfaces on a 4-port host. I missed it.
Fixed in #596: one interface per port (same WWN and PCI address), the SCSI adapter wins, an NVMe adapter without a SCSI twin is still synced. The vmhba64/vmhba65 interfaces your run already created won't be touched by name; they get the orphaned tag, and with prune_enabled they're removed after prune_delay_in_days, otherwise please delete them by hand.
If you can, run the branch once more against your test NetBox, it should end up with 2 FC interfaces per host and no changes on the second run.
Activity
bb-Ricardo commentedon Sep 7, 2023
Hi,
That's possible. The issue here is I don't have an environment with this configuration to implement a solution.
would you be able to provide me a dump from the API with
-l DEBUG3which includes the host with the unsynced interfaces?sulik76 commentedon Sep 25, 2023
Hi,
Did you receive the log file from clemenTal? I am also interested in your program detecting FC HBA cards with their WWN addresses installed in hosts and adding them to NetBox. I can send you a dump from the API with
-l DEBUG3from my environment.bb-Ricardo commentedon Sep 25, 2023
Hi,
I did not receive any logs. Would be happy if you could send them if you have some. Then I could look into implementing it.
Thank you.
sulik76 commentedon Sep 25, 2023
The log file after compression is more than 40MB so I sent you an invitation to a directory on my Google Drive. I also put there CSV files with lists of HBA adapters from several of my hosts visible in VCenter. There is also a text file with the names and uuid of these hosts. I anonymized the log file by removing the domains and parts of the IP addresses from the file.
I hope this data will help you add new feature to your program.
bb-Ricardo commentedon Sep 29, 2023
Hi,
Thank you for the log output, this is very helpful. I looked through the output and found that the FibreChannel Adapters are listed as StorageAdapters, not Network Interfaces. That's one reason why they don't show up.
also the amount of data is very limited:
we would need a regex to guesstimate the interface type which is a mandatory field in NetBox.
Would add an interface with following infos to NetBox:
What do you think? How would you determine the interface type?
sulik76 commentedon Oct 3, 2023
Hi,
It seems to me that the interface name, interface type and WWN assigned to the device are sufficient for HBA adapters.
I was wondering how you can guess the type of interface and I think there aren't too many options. The first one that comes to my mind is parsing the model field and looking there for the speed at which the interface can work. In the data dump you sent from my infrastructure: 2600 Series 16Gb Fibre Channel to PCI Express HBA = 16gfc-sfpp If we don't find the speed there then we should use the speed field. However, from the VCenter API description, it appears that this field contains the current operational speed of the interface. It's not the best choice but there probably isn't another one to add this type of interface to Netbox. Perhaps it would be a good idea that when a new interface is added to NetBox, the script does not change its type if it is changed in the NetBox GUI to the correct one.
For WWN, in my opinion we should assign a portWorldWideName to the interface in NetBox. We also need to keep in mind that the VCenter API returns the WWN as a decimal notation and it needs to be converted to hexadecimal notation which is acceptable to NetBox.
bb-Ricardo commentedon Oct 5, 2023
Hi,
Good point about the speed. I could try to use some regex to grab the speed and set it on new interfaces.
Thanks for the hint on the format conversation for the WWN.
Will look into adding this.
semx commentedon Oct 10, 2026
Implemented in
development(#591), in the imageghcr.io/bb-ricardo/netbox-sync:development.sync_host_fc_adapters = Truecreates an interface per Fibre Channel HBA of each host: the device name (vmhba3), an FC type derived from the adapter model (32gfc-sfp28for the QLE2700/QLE2800 adapters in my capture; the port speed is only used when the model names none), the port WWN, model and driver as description, enabled from the link state. Block and PCIe HBAs are left out. I only have a vcsim capture of QLogic adapters to test with, so Emulex or Broadcom model strings are the thing I would most like to hear about.Could you try it against your vCenter? Run with
-nfirst, then a real run and a second one (the second should change nothing in NetBox), and say what came out, here or in the call for testing: #592. Nothing changes unless the option is set, so pulling the image is safe. It goes into 1.10.0, the next feature release.tfoks commentedon Oct 12, 2026
Tested
sync_host_fc_adaptersfromdevelopment(24b796d, same code as the development image) against our test NetBox. So far only a dry run (-n); the real run and the second run will follow.Setup
qlnativefc) per hostsync_host_fc_adapters = Trueadded to our 1.9.1 settings. A check_redfish source reads the iLO inventory of the same hosts.Result of the dry run
Type, WWN and description come out as expected: model
QLE2690 Single Port 16Gb Fibre Channel to PCIe Adaptergives16gfc-sfpp, even though the ports currently run at 8G, and the WWN is converted to51:40:2E:C0:12:C8:98:A2.What surprised me: each host gets 4 FC interfaces for its 2 physical ports. With FC-NVMe enabled, ESXi lists an extra adapter per QLogic port, and both adapters are
vim.host.FibreChannelHba:So
vmhba64andvmhba65become interfaces with the same WWN, model and type asvmhba1andvmhba2, on every host with FC-NVMe enabled. The iLO inventory confirms 2 single-port FC HBAs per host. A suggestion: create one interface per port WWN, and if several adapters report the same WWN, use thescsione.storageProtocolandpciare there to tell them apart.WARNING/ERROR lines
None from the FC code. The run logged:
Invalid data type for 'scope_id', fromcluster_scope_id_relationand not related to FC; fix(VMware): resolve cluster_scope_id_relation to the scoped object #593 fixes it.PTR record contains invalid characters, from DNS names of switch interfaces and not related to this feature.I didn't try the VM tenant, resource pool filter or
vm_name_regexoptions.tfoks commentedon Oct 12, 2026
Follow-up: real run and second run against the same test NetBox (NetBox 4.7.2, vCenter 8.0.3).
16gfc-sfpp, WWN51:40:2E:C0:12:C8:98:A2etc.,enabled = True(ports online), descriptionQLE2690 Single Port 16Gb Fibre Channel to PCIe Adapter (qlnativefc). This includes the FC-NVMe duplicatesvmhba64/vmhba65from my previous comment, with the same WWN asvmhba1/vmhba2.The run also logs changes and errors on every run that aren't FC-related and aren't new in development. #593, #594 and #595 cover some of them, and I'll report the rest separately.
semx commentedon Oct 12, 2026
Thanks a lot for testing this on real hardware, and for the table. You're right, and it's in our own capture too: the vc001 hosts have FC-NVMe enabled and the test even asserted 8 interfaces on a 4-port host. I missed it.
Fixed in #596: one interface per port (same WWN and PCI address), the SCSI adapter wins, an NVMe adapter without a SCSI twin is still synced. The vmhba64/vmhba65 interfaces your run already created won't be touched by name; they get the orphaned tag, and with
prune_enabledthey're removed afterprune_delay_in_days, otherwise please delete them by hand.If you can, run the branch once more against your test NetBox, it should end up with 2 FC interfaces per host and no changes on the second run.