Bug 1311928 - Attach interface with type of hostdev supports options of --model and --target
Attach interface with type of hostdev supports options of --model and --target
Status: ASSIGNED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Laine Stump
Jing Qi
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-25 05:54 EST by yalzhang@redhat.com
Modified: 2018-07-18 10:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description yalzhang@redhat.com 2016-02-25 05:54:30 EST
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-26 20:05:51 EDT
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 11:54:36 EST
Still no idea for a clean solution.

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