Go to main content

Oracle® VM Server for SPARC 3.6 Administration Guide

Exit Print View

Updated: September 2019
 
 

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.

To determine the number and identity of LUN0s that belong to an initiator port, run the OpenBoot PROM probe-scsi-all command in the service domain.

The following probe-scsi-all example output shows that no LUN0 belongs to the first target port, 200400110d237501. However, the second target port does have a LUN0. So, the vsan module simulates a LUN0 only for the first target port. The second target port does not require a simulated LUN0 because a LUN0 is present already.

{0} ok probe-scsi-all
/pci@300/pci@1/pci@0/pci@4/SUNW,emlxs@0,11
Device  PortID 12201  WWPN 200400110d237501
   LUN  2     Disk     SUN     StorEdge 3511   327R
   LUN  3     Disk     SUN     StorEdge 3511   327R
Device  PortID 12200  WWPN 200400110d237500
   LUN  0     Disk     SUN     StorEdge 3511   327R
   LUN  1     Disk     SUN     StorEdge 3511   327R

To see how a simulated LUN0 is represented, run the probe-scsi-all command in a guest domain.

The vsan module sets the SCSI device type of a simulated LUN0 to 0x1F, which OpenBoot PROM renders as UNKNOWN.

The following probe-scsi-all example output in the guest domain shows that the SCSI device type of the simulated LUN0 is UNKNOWN. For simulated LUN0s, the vsan module also sets the vendor, product, and version numbers to reasonable values.

{3} ok probe-scsi-all
virtual-devices@100/channel-devices@200/scsi@0
		
vHBA

TPORT-PHYS: w216000c0ee9088e4
   LUN: 1   Disk     SUN     StorEdge 3511   327R    487856128 Blocks, 249 GB
   LUN: 0   UNKNOWN  ORCL    vHBA:vsan       1.0

The following prtconf output for the guest domain shows that the nulldriver is bound to the simulated LUN0 device, and that its device type is scsa,nodev:

primary# prtconf -D
...
    SUNW,sun4v-scsi-hba, instance #2 (driver name: vhba)
        vhba, instance #3 (driver name: vhba)
...
            scsa,nodev, instance #2 (driver name: nulldriver)
...