The operational model for using virtual SCSI HBAs is qualitatively different than for other types of Oracle VM Server for SPARC virtual devices because only the virtual SCSI HBA and virtual SAN instances are known to the Logical Domains Manager. The virtual LUNs that appear in the guest domain and the physical LUNs that appear in the service domain are not known until they are discovered at runtime. The virtual LUNs and physical LUNs are discovered implicitly when the associated LDC connection is reset and explicitly by using the ldm rescan-vhba command.
Although you use the ldm command to name a virtual disk explicitly, a virtual LUN in a guest domain derives its identity from the identity of the associated physical LUN in the service domain. See the ldm(1M) man page.
For example, the physical LUN and the virtual LUN share the text shown in bold in the following device paths:
Physical LUN in the service domain:
Virtual LUN in the guest domain:
Note that the scsi@1 component in the virtual LUN's device path denotes the virtual SCSI HBA instance of which this virtual LUN is a member.
Because a virtual SCSI HBA's set of virtual LUNs is derived from the service domain at runtime, virtual LUNs cannot be added or removed explicitly from the guest domain. Instead, you must add or remove the underlying physical LUNs so that the guest domain's virtual LUN membership can be altered. An event such as a domain reboot or a domain migration, might cause the guest domains' virtual LUN membership to change. This change occurs because the virtual LUNs are rediscovered automatically whenever the virtual SCSI HBA's LDC connection is reset. If a virtual LUN's underlying physical LUN is not found on a future discovery, the virtual LUN is marked as unavailable and accesses to the virtual LUN return an error similar to the following:
WARNING: .../scsi@1/iport@0/disk@w216000c0ff8089d5,0 (sd6): ... Command failed to complete...Device is gone
A virtual SCSI HBA instance is managed by the vhba driver, but a virtual LUN is managed by a SCSI target driver based on the device type of the underlying physical LUN. The following output confirms that the vhba driver manages the virtual SCSI HBA instance and that the sd SCSI disk driver manages the virtual LUN:
# prtconf -a -D /dev/dsk/c2t216000C0FF8089D5d0 SUNW,SPARC-Enterprise-T5220 (driver name: rootnex) virtual-devices, instance #0 (driver name: vnex) channel-devices, instance #0 (driver name: cnex) scsi, instance #0 (driver name: vhba) iport, instance #3 (driver name: vhba) disk, instance #30 (driver name: sd)