Bug 1311928 - Attach interface with type of hostdev supports options of --model and --target
Summary: Attach interface with type of hostdev supports options of --model and --target
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Virtualization Maintenance
QA Contact: jiyan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-25 10:54 UTC by yalzhang@redhat.com
Modified: 2020-02-11 13:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-11 13:12:24 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description yalzhang@redhat.com 2016-02-25 10:54:30 UTC
Description of problem:
Attach interface with type of hostdev supports options of --model and --target

Version-Release number of selected component (if applicable):
libvirt-1.3.1-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Setup a SR-IOV, then start a guest.
2.Attach an interface with type of hostdev and --target option, it will succeed.

[root@ibm-x3850x5-05 ~]# virsh attach-interface rhel7.2 hostdev 0000:86:10.0 --target kshdfkjdf --managed --persistent
Interface attached successfully

[root@ibm-x3850x5-05 ~]# virsh dumpxml rhel7.2 | grep /interface -B8
.....
   <interface type='hostdev' managed='yes'>
      <mac address='52:54:00:2e:cd:0b'/>
      <driver name='vfio'/>
      <source>
        <address type='pci' domain='0x0000' bus='0x86' slot='0x10' function='0x0'/>
      </source>
      <target dev='kshdfkjdf'/>
      <alias name='hostdev0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/>
    </interface>

3.Attach an interface with type of hostdev and --model option, it will succeed.

[root@ibm-x3850x5-05 ~]# virsh attach-interface rhel7.2 hostdev 0000:86:10.1 --model e1000 --managed --persistent
Interface attached successfully

[root@ibm-x3850x5-05 ~]# virsh dumpxml rhel7.2 | grep /interface -B9
.......
    <interface type='hostdev' managed='yes'>
      <mac address='52:54:00:66:b1:ea'/>
      <driver name='vfio'/>
      <source>
        <address type='pci' domain='0x0000' bus='0x86' slot='0x10' function='0x1'/>
      </source>
      <model type='e1000'/>
      <alias name='hostdev1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/>
    </interface>

4. Validate the xml with all the interface above, it will succeed.
[root@ibm-x3850x5-05 qemu]# pwd
/etc/libvirt/qemu
[root@ibm-x3850x5-05 qemu]# virt-xml-validate rhel7.2.xml
rhel7.2.xml validates
[root@ibm-x3850x5-05 qemu]# echo $?
0
5. On the guest,check the network device
guest# lspci | grep -i eth
00:03.0 Ethernet controller: Red Hat, Inc Virtio network device
00:0c.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
00:0d.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
guest# 

Actual results:
The option "--model" or "--target" is invalid for hostdev type interface, but they can be specified with no reminder or error. 

Expected results:
The interface of hostdev should not support a "model type" or "target dev" specified as they are invalid. Or there should be a statement about this.


Addtional info:
N/A

Comment 3 Laine Stump 2017-03-27 00:05:51 UTC
I don't like the idea of virsh deciding that it's not reasonable to specify a particular option for a particular type of device. This really should be handled in the libvirt parsing, but I'm unsure of exactly what we should complain about. In the case of model, for example, the model is controlled by what the hardware is in the case of a hostdev network adapter, but if the guest uses a libvirt network, it doesn't know until the guest is started that the interface is going to be hostdev (and thus model will be irrelevant).

Comment 5 Laine Stump 2017-12-13 16:54:36 UTC
Still no idea for a clean solution.

Comment 6 Jaroslav Suchanek 2020-02-11 13:12:24 UTC
This bug was closed deferred as a result of bug triage.

Please reopen if you disagree and provide justification why this bug should
get enough priority. Most important would be information about impact on
customer or layered product. Please indicate requested target release.


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