Simulating a LUN0

The virtual SCSI HBA subsystem simulates the presence of a LUN0 for a SCSI target whose LUN0 or LUN0s are not visible in the service domain. A device is visible to the Oracle Solaris OS if it appears in prtconf output.

Because the vhba module uses a specific Oracle Solaris I/O framework, a LUN0 must be simulated if it is not visible in the service domain. The framework relies on the sending of a SCSI command (REPORT LUNS) to a SCSI target's LUN0 devices to discover the virtual SAN's LUNs. If a LUN0 is not visible, no LUNs within the virtual SAN can be discovered.

The vsan module creates metadata for a simulated LUN0 if the Oracle Solaris metadata for a physical LUN0 is not found during the physical LUN discovery process. The vsan module performs minimal simulation, which generates responses to the REPORT LUNS, INQUIRY, TEST UNIT READY, and REQUEST SENSE SCSI commands.

The requirement to simulate a LUN0 derives from an industry where it has become common for a storage vendor to implement a product that does not have a visible LUN0.

At runtime, the vsan module cannot determine whether a LUN0 is not present physically or is invisible, so the vsan module must simulate a LUN0 in both these instances. If a LUN0 is present but invisible, any functionality that is exported by the underlying SCSI device is not usable, and the vsan module returns INVALID COMMAND for any SCSI commands not mentioned previously.

The following shows how you can identify a simulated LUN0 before your system runs Oracle Solaris 11.4 SRU 39 and after your system runs Oracle Solaris 11.4 SRU 39:

Oracle Solaris 11.4 SRU 39. The following commands show that the device type of the simulated LUN0 is DISK (inq_dtype(0=disk)) and that sd is bound to the device:
```
# echo "::vhba" | mdb -k
vhba_t( 6400c779d080 ) vhba@0
...
  vhba_lun_t( 6400c5282558 ) lun(0) vlun-id(0) [NEW]
      devinfo(6400cd323ba8) scsi_device(6400cd10c548) scsi_inquiry(40012402060).inq_dtype(0=disk)
      /virtual-devices@100/channel-devices@200/scsi@0/iport@0/disk@w200000110d211500,0
#
# prtconf -D /virtual-devices@100/channel-devices@200/scsi@0/iport@0/disk@w200000110d211500,0
disk, instance #16 (driver name: sd)
```
For more information about sd, see sd(4D) man page.

Because a simulated LUN0 implements only the most basic SCSI commands, any Oracle Solaris software that assumes the simulated LUN0 is a real disk can see the warning messages. For example, because the simulated LUN0 is of type DISK, you might see the drive not available message:
```
# format
AVAILABLE DISK SELECTIONS:
...
  9. c16t200000110D211500d0 (drive not available)
     /virtual-devices@100/channel-devices@200/scsi@0/iport@0/disk@w200000110d211500,0
```
When LUN0 is simulated, the vsan module only issues the most basic SCSI commands. As a result, when applications such as the format command issue SCSI commands to read a disk label, they fail. So, the drive not available message appears, as expected.

Prior to Oracle Solaris 11.4 SRU 39. You can identify a simulated LUN0 by executing the following commands in the domain in which the vhba module executes:

# echo "::vhba" | mdb -k
vhba_t( 400154422c0 ) vhba@1
...
  vhba_lun_t( 64002d478630 ) lun(0) vlun-id(0) [COMMON]
      devinfo(4001a1cd7f8) scsi_device(400152d7b58) scsi_inquiry(40016a334f8).inq_dtype(0x1F=unknown)
      /virtual-devices@100/channel-devices@200/scsi@1/iport@0/unknown@w200000110d211500,0

Pass the scsi_inquiry value to the following command that outputs the vendor, product, and version number of the simulated device:

# echo "40016a334f8::print scsi_inquiry inq_vid inq_pid inq_revision" | mdb -k
inq_vid = [ "ORCL    " ]
inq_pid = [ "vHBA:vsan       " ]
inq_revision = [ "1.0 " ]

A simulated LUN0 has a SCSI device type of UNKNOWN, as shown by the inq_dtype value of 0x1F in the previous mdb -k example output.

Executing the following command and specifying LUN0's device path shows that the 'nulldriver' is bound to this device:

# prtconf -D /virtual-devices@100/channel-devices@200/scsi@0/iport@0/unknown@w200000110d211500,0
unknown, instance #1 (driver name: nulldriver)