6:14 a.m.
Hi!
I'm oVirt developer responsible for most of 'hostdev' support. While
working on SCSI passthrough (that is hostdev type='scsi'), I've
encountered few issues I'm not sure how to solve somewhat effectively
and nicely.
Just a note - oVirt by default disables 'dynamic_ownership', meaning
we have to handle endpoint ownership/labeling ourselves. This
is not something I can change in a short term. Also, oVirt uses
libvirt's python API, I'll do my best using the original C names.
To report and construct the hostdev element, I am using
virConnectListAllNodeDevices. To get information about the devices,
virNodeDeviceGetXMLDesc is called on each device. For PCI and USB
devices, XML of the device contains everything needed to
a) construct the element,
b) fix endpoint permissions.
SCSI device becomes more difficult as the information is scattered
between multiple devices. Devices I have encountered contain this
subtree:
<device>
<name>scsi_host4</name>
<path>/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4</path>
<parent>pci_0000_00_1f_2</parent>
<capability type='scsi_host'>
<host>4</host>
<unique_id>5</unique_id>
</capability>
</device>
<device>
<name>scsi_target4_0_0</name>
<path>/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0</path>
<parent>scsi_host4</parent>
<capability type='scsi_target'>
<target>target4:0:0</target>
</capability>
</device>
<device>
<name>scsi_4_0_0_0</name>
<path>/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0</path>
<parent>scsi_target4_0_0</parent>
<driver>
<name>sd</name>
</driver>
<capability type='scsi'>
<host>4</host>
<bus>0</bus>
<target>0</target>
<lun>0</lun>
<type>disk</type>
</capability>
</device>
<device>
<name>block_sdb_Samsung_SSD_850_PRO_256GB_S251NXAGB42213R</name>
<path>/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sdb</path>
<parent>scsi_4_0_0_0</parent>
<capability type='storage'>
<block>/dev/sdb</block>
<bus>ata</bus>
<drive_type>disk</drive_type>
<model>Samsung SSD 850</model>
<vendor>ATA</vendor>
<serial>Samsung_SSD_850_PRO_256GB_S251NXAGB42213R</serial>
<size>256060514304</size>
<logical_block_size>512</logical_block_size>
<num_blocks>500118192</num_blocks>
</capability>
</device>
<device>
<name>scsi_generic_sg1</name>
<path>/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/scsi_generic/sg1</path>
<parent>scsi_4_0_0_0</parent>
<capability type='scsi_generic'>
<char>/dev/sg1</char>
</capability>
</device>
To construct the element, information from device scsi_4_0_0_0 is
needed for <address> element (minus the host element). Adapter element
is one of the places that I am not sure which information I can rely
on, currently 'host' element from scsi_4_0_0_0 is used to form string
'scsi_host{host}'. Is this correct? Reliable?
Whole different issue is locating the endpoint (/dev/sg{int}) to set
the permissions. From the subtree, it's apparent that it is included
in device called scsi_generic_sg1, but there is no *direct* link
between scsi_4_0_0_0 and scsi_generic_sg1. At this point, we present
user with devices matching capability='scsi', therefore to get the
information 2 additional parses of the tree would have to be done.
Other way would be reporting 'scsi_generic' capability, where only
2 additional virNodeDeviceLookupByName calls would be required (to
descend 2 levels). Is there anything *really* wrong with this
approach? Are there any other options without dynamic ownershit?
Seclabel doesn't seem to be available.
I'm thankful for any hints.
Regards,
mpolednik