Configuring virtual SCSI HBAs and virtual SANs is very flexible. The physical SCSI HBA initiator port that is used by the ldm add-vsan command can drive any type of bus that supports SCSI, such as Fibre Channel, SAS, or SATA. A virtual SCSI HBA and a virtual SAN can execute in the same domain. The more common configuration has the virtual SCSI HBA and the virtual SAN execute in different domains where the virtual SAN executes in a service domain that has direct access to a physical HBA card.
Although a virtual SAN is associated conceptually with a physical SAN, it does not need to be. For example, you can create a virtual SAN that comprises the set of local storage devices that are reachable from a motherboard HBA.
The virtual HBA subsystem unconditionally creates a virtual LUN for each physical LUN that is discovered. So, as with virtual disks, you must not have conflicting workloads access the same virtual LUN.
For example, if an initiator port reaches ten physical SCSI devices, the virtual HBA subsystem creates ten virtual LUNs in the guest domain. If the guest operating system boots from one of those virtual LUNs, you must ensure that no other guest domain accesses the virtual LUN, and that the domain that owns the physical SCSI device does not access the physical LUN.
A similar warning holds for any virtual LUNs that might be in use by a guest domain. You must strictly control access to such virtual LUNs on other guest domains and access to the underlying physical LUN on the service domain to prevent conflicting access. Such conflicting access might result in data corruption.
Lastly, 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.