Bug 1311928

Summary: Attach interface with type of hostdev supports options of --model and --target
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: yalzhang <yalzhang>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED DEFERRED QA Contact: jiyan <jiyan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: dyuan, mzhan, rbalakri, xuzhang, yalzhang
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-11 13:12:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.