Modified the steps to identify the attached device on the client plugin and hence also passing the bus number vs. the PCI slot number. The PCI slot number handles devices on the secondary PCI bus already but doesn't handle devices on non-zero functions of the PCI bridge device.
The change is to identify the PCI bridge behind which the PVSCSI controller is located (per https://kb.vmware.com/s/article/2047927) and pass that to the client.
The client uses the bridge number and find the devices on the PCI bus (secondary) of that PCI bridge. Given only a single device is present on the PCI bridge (the PVSCSI controller) we use that and generate the final disk path.
The server logs look like this,
11/07/17 07:56:40 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] *** disk_attach: VMDK /vmfs/volumes/sharedVmfs-0/dockvols/_DEFAULT/pci-vol-3.vmdk to VM 'master-VM0.0' , bios uuid = 564dc89b-af45-e984-dd7b-0daaf4b09b44, VC uuid=52a51794-7af6-31de-ecfa-860dcf56e686)
11/07/17 07:56:40 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] Found vm name='master-VM0.0'
11/07/17 07:56:40 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] Attaching /vmfs/volumes/sharedVmfs-0/dockvols/_DEFAULT/pci-vol-3.vmdk as independent_persistent
11/07/17 07:56:41 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] Disk /vmfs/volumes/sharedVmfs-0/dockvols/_DEFAULT/pci-vol-3.vmdk successfully attached. controller pci_slot_number=15.0, disk_slot=0
11/07/17 07:56:41 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] executeRequest 'attach' completed with ret={'Unit': '0', 'ControllerPciSlotNumber': '15.0'} <------- the bridge as the client would see it (this is typically PCI bridge 1 in the VM config at a PCI slot number of 21).
Testing: Verified create, attach, re-attach, inspect workflows with the change.
Modified the steps to identify the attached device on the client plugin and hence also passing the bus number vs. the PCI slot number. The PCI slot number handles devices on the secondary PCI bus already but doesn't handle devices on non-zero functions of the PCI bridge device.
The change is to identify the PCI bridge behind which the PVSCSI controller is located (per https://kb.vmware.com/s/article/2047927) and pass that to the client.
The client uses the bridge number and find the devices on the PCI bus (secondary) of that PCI bridge. Given only a single device is present on the PCI bridge (the PVSCSI controller) we use that and generate the final disk path.
The server logs look like this, 11/07/17 07:56:40 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] *** disk_attach: VMDK /vmfs/volumes/sharedVmfs-0/dockvols/_DEFAULT/pci-vol-3.vmdk to VM 'master-VM0.0' , bios uuid = 564dc89b-af45-e984-dd7b-0daaf4b09b44, VC uuid=52a51794-7af6-31de-ecfa-860dcf56e686) 11/07/17 07:56:40 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] Found vm name='master-VM0.0' 11/07/17 07:56:40 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] Attaching /vmfs/volumes/sharedVmfs-0/dockvols/_DEFAULT/pci-vol-3.vmdk as independent_persistent 11/07/17 07:56:41 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] Disk /vmfs/volumes/sharedVmfs-0/dockvols/_DEFAULT/pci-vol-3.vmdk successfully attached. controller pci_slot_number=15.0, disk_slot=0 11/07/17 07:56:41 14630789 [master-VM0.0-sharedVmfs-0._DEFAULT.pci-vol-3] [INFO ] executeRequest 'attach' completed with ret={'Unit': '0', 'ControllerPciSlotNumber': '15.0'} <------- the bridge as the client would see it (this is typically PCI bridge 1 in the VM config at a PCI slot number of 21).
Testing: Verified create, attach, re-attach, inspect workflows with the change.