twt运营
作者twt运营2016-11-25 09:17
软件开发工程师, twt

CentOS7网卡命名中碰到的一个坑

字数 1525阅读 15536评论 0赞 1

以下内容转自公众号:云技术实践(ID:kvm_virt)

环境描述:

碰到CentOS7命名机制的问题缘于测试cloudstack4.5.1版本,架构为管理节点采用cloudstack的4.5.1_EL6版本,计算节点采用cloudstack4.5.1_EL7版本(EL7系统下默认的tomcat版本为7.0.54,管理节点安装完成以后检查的tomcat配置文件为tomcat6的配置文件报错而无法启动cloudstack-mgmt服务),计算服务器采用Thinkserver RD640,总共3块网卡,一块cloudbr0作为mgmt流量与默认的storage流量入交换机管理VLAN的access口,一块cloudbr1作为public与guest流量入交换机trunk口,1块用于监控管理本机入交换机监控VLAN口。

CentOS7下默认的识别的网卡设备名称为“enpxxxx”,依据原生的centos7系统识别的设备名称做cloudbr0与cloudbr1桥接是没问题的,但是将其加入到cloudstack管理平台中,日志里会一直报错“can not find cloudbr1”,究其原因是因为cloudstack无法识别网桥下的子接口enpxxxx”,所以需要将centos7下原生识别的网卡名称改为熟悉的EL5、6下大家熟悉的ethX才能继续测试工作。

测试一:通过net.ifnames=0与biosdevname=0参数进行改名,/etc/sysconfig/grub配置文件对内核参数进行传递,截图如下:

改完配置参数以后,通过“grub2-mkconfig -o /boot/grub2/grub.cfg”进行更新重启,重启以后网卡设备名称都改变为ethX,但是有个奇怪的现象:设备对应的mac地址竟然跟centos7默认识别的网卡的mac地址没有对应起来,eth0的mac地址先前的el7系统识别的enpxxf0的mac地址相同,但是eth1的mac地址与先前el7系统识别的enpxxf1设备mac地址不同,而是与用于监控的那块网卡的mac地址进行了对调,给相应的网卡设备配置文件做了配置以后,eth1设备的状态始终是“NO-CARRIER....DOWN”状态,eth2设备状态是正常的,初步怀疑可能是有些参数配置错误导致的现象或者重新生成的设备跟/etc/udev/rule.d/下的规则文件中的mac地址需要对应起来;

测试二:通过测试一中的方法更改网卡设备名称,检查所有配置文件,eth1设备与enpf1设备mac地址依然与原生的el7系统识别到的设备mac地址无法一一对应起来,手动添加70-persistent-net.rules文件,文件中指定ethX设备名称与现有的mac地址对应,然后重启服务器,截图如下:

重启以后eth1的状态依然是“NO-CARRIER....DOWN”,eth0与eth2的状态一直是UP,一直是正常的,于是怀疑到可能需要BIOS设置调整eth2与eth1的关系;

测试三:开机F1进入bios,对监控网卡进行调整,截图如下:

之前BMC网卡是shared模式,改成专用dedicated模式,然后重新安装EL7系统,更改网卡设备名称,进行桥接cloudbr0与cloudbr1,加入cloudstack管理平台,创建实例正常,测试完毕!

总结:

EL7系统中,systemd和udevd不同的命名方案,但是默认是根据固件信息、拓扑及位置信息名称分配,这与EL6系统机制不同,本次测试环境中又恰好遇到BMC网卡模式为shared模式,所以才会触发到这个坑,希望以后有同样使用场景的兄弟们不要踩到此坑!

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广