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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list