OVA虚拟机部署后网络不通，绝大多数情况下是网卡驱动未加载、网卡命名规则变化、或虚拟网络类型不匹配造成的，按“驱动→网卡名→IP配置→虚拟交换机”的顺序排查基本都能解决。
这个问题我处理过不下几十次,每次都是同样的套路，OVA本身是个打包好的虚拟机模板，它把磁盘数据、硬件配置和OVF描述文件绑在一起，导出的环境跟新环境不一样，网络自然容易出岔子，下面就把排查路径一步步拆开讲清楚。
ova导入后网卡不识别？先查驱动和硬件环境
网卡类型变了，驱动根本不认
OVA封装的时候记录的是源平台的网卡类型,比如你在VMware Workstation里导出的OVA，网卡通常是e1000或vmxnet3，部署到vCenter或ESXi上以后，如果模板描述文件里写死的网卡类型跟目标宿主机支持的驱动不匹配，系统起来以后ip a里什么都看不到。
行业内比较常见的做法是先在esxi的虚拟机配置里把网卡类型改成E1000再开机试一次，很多OVF模板默认标注的是“灵活网卡”，但实际生效的却是e1000，另一种情况是网卡显示vmxnet3，但系统里没装对应的驱动。
查看当前系统识别的网卡状态,用这个命令：
lspci | grep -i ethernet dmesg | grep -i eth
如果能看到硬件但看不到接口,说明驱动没挂上，这时需要手动加载：
modprobe vmxnet3
加载成功后再看ip link，如果接口出现了但名字变成了ens192或ens224，别慌，这是正常的，后面改配置就行。
udev规则锁死了旧网卡名
这个坑很多人踩过,OVA在源环境里生成的udev规则或者/etc/udev/rules.d/70-persistent-net.rules里记录了原MAC地址和网卡名的对应关系，目标机器的MAC地址变了，系统就把新网卡当作“未知设备”，不给它分配eth0的名字。
结果就是你进系统后,发现网卡叫ens256或者干脆是enp0s3但没有IP，这个问题的排查方式很简单，看udev规则文件里面记录的MAC地址跟现状是否一致：
cat /etc/udev/rules.d/70-persistent-net.rules
发现不一致的情况下,删除这个文件再重启，CentOS 7以上的系统建议同时清掉/etc/sysconfig/network-scripts/ifcfg-eth0里的HWADDR和UUID字段，否则NetworkManager还是会认死旧配置。
虚拟机网络不通怎么排查？从这四个层面下手
第一层：检查虚拟交换机端口组
部署在ESXi上的OVA,如果选择的端口组是VLAN隔离的，而源环境用的是VLAN 0，那么IP通了但网关不通。ESXi的虚拟交换机分为标准交换机和分布式交换机两种，后者如果端口组没配置正确，网络直接处于“假死”状态。
进去vSphere Client，点击宿主机 → 配置 → 网络，看虚拟适配器上挂的端口组是不是有流量标识，如果端口组有问题，虚拟机控制台里ping网关会提示Destination Host Unreachable，而ping同网段其他机器可能通也可能不通。
第二层：核对虚拟机的IP配置模式
OVA模板里常常封装了静态IP,而且这个IP往往还带着源环境的痕迹，比如之前的网段是192.168.1.0/24，部署到10.0.0.0/24的环境里，起不来自然正常。
修改静态IP的路径在每类系统里不一样：
- Linux（CentOS/RHEL）：编辑
/etc/sysconfig/network-scripts/ifcfg-ens192，改掉IPADDR和GATEWAY - Linux（Ubuntu 18.04+）：修改
/etc/netplan/01-netcfg.yaml或类似文件 - Windows Server：直接在图形界面里改IPv4属性
改完之后第一时间重启网络服务,别急着重启整台虚拟机，Netplan的系统执行netplan apply，NetworkManager的系统执行systemctl restart NetworkManager。
第三层：查看网关和路由表
有一种特殊情况是IP配置没问题,网卡驱动也正常，但路由表是空的，OVA打包时带的静态路由在新环境下行不通，系统起来后默认路由没有自动生成。
检查方法：
ip route show
如果没有任何default via的行，手动加一下：
ip route add default via 网关IP dev ens192
这只是临时验证,确认通了之后还是要写进配置文件里，否则重启后又丢掉，那才叫折腾人。
第四层：安全组和防火墙策略
云平台上部署的OVA,经常遇到“能ping通但ssh连不上”的情况，这不是系统层面的问题，而是安全组规则把22端口挡了。行业共识认为，部署私有云或公有云镜像时，安全组的排查应该排在防火墙前面，因为安全组挡住的流量根本到不了虚拟机内部。
本地防火墙方面,查看iptables或firewalld是否放行了需要的端口：
systemctl status firewalld iptables -L -n
esxi导入ova网络不通，这几个地方最容易出问题
网卡类型从e1000变成了vmxnet3的兼容性之争
越新的ESXi版本越倾向于默认挂载vmxnet3网卡,vmxnet3性能好，但需要系统里有对应驱动，Windows Server 2008 R2这种老系统导入到ESXi 8.0上，如果没有手动安装VMware Tools，vmxnet3驱动十有八九是缺失的。
处理办法：把网卡临时改成e1000e或者e1000，先把网络搞通，进入系统装好VMware Tools，再关机改回vmxnet3，我这个顺序前后反了，改完网卡类型之后网络直接丢，刚好验证了前面的判断驱动确实没有。
网络配置文件里的旧MAC地址是隐形杀手
/etc/sysconfig/network-scripts/ifcfg-eth0里如果有HWADDR=00:0C:29:AA:BB:CC这一行，而实际虚拟机的MAC是00:50:56:8A:9D:2E，那NetworkManager会直接忽略这个配置文件，这种坑跟udev规则是双胞胎兄弟，经常同时出现。
还有一部分OVA封装系统里自带了/etc/hosts绑定，改了IP后hosts里还是旧地址，会导致内部服务互相访问异常，现象是网络通但业务不通，这种问题很多运维人员排查半天最后发现是hosts文件在捣鬼。
部署分布式交换机之后端口组ID不连续
在vDS（分布式交换机）环境下，OVA导入时如果选择的端口组跟标准交换机混用，vCenter可能会分配一个不连续的端口ID。此时虚拟机的网络连接在界面上显示“已连接”，但实际数据包根本发不出去。
在vSphere客户端的虚拟机编辑设置里,把网络适配器移掉，再重新添加一次，选择正确的分布式端口组，绝大多数情况下能恢复。
如何确认OVA内部的网络配置再决定怎么改
导入OVA之前,想提前知道这个镜像封装的网络情况，可以解包看OVF文件，用tar解压ova：
tar -xvf 你的镜像.ova
里面会有一个.ovf格式的文本文件，用文本编辑器打开，搜索Network关键词，能看到类似这样的一段：
<Network ovf:name="VM Network">
这个name就是模板创建者在打包时指定的网络名称,如果源环境里这个网络叫“VM Network”，而你的ESXi里没有这个名字，导入后vCenter会自动映射到默认端口组，网络不通也就不意外了，这时候回到“虚拟交换机端口组”那一步去调整即可。
云平台之间互导OVA的特殊处理方式
从简米云导出镜像再导入OpenStack,或者从VMware导出再导入KVM虚拟化平台，这属于跨虚拟化平台迁移，OVA内部的网卡驱动和总线类型很可能完全不兼容。
这种情况下,需要提前给虚拟机注入virtio驱动（针对KVM）或xen-net-front驱动（针对Xen），否则导入后系统起来根本看不到网卡，有些平台允许在导入时选择磁盘总线类型，把默认的SCSI改称IDE，至少能保证系统先启动，之后再补驱动。
跨平台迁移导致的网络不通,跟同一平台内的问题处理思路完全不同，前者重点在驱动层，后者重点在配置层，判断标准就一句话：dmesg | grep -i firmware如果报错，那是驱动缺失；没有报错只是没有IP，那是配置问题。
ova网络不通常见问题解答
ova导入后能ping通内网，但ping不通网关，问题出在哪？
网关不回应,多数原因是端口组VLAN设置不对，虚拟机发出的数据帧带上了错误的VLAN标签，交换机直接丢弃，检查ESXi端口组的VLAN ID是否跟物理交换机上配置的trunk一致，同时确认虚拟机的网卡没有在客户机操作系统里手动设置了VLAN ID（vconfig命令的结果）。
虚拟机重启后ip还是之前配置的静态地址，怎么改成dhcp？
修改网卡配置文件,把BOOTPROTO从none或static改成dhcp，删掉IPADDR、NETMASK、GATEWAY几行，然后释放旧地址重新获取：
dhclient -r ens192 dhclient ens192
如果有NetworkManager管理,直接nmcli con mod eth0 ipv4.method auto然后重启连接，改完以后确认/etc/resolv.conf里的DNS是不是也被刷新了，有些模板会在resolv.conf里写死老DNS地址，需要一并处理。
ova部署的虚拟机网卡是down的状态，怎么应对？
先排除硬件开关问题,ESXi里看虚拟机的连接状态是否勾选了“已连接”和“打开电源时连接”，然后是系统层面，执行ip link set ens192 up手动拉起接口，如果拉起后立刻又down掉，大概率是网卡驱动和硬件之间有冲突，检查dmesg中是否有Link is down的反复提示，补装对应驱动可以解决绝大多数此类问题。
网络问题的排查本质上是耐心活儿,OVA导入后网络不通，九成情况不怪虚拟化平台本身，而是封装时的配置残留和驱动差异在捣乱，按网卡驱动、接口命名、IP配置、交换机端口组这条链路走一遍，大部分问题都能在半小时内定位。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/624853.html
