虚拟化环境下的CentOS7网络环境存在的问题

本文涉及的产品
云解析 DNS,旗舰版 1个月
云解析DNS,个人版 1个月
全局流量管理 GTM,标准版 1个月
简介:
+关注继续查看

为什么要进行一次测试?

在使用CentOS7的过程中发现网络部分有很多与CentOS6所不同的地方。

1.CentOS7默认使用NetworkManager管理系统的网络而不再是network

2.NetworkManager默认使用的是nmtui或nmcli进行管理,不再是sysconfig中的ifcfg配置文件,但这些ifcfg文件依然被支持

3.默认NetworkManager和network同时在系统中工作,但NetworkManager要先于network启动

4.实际使用过程中发现即使在ifcfg配置文件中使用了静态IP地址以及静态DNS,在NetworkManager中依然使用自动获取(DHCP)的方式,自动获取IP地址和DNS服务器地址

5.NetworkManager默认使用ip命令来配置网络而不是ifcfgxxx,ip命令配置的网络重启后失效

测试环境:

测试虚拟化环境:VMware ESXi 5.1.0

操作系统:CentOS7.0(1406-x86_64),采用最小化安装(默认即是NetworkManager管理网络服务)

网络环境:多vlan的网络环境、其中一vlan设有DHCP服务

测试结果:

  1. VMware VMXNET3 Ethernet Controller对应的网卡是ens160, VMware E1000 Ethernet Controller对应的网卡名称为ens32,CentOS7默认不支持VMXNET2,如果采用VMXNET3,则网卡编号为ens160、ens192和ens224,如果采用E1000则网卡编号为ens32、ens33、ens34。

  2. 如果在安装操作系统时在网络连接步骤中设定的是静态IP地址,则在ifcfg的配置文件中将会将IPADDR、PREFIX、GATEWAY的后面加一个0表示,并且将BOOTPROTO的值设为none,如果绑定一个公网IP地址的话将后面的数字将上加。

  3. ifcfg文件中默认使用“NAME=”而不是“DEVICE=”,ifup和ifdown这两个命令都是使用的是“DEVICE=”,测试过程中发现并不需要将ifcfg文件中默认使用的“NAME=”换成“DEVICE=”,network服务照样可以启动,但只有BOOTPROTO的值为none而不是dhcp时,nmcli中ipv4.method的值才是manual。

  4. 手动修改ifcfg文件不能触发NetworkManager应用这些变更,需要使用nmcli connection reload,或者使用systemctl restart NetworkManager.service,例如ifcfg中将BOOTPROTO从dhcp改为static,需要注意的是nmcli connection reload并不能代替systemctl restart NetworkManager.service,因为nmcli中的任何更改在save persistent之后将对ifcfg文件进行修改,但nmcli中的修改在系统中不会立刻生效,依然需要systemctl restart NetworkManager.service,此时通过ip a命令发现原先修改前的配置和修改后的配置都会留在系统中。

  5. 如果将NetworkManager禁用掉,那么nmcli、nmtui等命令将不再可用。

  6. nmcli中的结果集可能会叠加,例如IP地址或DNS服务器地址可能存在多个,remove只能删除一个配置属性但不能删除整个结果集。

  7. 偶然遇到NetworkManager中的连接名称不是网卡名称的情况,可以用nmcli手动更改。

测试总结:

NetworkManager不如network使用起来方便和不出错,因此在不明就里之前建议谨慎使用NetworkManager。

tips:

在配置服务器时尽可能按照如下提示进行配置,以免除NetworkManager 所带来的麻烦和困扰

  1. 在安装操作系统时将网络配置好,打算采用动态IP就使用dhcp,打算采用静态IP地址就手动设置,提前设定好DNS服务器地址,或将DNS地址写进文件并设定好计划任务或者开机自动更新配置

  2. 尽可能的将DHCP关掉,特别是需要静态IP地址的服务器不要使用DHCP来获取哪些可能没有使用的地址,以免遇到上述测试结果中遇到的nmcli的结果集存在重复的情况

  3. 将NetworkManager禁用掉使用network,并不需要将ifcfg文件中默认使用的“NAME=”换成“DEVICE=”,network服务照样可以启动,网络在ifcfg配置文件配置正确的情况下依然可用,由于systemctl与services的不同,systemctl status network时将显示此服务中命令行的运行状态,例如network调用的是/etc/rc.d/init.d/network start,正确情况下此命令会返回代码为0并退出,这并不意味着network服务已经停止,用户只需要关心此状态中是否是绿色的active即可。




本文转自 urey_pp 51CTO博客,原文链接:http://blog.51cto.com/dgd2010/1592821,如需转载请自行联系原作者

相关文章
|
3月前
|
负载均衡 安全 虚拟化
另一种虚拟化平台-NSX DC如何实现Openstack网络与安全
最近这两个月,工作强度陡然提升。前不久为了归纳和总结NSX DC分别与HOST-VM容器和裸金属容器的最佳实践和“特殊部署”,已经起早贪黑了两个多礼拜。因此,公众号的更新频率有所下降。好在功夫不负有心人,届时我也会推出专门的篇幅来介绍云原生场景的技术实现。 在今天的分享中,我将继续上一篇的内容,向大家展示管理员通过Openstack Horizon或者命令行执行配置的时候,NSX DC后端究竟发生了什么变化。
另一种虚拟化平台-NSX DC如何实现Openstack网络与安全
|
6月前
|
KVM 虚拟化 Windows
【KVM虚拟化】· KVM中的网络
【KVM虚拟化】· KVM中的网络
|
SDN 虚拟化
开源创新、软件定义网络和网络功能虚拟化特性
开源创新、软件定义网络和网络功能虚拟化特性
274 0
开源创新、软件定义网络和网络功能虚拟化特性
|
存储 负载均衡 安全
云数据中心引入网络功能虚拟化NFV
网络功能的虚拟化正在改变大型数据中心的网络现状。服务器和桌面虚拟化,云计算和移动设备的集成使得数据中心网络的网络负担日益加重。
134 0
云数据中心引入网络功能虚拟化NFV
|
安全 网络协议 API
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.6
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.6
|
缓存 Oracle 网络协议
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.5
《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.5
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.5
|
负载均衡 定位技术 SDN
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.4(二)
《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.4
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.4(二)
|
缓存 资源调度 网络协议
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.4(一)
《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.4
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.4(一)
|
存储 网络安全 Apache
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.3(四)
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.3
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.3(四)
|
安全 网络安全 SDN
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.3(三)
《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.3(三)
带你读《软件定义网络之旅:构建更智能、更快速、更灵活的未来网络》第三章网络功能虚拟化3.3(三)
相关产品
云迁移中心
推荐文章
更多