On Thu, Mar 17, 2016 at 12:14:43PM +0100, Martin Polednik wrote:
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.
OK, I'll lave my two cents here. I got lost in this description, it's almost as I wrote it myself =) What you would find useful is if we got you back one XML that has all node devices ordered in a tree, so the hierarchy is clearly visible from the XML, right? If you don't use dynamic_ownership and you set the permissions yourself, you need to be able to access the host system (which you can and do). My question in that case is; if you have the access, why don't just get all the information from sysfs where libvirt is getting those? You wouldn't have to go through any tree reconstruction and you'd have to parse way less stuff then now.
Regards, mpolednik _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
