Bug 1478865 - Unable to define a vlan over a nic with a long name (exceeds iface max name length) [NEEDINFO]
Unable to define a vlan over a nic with a long name (exceeds iface max name l...
Status: NEW
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-08-16 06:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
danken: needinfo? (edwardh)
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.

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