Bug 1478865
| Summary: | Unable to define a vlan over a nic with a long name (exceeds iface max name length) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Mor <mkalfon> | ||||
| Component: | Core | Assignee: | Edward Haas <edwardh> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mor <mkalfon> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.19.26 | CC: | bgraveno, bugs, danken, edwardh, mburman, mkalfon, myakove | ||||
| Target Milestone: | ovirt-4.1.6 | Keywords: | Automation | ||||
| Target Release: | --- | Flags: | rule-engine:
ovirt-4.1+
rule-engine: ovirt-4.2+ |
||||
| Hardware: | ppc64le | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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 10:02:14 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Mor
2017-08-07 11:12:09 UTC
Created attachment 1310024 [details]
vdsm supervdsm and engine logs
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 * I forgot to add one additional step before applying the changes: - Set MTU with value 5000 on the network. 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? (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. 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. Please consider closing this BZ, we have nothing to fix. 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. Mor, please test the suggested workaround. (In reply to Dan Kenigsberg from comment #9) > Mor, please test the suggested workaround. Maybe I missed it, what is exactly the suggested workaround? Sorry, I missed the doc text. The workaround (described in the doc text) is acceptable. Red Hat Virtualization Manager Version: 4.1.6-0.1.el7 *** Bug 1540991 has been marked as a duplicate of this bug. *** |