[libvirt-users] Questions regarding hostdev scsi

[Martin Kletzander]

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 at redhat.com
>https://www.redhat.com/mailman/listinfo/libvirt-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20160318/c6af0eb9/attachment.sig>