Bug 1367786 - [RFE] SRIOV - PF / VM that assign to PF does not get vlan tag
Summary: [RFE] SRIOV - PF / VM that assign to PF does not get vlan tag
Keywords:
Status: CLOSED DUPLICATE of bug 1402583
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Stephen Finucane
QA Contact: OSP DFG:Compute
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-17 13:11 UTC by Eran Kuris
Modified: 2023-03-21 18:38 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-04 16:19:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1743458 0 None None None 2018-05-07 11:03:33 UTC
OpenStack gerrit 381370 0 None MERGED Expose SR-IOV physical function's VLAN tag to guests 2020-12-29 22:42:42 UTC

Internal Links: 1325686

Description Eran Kuris 2016-08-17 13:11:21 UTC
Description of problem:
During RFE testing Manage SR-IOV PFs as Neutron ports, I found VM booted with Neutron port vnic_type direct-physical but it does not get access to DHCP server.
The problem is that the PF / VM does not get VLAN tag with the internal vlan.
Workaround :
Enter to the VM via console and set vlan interface.

Version-Release number of selected component (if applicable):
python-neutronclient-4.2.1-0.20160721230146.3b1c538.el7ost.noarch
openstack-neutron-common-9.0.0-0.20160726001729.6a23add.el7ost.noarch
python-neutron-9.0.0-0.20160726001729.6a23add.el7ost.noarch
openstack-neutron-fwaas-9.0.0-0.20160720211704.c3e491c.el7ost.noarch
openstack-neutron-metering-agent-9.0.0-0.20160726001729.6a23add.el7ost.noarch
openstack-neutron-openvswitch-9.0.0-0.20160726001729.6a23add.el7ost.noarch
puppet-neutron-9.1.0-0.20160725142451.4061b39.el7ost.noarch
python-neutron-lib-0.2.1-0.20160726025313.405f896.el7ost.noarch
openstack-neutron-ml2-9.0.0-0.20160726001729.6a23add.el7ost.noarch
openstack-neutron-9.0.0-0.20160726001729.6a23add.el7ost.noarch
openstack-neutron-sriov-nic-agent-9.0.0-0.20160726001729.6a23add.el7ost.noarch

How reproducible:
always

Steps to Reproduce:
1.deploy SRIOV env
2.create port  vnic type : direct- physical 
3. boot vm 
4. the vm is active but no iP addres  - no connectivity to DHCP server


Actual results:
no vlan tag on PF / vm 

Expected results:


Additional info:

Comment 2 Assaf Muller 2016-08-23 20:22:02 UTC
Vladik am I correct to understand that this is a Nova RFE and not a Neutron bug?

Comment 3 Vladik Romanovsky 2016-08-24 14:18:00 UTC
(In reply to Assaf Muller from comment #2)
> Vladik am I correct to understand that this is a Nova RFE and not a Neutron
> bug?

Assaf, you're right, I don't see it as a bug, as it has never been implemented and it was a known limitation[1].
Unlike the VFs behaviour, any information (MAC, VLAN) about the PFs will be reset during the assignment. We have found a workaround for updating the MAC, but didn't get to solve the VLAN issue.

We should open an RFE and probably work together to find an angle on this issue.

Thanks,
Vladik

[1] https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/sriov_pf_neutron_port.html

Comment 4 Nir Yechiel 2016-08-24 15:33:21 UTC
Removing this from being a blocker of BZ #1325686. This should be treated as a separate RFE.

Comment 5 Eran Kuris 2016-08-25 06:11:03 UTC
(In reply to Nir Yechiel from comment #4)
> Removing this from being a blocker of BZ #1325686. This should be treated as
> a separate RFE.

Nir ,
According to this bug do you think that RFE :https://bugzilla.redhat.com/show_bug.cgi?id=1325686 
is relevant to RHOS -10  ?

Comment 6 Nir Yechiel 2016-08-25 06:16:59 UTC
(In reply to Eran Kuris from comment #5)
> (In reply to Nir Yechiel from comment #4)
> > Removing this from being a blocker of BZ #1325686. This should be treated as
> > a separate RFE.
> 
> Nir ,
> According to this bug do you think that RFE
> :https://bugzilla.redhat.com/show_bug.cgi?id=1325686 
> is relevant to RHOS -10  ?

No.

Comment 13 Eran Kuris 2017-05-25 13:04:24 UTC
This issue is not a duplicate of bug 1402583. It different issue.

Comment 14 Eran Kuris 2017-05-25 13:47:06 UTC
In RFE  bug 1402583 Nova expose "VLAN" ID of the network to the guest.After discussion with Vladik R. from Nova team, suggested that cloud-config / cloud-init will use this info and set in the PF guest sub-interface VLAN with the relevant VLAN id.

Comment 15 Eran Kuris 2017-06-05 13:58:54 UTC
Workaround :
Create cloud config file- create_int.yaml
#cloud-config
write_files:
  - path: "/etc/sysconfig/network-scripts/ifcfg-eth0.224"
    owner: "root"
    permissions: '777'
    content: |
      DEVICE="eth0.224"
      BOOTPROTO="dhcp"
      ONBOOT="yes"
      VLAN="yes"
      PERSISTENT_DHCLIENT="yes"
runcmd:
    - [ sh, -c , 'systemctl restart network' ]



boot instance to PF:
nova boot --flavor 3 --image rhel PF  --config-drive true --user-data create_int.yaml --nic port-id=b73acd2b-a064-4045-aceb-f190f19b54bb

Comment 16 Sahid Ferdjaoui 2018-04-13 12:39:41 UTC
libvirt does not provide any mechanism when passing physical function to guest to update its MAC address that because interface element does not support passing PF. Only SRIOV VF is supported [0].

To pass PF nova uses libvirt hostdev element but it does not support any network related features.

The comment #15 provides a workaround. If we really want this we need first to open a BZ in libvirt component that to support PF for interface element. If not I guess we should close the bug as WONTFIX.

[0] https://libvirt.org/formatdomain.html#elementsNICSHostdev

Comment 18 Stephen Finucane 2018-05-04 13:56:45 UTC
(In reply to Eran Kuris from comment #14)
> In RFE  bug 1402583 Nova expose "VLAN" ID of the network to the guest.After
> discussion with Vladik R. from Nova team, suggested that cloud-config /
> cloud-init will use this info and set in the PF guest sub-interface VLAN
> with the relevant VLAN id.

For reference, the commit that added this feature appears to be 18a23b747b410c81ff222cc552943326aacbb179. It appears we could extend this to include physical functions. However, I'm not sure if we'd be able to identify these or not. This warrants further investigation.

Comment 19 Artom Lifshitz 2018-05-04 16:19:51 UTC
Hi Eran,

There are a couple things going on here.

The original PF vlan tagging work has a bug [1] where "hostdev" devices in the instance XML aren't considered for device metadata, preventing the vlan tag from being exposed to the guest in the metadata. A fix [2] is in progress.

That being said, I don't see how this bugzilla is different from the original RFE that Vladik has implemented [3]. Once as PF is passed through to the guest, the host loses all control over it, and it is up to the guest OS to manage the PF. The best Nova can do is inform the guest, via the metadata, of what parameters (VLAN in this case) it needs to set on the PF. Bug [1] notwithstanding, this is what Vladik has implemented. Your comment #15 is not a workaround, it is the actual solution. If you would like cloud-init integration for the VLAN tag exposed in the device metadata, that would be a different RFE. Is there anything that I'm missing or not understanding, based on this paragraph?

Cheers!

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1532683
[2] https://review.openstack.org/#/c/533805/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1402583

*** This bug has been marked as a duplicate of bug 1402583 ***

Comment 20 Eran Kuris 2018-05-06 06:12:15 UTC
(In reply to Artom Lifshitz from comment #19)
> Hi Eran,
> 
> There are a couple things going on here.
> 
> The original PF vlan tagging work has a bug [1] where "hostdev" devices in
> the instance XML aren't considered for device metadata, preventing the vlan
> tag from being exposed to the guest in the metadata. A fix [2] is in
> progress.
> 
> That being said, I don't see how this bugzilla is different from the
> original RFE that Vladik has implemented [3]. Once as PF is passed through
> to the guest, the host loses all control over it, and it is up to the guest
> OS to manage the PF. The best Nova can do is inform the guest, via the
> metadata, of what parameters (VLAN in this case) it needs to set on the PF.
> Bug [1] notwithstanding, this is what Vladik has implemented. Your comment
> #15 is not a workaround, it is the actual solution. If you would like
> cloud-init integration for the VLAN tag exposed in the device metadata, that
> would be a different RFE. Is there anything that I'm missing or not
> understanding, based on this paragraph?
> 
> Cheers!
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1532683
> [2] https://review.openstack.org/#/c/533805/
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1402583
> 
> *** This bug has been marked as a duplicate of bug 1402583 ***

Nope Artom you did not miss anything. Thanks for your explanation.


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