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,
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. ***