Hide Forgot
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:
Vladik am I correct to understand that this is a Nova RFE and not a Neutron bug?
(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
Removing this from being a blocker of BZ #1325686. This should be treated as a separate RFE.
(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 ?
(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.
This issue is not a duplicate of bug 1402583. It different issue.
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.
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
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
(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.
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 ***
(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.