This issue got on my table quite a number of times in the last 4 weeks. Customer is trying to use the vHBA feature of Oracle VM for SAPRC 3.3 and newer. While configuring and testing to do so, the customer is seeing a error message like
Oct 10 00:00:00 guest1 scsi: [ID 123455 kern.warning] WARNING: scsi_enumeration_failed: vhba3 probe@w50000xxxxxxxxxxxxx,0 enumeration failed during tran_tgt_init
Oct 10 00:00:00 guest1 vhba: [ID 123456 kern.warning] WARNING: vhba_tran_tgt_init: no softstate for vt(3xxxxxxxxxxxx) lun(0) ua(w50000xxxxxxxxxxxxx,0) tgt-dip(3xxxxxxxxxxxxxx) vin(xxxxxxxxxxx)
When you see something like that, the solution is quite simple. You need a LUN 0 to be visible and functional(it has to react when commands were send) on the target. Or as the documentation states:
When configuring a virtual SAN, note that only SCSI target devices with a LUN 0 have their physical LUNs visible in the guest domain. This constraint is imposed by an Oracle Solaris OS implementation that requires a target's LUN 0 to respond to the SCSI REPORT LUNS command
I would not call it a constraint, it's more like standard compliance as due to the definition of the SCSI-3 standard itís the only LUN that you could always assume to be there as the SCSI-3 standard simply mandates it ... if the device is standard compliant. The SCSI-3 specification (available at t10.org) states in section Ą4.7.2 SCSI target deviceď:
A logical unit is the object to which SCSI commands are addressed. One of the logical units within the SCSI target device shall be accessed using the logical unit number zero. See 4.8 for a description of the logical unit.
And shall is specified as:
A keyword indicating a mandatory requirement. Designers are required to implement all such mandatory requirements to ensure interoperability with other products that conform to this standard.
So as soon as you make a LUN 0 available on the targets you are seeing with the vHBA, you will see the LUNs.