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
Martin Kletzander
2016-Mar-18 09:17 UTC
Re: [libvirt-users] Questions regarding hostdev scsi
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@redhat.com >https://www.redhat.com/mailman/listinfo/libvirt-users