RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1558655 - [SR-IOV] - Can't start VM with SR-IOV vNIC [rhel-7.5.z]
Summary: [SR-IOV] - Can't start VM with SR-IOV vNIC [rhel-7.5.z]
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: yafu
URL:
Whiteboard:
Depends On: 1556828
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-20 17:25 UTC by Oneata Mircea Teodor
Modified: 2018-04-10 19:14 UTC (History)
18 users (show)

Fixed In Version: libvirt-3.9.0-14.el7_5.2
Doc Type: Bug Fix
Doc Text:
Prior to this update, if the "interface type='hostdev'" configuration was used for a guest virtual machine, booting the guest in some cases failed due to a validation error. With this update, the libvirt service has been fixed to ignore hostdev duplicates in the XML configuration. As a result, the guest boots correctly in the described scenario.
Clone Of: 1556828
Environment:
Last Closed: 2018-04-10 19:13:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1056 0 None None None 2018-04-10 19:14:07 UTC

Description Oneata Mircea Teodor 2018-03-20 17:25:53 UTC 
This bug has been copied from bug #1556828 and has been proposed to be backported to 7.5 z-stream (EUS).
Comment 5 yafu 2018-03-21 10:15:34 UTC 
Test with libvirt-3.9.0-14.el7_5.2.x86_64.

Test steps:
(1)Scenario 1: hotplug->unhotplug->hotplug hostdev interface with alias name:
1.Start a guest:
#virsh start iommu1
Domain iommu1 started

2.Prepare a hostdev interface with alias name:
#cat interface.xml
<interface type='hostdev' managed='yes'>
  <mac address='66:18:0b:c2:85:b8'/>
  <source>
    <address type='pci' domain='0x0000' bus='0x04' slot='0x10' function='0x3'/>
  </source>
  <alias name='ua-04c2decd-4e33-4023-84de-a2205c777af7'/>
  <model type='virtio'/>
</interface>

3.Hotplug the hostdev interface deto the guest:
#virsh attach-device iommu1 interface.xml
Device attached successfully

4.Check the hostdev interface in the live guest xml:
#virsh dumpxml iommu1 | grep -A10 interface
<interface type='hostdev' managed='yes'>
      <mac address='66:18:0b:c2:85:b8'/>
      <driver name='vfio'/>
    ...
      <alias name='ua-04c2decd-4e33-4023-84de-a2205c777af7'/>
    ...
</interface>

5.Hotunplug the hostdev interface from the guest:
#virsh detach-device iommu1 interface.xml
Device detached successfully

6.Check the hostdev interface in the live guest xml:
#virsh dumpxml iommu1  | grep hostdev
no output

7.Repeat step3-4, the hostdev interface can attach successfully to the guest.

(2)Scenario 2: coldplug->coldunplug hostdev interface with alias name:
1.Coldplug hostdev interface to guest:
#virsh attach-device iommu1 interface.xml --config
Device detached successfully

2.Start the guest:
#virsh start iommu1
Domain iommu1 started

3.Check the hostdev interface in the live xml:
#virsh dumpxml iommu1 | grep -A10 interface
<interface type='hostdev' managed='yes'>
      <mac address='66:18:0b:c2:85:b8'/>
      <driver name='vfio'/>
    ...
      <alias name='ua-04c2decd-4e33-4023-84de-a2205c777af7'/>
    ...
</interface>

4.Coldunplug the hostdev interface from the guest:
#virsh detach-device iommu1 interface.xml --config
Device detached successfully

5.Check the hostdev interface in the inactive domain xml:
#virsh dumpxml iommu1 --inactive | grep -i hostdev
no output

(3)Scenario 3: Hotplug hostdev interface with the same alias name:
1.Attach the hostdev interface device with alias name to the guest:
#virsh attach-device iommu1 interface.xml
Device attached successfully

2.Repeat step 1:
#virsh attach-device iommu1 interface.xml
error: Failed to attach device from /nic-xml/interface.xml
error: XML error: non unique alias detected: ua-04c2decd-4e33-4023-84de-a2205c777af
Comment 6 Michal Privoznik 2018-03-21 10:35:04 UTC 
Restoring doc text I added earlier.
Comment 7 yafu 2018-03-22 04:53:22 UTC 
Hi,Michael,

Could you help to test this bug from RHV with libvirt-3.9.0-14.el7_5.2.x86_64 please?

Thanks a lot.
Comment 8 Michael Burman 2018-03-22 09:09:19 UTC 
(In reply to yafu from comment #7)
> Hi,Michael,
> 
> Could you help to test this bug from RHV with
> libvirt-3.9.0-14.el7_5.2.x86_64 please?
> 
> Thanks a lot.

Hi Yafu, sure np
can you please send me the link to this version build(RPM) and i will test it)
Comment 11 yafu 2018-03-23 05:03:04 UTC 
Hi,Michal,

I found when hotunplug device from the guest, libvirt did not check the alias name. 
Could you help to check that please? Thanks.

Test steps:
1.Prepare hostdev interface xml:
#cat interface.xml-1
<interface type='hostdev' managed='yes'>
  <mac address='66:18:0b:c2:85:b8'/>
  <source>
    <address type='pci' domain='0x0000' bus='0x04' slot='0x10' function='0x3'/>
  </source>
  ***<alias name='ua-04c2decd-4e33-4023-84de-a2205c777af7'/>***
  <model type='virtio'/>
</interface>

2.Hotplug the hotdev interface to the guest:
#virsh attach-device iommu1 interface.xml-1
Device attached successfully

3.Check the live xml:
#virsh dumpxml iommu1 | grep -A10 interface
<interface type='hostdev' managed='yes'>
      <mac address='66:18:0b:c2:85:b8'/>
      <driver name='vfio'/>
    ...
      ***<alias name='ua-04c2decd-4e33-4023-84de-a2205c777af7'/>***
    ...
</interface>


4.Prepare another hostdev interface xml with different alias name:
#cat interface.xml-2
<interface type='hostdev' managed='yes'>
  <mac address='66:18:0b:c2:85:b8'/>
  <source>
    <address type='pci' domain='0x0000' bus='0x04' slot='0x10' function='0x3'/>
  </source>
  ***<alias name='ua-04c2decd'/>***
  <model type='virtio'/>
</interface>

5.Hotunplug the hostdev interface from guest:
#virsh detach-device iommu1 interface.xml-2
Device detached successfully

6.Check the live xml and found the hostdev interface detached successfully.
Comment 12 Michal Privoznik 2018-03-23 08:16:20 UTC 
(In reply to yafu from comment #11)
> Hi,Michal,
> 
> I found when hotunplug device from the guest, libvirt did not check the
> alias name. 
> Could you help to check that please? Thanks.
> 

This is expected. Libvirt makes no promises on which device attributes it uses to find the matching device in domain definition. That's why users are required to pass whole device XML. Having said that, for <interface/> it currently uses MAC address.
Comment 15 yafu 2018-03-26 04:59:36 UTC 
According to comment 5 and comment 13, move the bug to verified.
Comment 18 errata-xmlrpc 2018-04-10 19:13:42 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/RHBA-2018:1056
Note You need to log in before you can comment on or make changes to this bug.