Hide Forgot
Description of problem: I was trying to configure alias and vlan interfaces on rhel7 host using static subnet. Host was provisioned successfully, but none of the interfaces configured. I checked the interface configs are found that device names were incorrect. Alias interface config file named ike: /etc/sysconfig/network-scripts/ifcfg-_0 [root@sghai ~][root@sghai ~]# cat /etc/sysconfig/network-scripts/ifcfg-_0 | grep DEVICE DEVICE=:0 vlan inteface config file named as: /etc/sysconfig/network-scripts/ifcfg-.1 [root@sghai ~]# cat /etc/sysconfig/network-scripts/ifcfg-.1 | grep DEVICE DEVICE=.1 Version-Release number of selected component (if applicable): sat6.2 beta snap4 How reproducible: always Steps to Reproduce: 1. configure alias and vlan interfaces on rhel7 2. 3. Actual results: incorrect device names in alias and interface config files Expected results: Device names sould be correct Additional info:
Moving to POST since upstream bug http://projects.theforeman.org/issues/13000 has been closed ------------- Marek Hulán Applied in changeset commit:community-templates|673a05b33c3efcb2db4bf29306a7086a22f5e43f.
Verified with sat6.2 beta snap6.2 when we provision a host by adding a alias interface, host provisioned successfully but with incorrect alias interface name: [root@alias network-scripts]# cat ifcfg-_0 BOOTPROTO="none" IPADDR="192.168.100.120" NETMASK="255.255.255.248" DEVICE=:0 ONBOOT=yes PEERDNS=no PEERROUTES=no TYPE=Alias however, if I rebuild the same host then interface comes up correctly: [root@alias network-scripts]# cat ifcfg-eth0_0 BOOTPROTO="none" IPADDR="192.168.100.120" NETMASK="255.255.255.248" DEVICE=eth0:0 ONBOOT=yes PEERDNS=no PEERROUTES=no TYPE=Alias [root@alias network-scripts]# ifconfig -bash: ifconfig: command not found [root@alias network-scripts]# ifconfig -a -bash: ifconfig: command not found [root@alias network-scripts]# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:aa:2b:04 brd ff:ff:ff:ff:ff:ff inet 192.168.100.5/24 brd 192.168.100.255 scope global dynamic eth0 valid_lft 43094sec preferred_lft 43094sec inet 192.168.100.120/29 brd 192.168.100.127 scope global eth0:0 valid_lft forever preferred_lft forever inet6 fe80::5054:ff:feaa:2b04/64 scope link valid_lft forever preferred_lft forever
same issue with rhel6 host. [root@aliasrhel6 network-scripts]# ll | grep ifcfg- -rw-r--r--. 1 root root 125 Apr 7 10:00 ifcfg-_0 -rw-r--r--. 1 root root 94 Apr 7 10:00 ifcfg-eth0 -rw-r--r--. 1 root root 254 Apr 9 2015 ifcfg-lo [root@aliasrhel6 network-scripts]# cat ifcfg-_0 BOOTPROTO="none" IPADDR="192.168.100.121" NETMASK="255.255.255.248" DEVICE=:0 ONBOOT=yes PEERDNS=no PEERROUTES=no TYPE=Alias [root@aliasrhel6 network-scripts]#
Okay, Marek and I worked together to find the root cause of issue. Thanks Marek for your help. Finally, we got to know that user needs to specify the identifier for first interface. when we provision a virtual host from satellite6, webUI doesn't set the identifier for first interface. However, when we create alias of first interface, we need to specified the identifier under "attached_to" otherwise, alias interface won't be configured and it fails silently. However, UI should raise a validation error for alias interface, if user forget to set the identifier for first interface. I'll file a new bz.
By mistake, closed this bz. Moving this back to ON_QA so that I can move it to verified state it.
As per comment10, original issue has been fixed. Moving this to verified. I can create virtual interfaces on rhel6 and rhel7 host. Please see the screenshots for verification.
Created attachment 1145922 [details] virtual interface configuration on rhel6 host
Created attachment 1145923 [details] virtual interface configuration on rhel7 host
For validation error issue mentioned in comment10, filed this bz: https://bugzilla.redhat.com/show_bug.cgi?id=1325777
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:1500