[libvirt] changes to domain XML for SCSI support

[Paolo Bonzini]

On 10/27/2011 11:19 AM, Daniel P. Berrange wrote:
>>     <address type='scsi' host='...'
>>                          bus='...' target='...' lun='...'/>
>>
>> where host selects the qdev parent device, while channel/target/lun
>> are passed as qdev properties (the QEMU names are respectively
>> channel, scsi-id, lun).
>
> The problem here is that we already have an address type that is used
> for SCSI - type='drive'. If we switch to type='scsi' then we break
> backwards compatibility.
>
> The current drive addressing scheme has  controller, bus, unit.
> Controller is equivalent to what you called host. bus matches.
> and unit maps to lun. Thus we only need to add a new 'target'
> attribute to the existing drive addressing scheme, making sure
> it defaults to zero for any existing configs. This new attr
> would be ignored for any IDE/Floppy controller drives.

Makes sense.

>> 2) add a new<drive device='lun'>  attribute.
>>
>>    <drive type='block' device='lun'>
>>      <driver name='qemu' type='raw'/>
>>      <source dev='/dev/sda'/>
>>      <target dev='sda' bus='scsi'>
>>      <address type='scsi' host='...' bus='...' target='...' lun='...'/>
>>    </drive>
>
> IMHO this is still the best for LUN passthrough because it operates
> correctly with lock managers and security managers, and logically
> we are assigning drives, so the expectation is to see them in the
> XML as<drive>  elements.

Yes, it makes sense.  I like the idea of using <hostdev> only for opaque 
passthrough.

Any bikeshedding on device='lun'?

>> 1) the "mode" attribute is dropped (more precisely, only "subsystem"
>> is allowed and never printed; everything else is rejected);
>
> The mode attribute was essentially being used to distinguish between
> devices that were directly associated with a specific hardware device,
> vs those which are logical devices on top of a hardware device.

... and which, as you said later, should not use <hostdev> at all.

> While this is somewhat redundant, we can't drop the existing mode
> attribute from the XML because some apps may be checking for its
> existance.

The RNG schemas describe it as optional, that's why I said it could go.

>> NPIV support: generalizing hostdev source addresses
>> ===================================================
>>
>> In NPIV, a virtual HBA is created using "virsh nodedev-create" and
>> passed to the guest.  Such virtual adapter does have a stable
>> address, namely its WWN.  As such, it can be addressed simply by
>> generalizing the kind of source address that can be passed to
>> <hostdev type='scsi_host'/>:
>
> Yep, WWNN/WWPN are clearly the desirable unique attribute to use
> here.
>
>>    <hostdev type='scsi_host'>
>>      <source>
>>        <address type='wwn' wwpn='...' wwnn='...'/>
>>      </source>
>>    </hostdev>
>>
>> (Note that this doesn't use<source name='...'/>  and, as such, it
>> does not rely on the ideas above).
>
> Any time that an element has a choice of schemas to follow, we need
> an attribute to indentify which schema is being followed. So, if we
> allow<source>  to work with WWNN or a nodedev device name, we'd need
> to add a mode='wwwn|nodedev' attribute to<source>  to tell apps what
> schema this device follows.

So this could become

- <source mode='host'> lets you address a host by its unique name.  For WWN:

<controller type='scsi'>
   <source mode='host'>
     <address type='wwn' wwpn='...' wwnn='...'>
   </source>
</controller>

Even if other kinds of addresses were allowed (IQN for , the source 
would still be 'host'.

- <source mode='nodedev'> lets you address a host by its parent device + 
optionally the host_unique_id that is available in sysfs

<controller type='scsi'>
   <source mode='nodedev'>
     <address type='pci' bus='...'>
     <unique_id>0</unique_id>  (optional)
   </source>
</controller>

- an optional <target> element can be added to restrict passthrough to a 
single target port:

<controller type='scsi'>
   <source mode='...'>
     <address ... as above ...>
     <target>0</target>
   </source>
</controller>


> I like the idea of using WWNN/WWPN for NPIV controller assignment
> since this is a strong unique attribute.
>
> I'm not such a fan of using the node device names as we don't have
> a particularly strong guarantee of stability for those. eg updating
> to a newer Linux release might change the node device names. So I'd
> rather find some kind of other unique attribute for the SCSI controllers
> to use.

It should be possible to get a unique name from the INQUIRY command's 
device identification page.  I guess whether a descriptor exists for the 
target port depends on the controller.  Here I just emulated a SAS 
controller using tcm_loop:

$ sg_inq -i /dev/sdb
...
     transport: Serial Attached SCSI (SAS)
     designator_type: SCSI name string,  code_set: UTF-8
     associated with the target port
       SCSI name string:
       naa.600140554cf3a18e,t,0x0003

These could be used for <source mode='host'>, the above being:

<controller type='scsi'>
   <source mode='host'>
     <address type='naa' naa='600140554cf3a18e'>
     <target>3</target>  (pass through this target only)
   </source>
</controller>


Unfortunately, these are not available anywhere in sysfs or the udev 
database.  So it's probably simplest to start with the NPIV special case 
only and make sure the ideas extend to other stable addressing modes.

Paolo