Bug 1478865 - Unable to define a vlan over a nic with a long name (exceeds iface max name length)
Unable to define a vlan over a nic with a long name (exceeds iface max name l...
Status: CLOSED CURRENTRELEASE
Product: vdsm
Classification: oVirt
Component: Core (Show other bugs)
4.19.26
ppc64le Unspecified
medium Severity medium (vote)
: ovirt-4.1.6
: ---
Assigned To: Edward Haas
Mor
: Automation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-07 07:12 EDT by Mor
Modified: 2017-09-20 19:23 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
On Red Hat Enterprise Linux, consistent network device naming [1] is used to generate consistent names for network devices. On some systems, the generated name is too long, limiting automated tail additions to be applied (the classic example is to create a VLAN interface over such an interface). In cases where the long-name interface is used as a base of a VLAN, the total VLAN interface name may exceed the kernel name limit (15). As a result, the creation of the vlan fails. For example, len(<base-name> + 1(for the dot) + len<vlan-id> + 1 <= 15 The simplest workaround is to disable the new name mechanism. Alternatively, add a static udev rule to manipulate the name of the interfaces: ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:50:56:8e:12:34", NAME="eth123" [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-19 06:02:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1+
rule-engine: ovirt‑4.2+


Attachments (Terms of Use)
vdsm supervdsm and engine logs (1.68 MB, application/octet-stream)
2017-08-07 07:14 EDT, Mor
no flags Details

  None (edit)
Description Mor 2017-08-07 07:12:09 EDT
Description of problem:
On a PPC (PowerPC) based environment, SetupNetwork fails to apply attachment of VM network with VLAN and MTU 5000 on host.

Version-Release number of selected component (if applicable):
Red Hat Virtualization Manager Version: 4.1.5.1-0.1.el7

How reproducible:
Not always reproducible.

Steps to Reproduce:
1. Create VM network with VLAN tag (e.g. 137).
2. Attach the network to PPC arch host interface.
3. Apply the changes.

Actual results:
VDSM the target hosts fails. SetupNetworks error: 'IOError: [Errno 8] Bad socket.'

Additional info:
Engine.log: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to HostSetupNetworksVDS, error = [Errno 8] Bad socket,
Comment 1 Mor 2017-08-07 07:14 EDT
Created attachment 1310024 [details]
vdsm supervdsm and engine logs
Comment 2 Mor 2017-08-07 07:19:16 EDT
installed packages:
vdsm-hook-ethtool-options-4.19.26-1.el7ev.noarch
vdsm-hook-vmfex-dev-4.19.26-1.el7ev.noarch
vdsm-python-4.19.26-1.el7ev.noarch
vdsm-yajsonrpc-4.19.26-1.el7ev.noarch
vdsm-xmlrpc-4.19.26-1.el7ev.noarch
vdsm-4.19.26-1.el7ev.ppc64le
vdsm-api-4.19.26-1.el7ev.noarch
vdsm-jsonrpc-4.19.26-1.el7ev.noarch
vdsm-cli-4.19.26-1.el7ev.noarch
Comment 3 Mor 2017-08-07 07:21:10 EDT
* I forgot to add one additional step before applying the changes:
- Set MTU with value 5000 on the network.
Comment 4 Edward Haas 2017-08-09 05:24:09 EDT
I see this in the log:
MainProcess|jsonrpc/4::DEBUG::2017-08-07 04:03:53,804::commands::69::root::(execCmd) /usr/bin/taskset --cpu-list 0-127 /usr/bin/systemd-run --scope --unit=6e18f65f-6cae-4dc9-a23f-7a47a58683dc --slice=vdsm-dhclient /sbin/ifup enP2p1s0f4d1.137 (cwd None)
MainProcess|jsonrpc/4::DEBUG::2017-08-07 04:03:53,860::commands::93::root::(execCmd) FAILED: <err> = 'Running scope as unit 6e18f65f-6cae-4dc9-a23f-7a47a58683dc.scope.\nError: argument "enP2p1s0f4d1.137" is wrong: "name" too long\n\n'; <rc> = 1


How is it possible that this is not always reproducible?
If it worked until now, what changed? Is it a change in VDSM or in the initscripts?
Comment 5 Mor 2017-08-09 06:15:54 EDT
(In reply to Edward Haas from comment #4)
> I see this in the log:
> MainProcess|jsonrpc/4::DEBUG::2017-08-07
> 04:03:53,804::commands::69::root::(execCmd) /usr/bin/taskset --cpu-list
> 0-127 /usr/bin/systemd-run --scope
> --unit=6e18f65f-6cae-4dc9-a23f-7a47a58683dc --slice=vdsm-dhclient /sbin/ifup
> enP2p1s0f4d1.137 (cwd None)
> MainProcess|jsonrpc/4::DEBUG::2017-08-07
> 04:03:53,860::commands::93::root::(execCmd) FAILED: <err> = 'Running scope
> as unit 6e18f65f-6cae-4dc9-a23f-7a47a58683dc.scope.\nError: argument
> "enP2p1s0f4d1.137" is wrong: "name" too long\n\n'; <rc> = 1
> 
> 
> How is it possible that this is not always reproducible?
> If it worked until now, what changed? Is it a change in VDSM or in the
> initscripts?

Maybe the hosts were changed in the env, and the interface names changed as a result.
Comment 6 Edward Haas 2017-08-09 07:53:09 EDT
This is a kernel limitation on the name:
<base interface name> + '.' + <vlan id (1 to 4095)>

Cannot pass 16 chars.

I find it strange that a generated interface name is so long in the first place.
Comment 7 Edward Haas 2017-08-09 07:54:07 EDT
Please consider closing this BZ, we have nothing to fix.
Comment 8 Dan Kenigsberg 2017-08-16 06:39:32 EDT
Please add here a udev rule example to rename an extremely long interface name.

At the moment, all we can do is a release note warning that iface_name + vlan_id must be shorter than 14.
Comment 9 Dan Kenigsberg 2017-08-27 19:05:15 EDT
Mor, please test the suggested workaround.
Comment 10 Mor 2017-08-28 03:41:00 EDT
(In reply to Dan Kenigsberg from comment #9)
> Mor, please test the suggested workaround.

Maybe I missed it, what is exactly the suggested workaround?
Comment 11 Mor 2017-08-28 03:42:03 EDT
Sorry, I missed the doc text.
Comment 12 Mor 2017-08-29 09:34:17 EDT
The workaround (described in the doc text) is acceptable.

Red Hat Virtualization Manager Version: 4.1.6-0.1.el7

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