Bug 1523564 - Start vm with hostdev <source protocol='vhost' ...> will cause unknown error.
Summary: Start vm with hostdev <source protocol='vhost' ...> will cause unknown error.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.5
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: yisun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-08 10:11 UTC by yisun
Modified: 2018-10-30 09:51 UTC (History)
5 users (show)

Fixed In Version: libvirt-4.3.0-1.el7
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-10-30 09:50:00 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3113 None None None 2018-10-30 09:51:23 UTC

Description yisun 2017-12-08 10:11:40 UTC
Description of problem:
Start vm with hostdev <source protocol='vhost' ...> will cause unknown error.

Version-Release number of selected component (if applicable):
libvirt-3.9.0-5.el7.x86_64
kernel-3.10.0-811.el7.x86_64
qemu-kvm-rhev-2.10.0-11.el7.x86_6

How reproducible:
100%

Steps to Reproduce:
1. Having a HBA card connecting to backend storage on host
# virsh nodedev-dumpxml scsi_host8
<device>
  <name>scsi_host8</name>
  <path>/sys/devices/pci0000:00/0000:00:03.0/0000:08:00.1/host8</path>
  <parent>pci_0000_08_00_1</parent>
  <capability type='scsi_host'>
    <host>8</host>
    <unique_id>8</unique_id>
    <capability type='fc_host'>
      <wwnn>2001001b32a9da4e</wwnn>
      <wwpn>2101001b32a9da4e</wwpn>
      <fabric_wwn>2001547feeb71cc1</fabric_wwn>
    </capability>
    <capability type='vport_ops'>
      <max_vports>127</max_vports>
      <vports>0</vports>
    </capability>
  </capability>
</device>

2. edit a vm and add following xml:
# virsh edit avocado-vt-vm1
...
<hostdev mode='subsystem' type='scsi_host' managed='no'>
    <source protocol='vhost' wwpn='naa.2101001b32a9da4e'/>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</hostdev>
...

3. start the vm
# virsh start avocado-vt-vm1
error: Failed to start domain avocado-vt-vm1
error: An error occurred, but the cause is unknown

Actual results:
vm cannot be started, but the reason is unknown

Expected results:
vm should be started?
or clear error msg should be provided.

Additional info:
In https://libvirt.org/formatdomain.html
related info as follow:
===============================================
  ...
  <devices>
    <hostdev mode='subsystem' type='scsi_host'>
      <source protocol='vhost' wwpn='naa.50014057667280d8'/>
    </hostdev>
  </devices>
  ...
  ...
scsi_host
    since 2.5.0For SCSI devices, user is responsible to make sure the device is not used by host. This type passes all LUNs presented by a single HBA to the guest. 
===============================================

I just following this instruction to add the <hostdev>, did I misuse something here?

Comment 2 John Ferlan 2017-12-12 14:23:37 UTC
I don't recall all the details around scsi-vhost, but I don't believe at some point it was determined a vHBA scsi_host cannot be passed through this way.

IIRC, the code is designed for an HBA not a vport capable HBA. The upstream posting cover letter and patches can be found here:

https://www.redhat.com/archives/libvir-list/2016-September/msg00148.html

there's a fairly decent history of alterations and a cover letter that can be followed if you so desire.

Beyond that, there is not a whole lot of documentation available, but http://wiki.libvirt.org/page/Vhost-scsi_target does describe the setup and feature a bit.

After a bit of research, I found the problem you're seeing is that "/dev/vhost-scsi" doesn't exist and that's why things are failing without a real error message.

I also should note that through this bz, I also found that if you don't provide the <address> a different problem is raised, but I have a fix for that too.

I have posted some patches upstream:

https://www.redhat.com/archives/libvir-list/2017-December/msg00394.html

Comment 4 John Ferlan 2017-12-13 21:00:16 UTC
Pushed patches upstream:

git show 211415492266084e9652615de07eb1527878e2c2
Author: John Ferlan <jferlan@redhat.com>
Date:   Tue Dec 12 08:31:03 2017 -0500

    util: Report error if vhost-scsi device file cannot be found
    
...
    
    If the vhost-scsi device file cannot be found, the generic error
    
        "error: An error occurred, but the cause is unknown"
    
    is returned.  Let's add a real error message to make it clear
    why the failure occurred.


$ git describe 211415492266084e9652615de07eb1527878e2c2
v3.10.0-65-g211415492
$

Comment 6 yisun 2018-06-13 08:45:04 UTC
Verified on libvirt-4.3.0-1.virtcov.el7.x86_64 and PASSED

1. #virsh edit avocado-vt-vm1
...
    <hostdev mode='subsystem' type='scsi_host' managed='no'>
      <source protocol='vhost' wwpn='naa.2101001b32a9da4e'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </hostdev>
...

2. # virsh start avocado-vt-vm1
error: Failed to start domain avocado-vt-vm1
error: unsupported configuration: vhost-scsi device file '/dev/vhost-scsi' cannot be found

3. remove the hostdev part and start the vm
4. prepare hostdev xml
# cat xml
    <hostdev mode='subsystem' type='scsi_host' managed='no'>
      <source protocol='vhost' wwpn='naa.2101001b32a9da4e'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
    </hostdev>

4. do hotplug:
# virsh attach-device avocado-vt-vm1 xml
error: Failed to attach device from xml
error: Unable to access /sys/kernel/config/target/vhost//naa.2101001b32a9da4e: No such file or directory

Comment 8 errata-xmlrpc 2018-10-30 09:50:00 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3113


Note You need to log in before you can comment on or make changes to this bug.