折腾虚拟机的人十个里有八个都被“ping不通”折磨过。我自己属于那种“装系统半小时配网络一下午”的人踩过的坑包括VMnet8感叹号、netplan缩进错误、防火墙偷偷把ICMP拦了、ssh端口没监听到……现在回想起来大部分问题其实都有固定的排查套路只是刚接触的人不知道从哪里下手。这篇文章不讲抽象概念直接从最常见的三个场景开始虚拟机ping不通宿主机、虚拟机ping不通网关、虚拟机ping不通外网。我会把每种情况的判断思路、排查命令、修改方法写清楚也会重点讲VMware Workstation里NAT、桥接、仅主机这三种模式容易埋的几个雷。如果你正在被虚拟机网络折腾按这个顺序走一遍大概率能解决。1. 先搞清楚虚拟机的三种网络模式再谈排障很多人一上来就改IP、关防火墙折腾半天还是不通原因就是没搞清楚虚拟机到底工作在哪种网络模式下。网络模式决定了虚拟机的数据包应该往哪个方向走、网关应该填什么。这一步不确认后面所有操作都是在盲人摸象。1.1 NAT模式的原理与常见误区NAT模式是VMware Workstation默认的网络模式对应的是虚拟网卡VMnet8。它的工作方式比较巧妙虚拟机不直接连入物理局域网而是由宿主机上的VMware NAT Service做一层地址转换把虚拟机的流量转成宿主机物理网卡发出的流量。对虚拟机来说宿主机就像一个“路由器”虚拟机的网关地址通常就是VMnet8的IP比如192.168.88.1。这个模式最大的好处是省心——宿主机能上网虚拟机基本也能上网不需要关心物理局域网里有没有DHCP、有没有IP-MAC绑定之类的问题。但这不代表NAT模式下就不会ping不通。我最常遇到的情况有两种。第一种虚拟机里拿到的是169.254.x.x这样的地址这表示没有从DHCP拿到有效IP一般是VMware DHCP Service停了或者VMnet8这张虚拟网卡本身异常。第二种虚拟机里手动配的静态IP和NAT网段对不上——比如VMnet8的网段是192.168.88.0/24而你在虚拟机里配的是192.168.1.10网关配了192.168.1.1那数据包从虚拟机出来以后根本找不到对应的网关自然就“Destination Host Unreachable”了。在VirtualBox里也有类似的结构只是虚拟网卡默认叫vboxnet0而且VirtualBox默认的“NAT网络”和“仅主机网络”是两个不同概念。很多人把VirtualBox的“仅主机”当成“能上网的NAT”来用结果发现ping不通外网还以为是自己配置有问题其实只是模式本身不支持出网。所以排障之前一定要先确认当前虚拟机到底用的哪个模式这一步能省掉大量无用功。1.2 桥接模式虚拟机直接“插”在局域网里桥接模式的原理是让虚拟机直接以一个“独立主机”的身份出现在物理局域网里虚拟机的网卡流量通过VMware的桥接协议直接走上物理交换机相当于虚拟机和宿主机是局域网里的两台机器。这种模式的优点是虚拟机拥有一个和物理局域网同网段的真实IP别人访问虚拟机非常方便缺点是它对物理网络环境有依赖。如果物理网络有DHCP虚拟机可以从DHCP获取IP如果没有DHCP或者网管开了交换机的端口安全、IP-MAC绑定那虚拟机就拿不到合法IP表现就是ping不通网关、ping不通外网。我在桥接模式下踩得最深的坑是笔记本同时连着Wi-Fi和有线网选桥接模式时VMware会问“桥接到哪块物理网卡”如果选错了桥接到有线网卡而实际流量是从Wi-Fi走的那虚拟机的数据包虽然发出去了却到不了真实网络怎么ping都不通。所以在选择桥接的“目标网卡”时必须先看清楚宿主机当前上网用的是哪块网卡——在Windows下用ipconfig查看默认路由对应的接口通常那个“默认网关”所在的网卡就是你该桥接的目标。还有一点也要注意桥接模式下虚拟机里的默认网关必须填物理路由器的地址比如192.168.1.1而不是VMnet8的地址。如果虚拟机还是沿用之前NAT模式的网关往外发的数据包目标地址都无法匹配同样ping不通。很多人从NAT切换到桥接之后忘记改网关就是一个看似简单的错误。1.3 仅主机模式只适合做私有网络测试仅主机模式Host-Only对应VMware里的VMnet1VirtualBox里的“仅主机网络”也是类似设计。宿主机和虚拟机之间建立了一个封闭的虚拟局域网宿主机可以通过虚拟网卡访问虚拟机但虚拟机不能访问宿主机之外的世界。这个模式适合做实验环境比如测试多个虚拟机之间的通信、或者宿主机和某个特定虚拟机之间的服务联调但不要指望它能提供外网访问。在仅主机模式下ping不通百度完全正常不是故障。我遇到过不少人在这个上面钻牛角尖改了一天的IP、路由、防火墙最后才发现设计上就不让出网。排障之前先看一眼模式真的能避免很多无用功。如果你需要外网访问就老老实实切回NAT或桥接模式。2. ping不通的时候先分清“哪条链路”断了“ping不通”听起来是同一句话实际上方向不同、原因也大不相同。很多人进到虚拟机里一通敲却忘了确认自己是要测“宿主机到虚拟机”还是“虚拟机到宿主机”还是“虚拟机到外网”。不同方向排查的侧重点完全不一样。2.1 宿主机ping虚拟机失败和虚拟机ping宿主机失败可能不是同一个原因宿主机ping虚拟机失败先看宿主机的虚拟网卡是否正常、IP是否和虚拟机在同一网段。比如NAT模式下宿主机的VMnet8是192.168.88.1虚拟机是192.168.88.128两者在同一网段才能ping通。如果VMnet8不可用比如被安全软件禁用了宿主机根本没有通往192.168.88.0/24的路由ping自然不通。而虚拟机ping宿主机失败通常是虚拟机内部的问题网卡没有UP、IP没配好、默认网关错误或者防火墙挡了入站ICMP。有时候宿主机ping不通虚拟机就是因为宿主机的防火墙拦了ICMP这种情况在Windows 10/11上尤其常见。我建议你在动手改配置之前先画一个简单的“链路图”宿主机 → 虚拟网卡 → 虚拟交换机 → 虚拟机网卡 → 虚拟机内的协议栈。每一跳都有可能断排查是一层一层来的直接改IP属于瞎猜。我见过太多人一上来就把IP改成静态结果越改越乱最后连DHCP分配的地址都没了。2.2 虚拟机ping不通网关问题多半出在虚拟机内部网关是虚拟机的“出口”。如果连出口都ping不通那问题基本就限定在虚拟机自己和虚拟交换机的范围内。首先检查网卡的IP和网关是否同段不同段数据包就发不出去。其次检查网卡状态Linux下执行ip link show如果状态显示为DOWN或者NO-CARRIER就要检查VMware里虚拟机的“已连接”选项有没有打开。在VMware里还出现过一种情况虚拟机的网卡模式选了“自定义特定虚拟网络”但下拉框里选的网络根本不是它期望的那个等于流量跑到另一条马路上了这时候需要在虚拟网络编辑器里重新指定。除了这些还要注意NAT模式下的“网关”本质上是VMware NAT Service虚拟出来的不是真实路由器。如果你在虚拟机里错误地把网关写成了宿主机的物理网卡IP比如192.168.1.2那虚拟机发出的包就没有谁来做NAT转换表现同样是不通。所以要千万记住NAT模式的网关就是VMnet8的IP不是你物理网卡的IP。2.3 虚拟机ping不通外网把网络层和DNS分开来看虚拟机能够ping通网关说明内部链路没问题问题在网关到外网这一段。可以按这个顺序递进测试先ping网关确认内部链路正常。再ping一个公网IP比如223.5.5.5测试NAT和出网链路。最后ping一个域名比如www.baidu.com测试DNS解析。如果ping公网IP能通、ping域名不能通那就是DNS配置的问题检查/etc/resolv.conf或netplan里的nameservers。如果ping公网IP都不通那就检查NAT服务是否正常、防火墙是否拦了出方向的流量。还有一种比较隐蔽的情况虚拟机里有多个网卡比如同时有NAT网卡和桥接网卡导致路由表出现了多条默认路由数据包走了错误的那条网络表现为“时好时坏”。遇到这种情况我会把无关网卡直接禁用只保留一条网卡通路再重新测试。3. 按顺序排查的完整链路虚拟网卡、IP、路由、防火墙如果方向已经分清还是找不到问题那就要进入“地毯式排查”。我的习惯是固定按这个顺序走宿主机的虚拟网卡和DHCP服务 → 虚拟机内的IP/掩码/网关 → 路由表 → 防火墙。这个顺序是从底层往上走的每一层都有对应命令可以验证。3.1 网络连接窗口里的虚拟网卡和DHCP服务是否正常先看Windows宿主机的“网络连接”窗口找到VMnet1和VMnet8。如果图标上有个黄色感叹号或者状态显示“无Internet访问”可以先怀疑虚拟网卡驱动或VMware服务出了问题。打开运行窗口输入services.msc在服务列表里找到VMware DHCP Service和VMware NAT Service看它们是否在运行。我遇到很多次这两个服务被优化软件或手动禁用后虚拟机拿不到IP自然就ping不通。VirtualBox也有类似的机制只是服务名不同如果网卡驱动被禁用虚拟机网卡会直接无法工作。这里有一个容易忽略的点如果宿主机上一次休眠或者重启之后虚拟网卡状态变成“已禁用”那虚拟机里的网卡状态也会跟着变但虚拟机系统内部可能不会立刻提示。所以在宿主机上把虚拟网卡“禁用再启用”一次是成本最低的恢复操作值得先试。3.2 虚拟机内的IP、掩码、网关是不是配错了在Linux里执行ip addr看网卡有没有拿到IP执行ip route看默认路由写的什么。常见错误是手动配IP的时候把掩码写成了24位但实际网段是16位结果网关不在同一个子网内数据包到了内核层就直接判定为不可达。举个例子VMware的NAT模式默认网段是192.168.88.0/24VMnet8的IP通常是192.168.88.1那虚拟机里的网关就必须填192.168.88.1如果填成其他网段流量根本发不出去。还有人会犯一个迷糊把网关填成了路由器的管理地址比如192.168.1.1但虚拟机的IP是192.168.88.128。这俩都不在一个子网里怎么可能通所以每改一个参数都要回头看一眼和网段是否匹配。我在排查时经常会整理一个小表格把网卡名、IP、掩码、网关、DNS五项列出来一项一项对照能避免不少低级失误。3.3 路由表里有没有默认路由用route -n或ip route查看。如果没有default条目那虚拟机不知道该把去外网的数据包往哪发。手动添加默认路由的命令是route add default gw 192.168.xxx.1 dev eth0但注意这只是临时生效重启后清空。此外也不要忽略多路由冲突的问题——如果虚拟机里存在两张网卡、两条默认路由可能会导致包走向错误。这种情况下我会先禁用一张网卡只保留一条默认路由再重新测试。有个地方要特别说明某些Linux发行版默认会把网卡管理交给NetworkManager如果你手动改了ifcfg文件但NetworkManager没有重新加载它可能会在后台把配置改回去。所以检查路由表之前先确认当前究竟是哪个网络管理服务在“管事”否则你看到的route输出可能和配置文件里的内容完全不一样。3.4 防火墙是不是把ICMP协议给拦了防火墙是最常见的“元凶”因为它表现得很隐蔽——IP配好了、路由也正常但就是ping不通。在Windows Server虚拟机上默认的“文件和打印机共享(回显请求-ICMPv4-In)”规则通常是关闭的某些精简版系统或安全软件也会禁用ICMP。在Linux上iptables和firewalld是主要拦截点。排查时可以先用iptables -L -n看看INPUT链有没有DROP规则快速测试则用iptables -I INPUT -p icmp -j ACCEPT加一条规则。CentOS 7/8里临时放行ICMP可以用firewall-cmd --add-protocolicmpUbuntu的ufw默认是放行icmp的但如果曾改过规则可以用ufw status verbose查看状态。有时候问题不在虚拟机而在宿主机——Windows宿主机自带的防火墙也可能拦掉来自虚拟网卡的ICMP请求。如果你发现虚拟机ping不同宿主机但宿主机ping虚拟机却正常那多半是宿主的入站规则拦了ICMP需要到“高级安全Windows Defender防火墙”里启用“文件和打印机共享(回显请求-ICMPv4-In)”规则。这个细节非常容易漏因为大多数人只盯着虚拟机里的防火墙看。4. VMware Workstation里的网络配置实操与避坑前面讲了通用排查思路这一节专门针对VMware Workstation讲几个高频坑。毕竟很多人用的就是VMware而这些坑我在实际使用中反复遇到过几乎每个都是“看一眼就能解决但没人告诉你”的类型。4.1 虚拟网络编辑器是排查的第一站打开VMware Workstation菜单里的“编辑→虚拟网络编辑器”看到VMnet8对应的NAT设置里面会显示子网IP和子网掩码右下角的“NAT设置”按钮还能看到网关IP。这个地方就是所有网段的源头也是排查链路的第一步。一定要清楚记得你的虚拟机用的是什么模式、对应哪个VMnet。如果一台虚拟机从NAT模式改成桥接模式但是忘记修改虚拟机里的IP和网关那就会出现“IP明明配置了但是ping不通”——因为网段已经和环境不匹配了。虚拟网络编辑器里还可以看到每块虚拟网卡对应的网络比如VMnet0通常用来做桥接VMnet1是仅主机VMnet8是NAT。如果你发现VMnet8的子网IP不是常见的192.168.x.0而是被其他程序改过的网段一定要以这里的实际值为准再去配置虚拟机内的IP。很多人拿网上下载的教程里的IP段直接套用结果自己的VMnet8网段已经被改成别的了怎么配都不通。4.2 改了虚拟机的网络模式后虚拟机系统内部也要跟着改切换网络模式不是点一下“桥接”或“NAT”就完事。比如你从NAT切到桥接虚拟机里的IP地址必须改成局域网里的可用IP网关改成路由器地址。不做这个调整就算虚拟网卡显示已连接虚拟机也上不了网。Linux里改完网卡配置后要重启网络服务或重新加载配置Ubuntu是netplan applyCentOS 7是systemctl restart network或者nmcli connection reload。如果还是不通就把网卡先down再up有时候不重启系统也能生效。有一个操作细节值得强调在VMware里切换网卡模式时最好把虚拟机的电源状态先关掉或者至少在虚拟机设置里重新选择一次“设备状态”的“已连接”勾选框。极少数情况下热切换网卡模式会导致虚拟机内部网卡一直停留在旧的工作状态让你误以为配置写错了折腾半天才发现重启一下虚拟机就好了。4.3 VMnet1/VMnet8网卡出现感叹号的处理Windows的“网络连接”窗口里VMnet1或VMnet8上出现黄色感叹号是很多人遇到的第一道关卡。感叹号不一定代表网卡坏了更多时候是网卡驱动里的“Internet连接共享”或组策略冲突。我处理这类问题一般是右键网卡→属性→IPv4手动指定一个IP例如VMnet8改成192.168.88.1然后禁用再启用这张网卡。如果还不行把VMware的网络相关的Windows服务全部设为自动包括VMware NAT Service和VMware DHCP Service然后重启系统。这招在大多数感叹号场景下都有效。还有一种情况是虚拟网卡“未识别网络”Windows会认为你这张网卡没有正常接入互联网然后自动打上感叹号。其实对虚拟化来说“未识别网络”不代表不能工作只要VMnet8和虚拟机的IP在同一网段通信照样可以进行。所以看到感叹号先别慌用命令行ping一下能通则说明网络是通的感叹号不影响使用。真正要处理的是“无法访问默认网关”或者“IP地址冲突”这类提示。5. Linux系统里网络配置文件的正确改法市面上的教程五花八门有的是改/etc/network/interfaces有的是改/etc/sysconfig/network-scripts还有的说用nmcli。新手遇到这些很容易晕。但不同发行版的默认管理工具确实不同必须对症下药。这一节我把最主流的两个发行版分开讲清楚。5.1 Ubuntu用netplan别再去改interfaces在Ubuntu 20.04之后网络配置默认用netplan配置文件通常在/etc/netplan/目录下文件名一般是01-network-manager-all.yaml或00-installer-config.yaml。我见过很多人直接去编辑/etc/network/interfaces结果发现改了没用因为那已经是老掉牙的教程了。这里给出一个NAT模式下的netplan示例network: version: 2 ethernets: ens33: dhcp4: true dhcp6: false如果是手动设置静态IP要这样写network: version: 2 ethernets: ens33: addresses: - 192.168.88.128/24 routes: - to: default via: 192.168.88.1 nameservers: addresses: - 223.5.5.5 - 114.114.114.114注意yaml文件的缩进非常严格空格不能乱写错一个缩进netplan apply会直接报错。我建议写完后先执行sudo netplan try如果配置有问题会在超时后自动回滚比直接apply再发现连不上安全得多。尤其当你是通过SSH远程操作虚拟机时netplan apply失败可能导致连接断开所以利用try这个回滚机制很重要。5.2 CentOS 7的NetworkManager与network服务之争CentOS 7的网卡配置文件在/etc/sysconfig/network-scripts/ifcfg-ens33网卡名不固定。关键字段是BOOTPROTOstatic或dhcp、ONBOOTyes、IPADDR、NETMASK、GATEWAY、DNS1。很多人配好之后执行systemctl restart network发现还是不生效原因往往是NetworkManager和network服务在抢这张网卡的管理权。如果你在配置里写了NM_CONTROLLEDno之后用network服务行为最可控——我在VMware里跑CentOS习惯关掉NetworkManager统一用network服务排障要可靠得多。如果你更习惯用NetworkManager那就别再去改ifcfg文件直接用nmcli命令。比如nmcli connection modify ens33 ipv4.addresses 192.168.88.128/24 ipv4.gateway 192.168.88.1 ipv4.method manual然后nmcli connection up ens33让它生效。最怕的就是两边都改、两边都没生效结果路由表里出现一堆奇怪条目。5.3 重启网络服务的“正确姿势”不同发行版重启网络服务的方式不一样CentOS 7用systemctl restart networkCentOS 8开始NetworkManager大一统用nmcli connection reload或nmcli connection up ens33Ubuntu用netplan applyDebian用systemctl restart networking。另外改完配置后不要急着看结果等几秒稳定一下再ping——我遇到过好几次虚拟机的网络服务还没完全启动完毕立刻执行ping显示“Network is unreachable”过几秒再试就通了。这里需要一点耐心不要对着刚重启的网络服务反复改配置。还有一个技巧在Linux虚拟机里改完网络配置之后可以用ip addr和ip route两个命令分别确认IP和路由是否生效。只要这两个输出符合预期基本就说明系统层面的配置没问题接下来再去查外部链路。这个“先验证系统内、再验证系统外”的顺序能帮你快速缩小问题范围。6. ping通了但Xshell连不上问题出在哪网络问题有时候不只是ping不通还有一种更让人挠头的ping能通但Xshell就是连不上。这个问题常见于刚装好Linux虚拟机、想用SSH远程登录的场景。很多人在这里耗了很久其实本质是混淆了“网络层通”和“应用层通”的概念。6.1 先确认sshd在运行、端口在监听Xshell建立的是SSH连接默认端口22。如果ping通但连接被拒绝第一反应应该是ssh服务有没有装、有没有起来。在Ubuntu里查看服务状态用sudo systemctl status ssh没安装就sudo apt install openssh-server。在CentOS里用sudo systemctl status sshd。另外确认sshd在监听ss -tlnp | grep :22如果只有127.0.0.1:22这一行说明sshd只绑定了回环地址外部连不上需要去/etc/ssh/sshd_config里找到ListenAddress改成0.0.0.0并重启服务。有些云镜像或精简系统默认禁止root直接登录或者根本没装sshd这两种情况都很常见。装好系统后第一件事先执行systemctl status ssh如果显示active再执行ss -tlnp看端口这两步过了SSH连接的成功率就有七八成了。6.2 “拒绝连接”和“超时”是两种不同的问题Xshell报“Connection refused”说明目标主机端口没开或防火墙拒绝了连接报“Connection timed out”说明数据包根本没到目标主机或半路被丢弃报“Connection reset by peer”则可能是ssh版本不匹配或安全软件干预。我在排查时一般遵循这样的顺序本地先ping通本地测试端口telnet ip 22在虚拟机内ss -tlnp看监听检查防火墙规则查看/var/log/auth.log或/var/log/secure里的sshd日志。这一套走下来基本能锁定问题。记住ping通了只代表网络层通不代表应用层SSH就一定能通这是两码事。关于防火墙在CentOS 7上如果firewalld开着光放行ICMP还不够还要放行ssh服务firewall-cmd --add-servicessh --permanent firewall-cmd --reload。Ubuntu如果开了ufw要执行ufw allow ssh。很多人只加了ICMP放行规则结果SSH端口还是被挡着Xshell当然连不上。6.3 账号、密码和密钥认证的坑用Xshell连接虚拟机时账号密码正确却一直认证失败可能是sshd配置里的PasswordAuthentication no被改过了。还有一种情况你配置了公钥认证但~/.ssh目录权限不对比如权限是777sshd会拒绝读取公钥文件导致登录失败。更隐蔽的是root用户登录时PermitRootLogin被设成prohibit-password只允许密钥登录这时即使密码输对了也会被拒。碰到这种情况要么用其他账号登录要么在虚拟机本机编辑/etc/ssh/sshd_config把PermitRootLogin改成yes再重启sshd。权限方面的要求是用户家目录不能对其他用户开放写权限.ssh目录最好是700authorized_keys文件最好是600。这个权限要求在很多教程里不会写但实际踩坑率极高。我在一次帮同事排查时发现他花了半小时在改防火墙结果只是公钥文件权限变成了644sshd直接忽略了那个文件换成密码登录也不行因为PasswordAuthentication也是no完全把自己锁在了门外。7. 其他平台场景Windows虚拟机、Hyper-V和PVE的补充经验说完了VMware和Linux再补几个其他平台的高频场景。虽然核心排障思路一样但不同平台确实有一些特有的坑提前知道能省很多事。7.1 Windows虚拟机里的网卡感叹号和“网络电缆被拔出”Windows虚拟机经常遇到两种现象一是任务栏网络图标显示感叹号二是网卡状态提示“网络电缆被拔出”。后者在VMware里通常是因为虚拟网卡没有连接——需要在虚拟机设置里把设备状态的“已连接”和“启动时连接”都勾上也可能是虚拟交换机服务没启动。在Hyper-V里如果没给虚拟机分配虚拟交换机虚拟机网卡会直接显示断开。如果你是在Windows 7虚拟机里装VMware Tools还需要注意网卡驱动是不是正确安装了有些精简版系统省略了对VMware虚拟网卡的驱动支持。处理“感叹号”时先别急着重装网卡驱动。在Windows虚拟机里执行ipconfig /all看看是不是拿到了有效的IP地址。如果拿到的是169.254开头的自动专用地址说明网卡是通着的但DHCP没分配成功重点应该去查虚拟交换机或者DHCP服务。如果ipconfig里干脆没有网卡或显示“媒体已断开”再考虑虚拟机设置里的连接选项和驱动问题。7.2 Hyper-V的虚拟交换机与WSL2网络Hyper-V和VMware不一样它支持三种虚拟交换机外部、内部、专用。外部交换机相当于VMware的桥接内部交换机类似仅主机模式但宿主机还能访问虚拟机专用交换机则宿主机都不访问。Hyper-V最容易踩的坑是选了“内部”或“专用”后宿主机侧的vEthernet网卡没配好IP导致虚拟机连宿主机都ping不通。解决方法是去“控制面板→网络和共享中心→更改适配器设置”找到对应的vEthernet网卡手动配一个固定IP比如192.168.100.1再把虚拟机的IP配到同一网段网关填192.168.100.1。至于WSL2它使用的是一种虚拟NAT网络常驻一个叫“vEthernet (WSL)”的虚拟网卡。如果你发现WSL2里网络异常比如ping不通外网可以先在Windows侧执行wsl --shutdown再重新打开WSL这能重置虚拟交换机。如果还不行就打开“网络适配器”设置把vEthernet (WSL)禁用再启用。另一种更少见的情况是电脑固件里没有开启虚拟化支持WSL2启动的时候会直接报“此计算机上未启用虚拟化”这种就只能进BIOS把Intel VT-x或AMD-V打开。7.3 PVE桥接配置的经验小结PVEProxmox VE网络配置主要在/etc/network/interfaces文件里常用的是Linux bridge比如vmbr0。虚拟机通过vmbr0接入物理网络宿主机IP也绑在vmbr0上。如果虚拟机ping不通外网第一个要确认的就是bridge_ports里填的是哪块物理网卡如果填错或没填虚拟机就不会有真正的外网链路。另一个常见问题是在PVE里给虚拟机配置网络时选用了virtio模型而老系统比如Windows 7没有自带virtio驱动网卡会显示为未识别设备自然无法配置IP。解决方法是先在虚拟机里装好virtio驱动或者临时改用e1000网卡模型把系统跑起来。我自己的习惯是每次改完网络配置都会在宿主机和虚拟机里各ping一次把结果记录下来再继续下一步。这种笨办法在排查多虚拟机网络的时候尤其管用比如三台虚拟机互相不通如果你不记录每一步的测试结果很容易来回改配置把自己绕晕。记住排障的核心不是靠运气而是靠“分层验证”模式、网卡、IP、路由、防火墙每一层都确认无误问题自然就浮出水面了。