VMware中SUSE 10虚拟机网络配置与排错指南

在虚拟化平台上跑老系统，网络这一关卡住的人比想象中多得多。VMware 里装一台 SUSE Linux 10 的虚拟机，系统装完，ifconfig只给你一个lo；好不容易看到网卡，名字变成eth1；照着网上的教程改完ifcfg-eth0，重启网络又被打回原形；桥接模式宿主机能上网虚拟机不行，NAT 模式反过来又拿不到地址。这些症状我见过太多次，它们的根因往往不在某一步操作写错，而在于 SUSE 10 这套系统和当下虚拟化平台的"年代差"没被正视。这篇就围绕"VMware 中配置 SUSE 10 虚拟机网络"这个具体场景，把网卡型号选型、配置文件写法、udev 命名规则、路由与 DNS 的配合、故障定位顺序一次讲透，给出可以直接抄的配置和一套能复用的排查路径。适合正在维护老旧 Linux 虚拟机、需要在隔离环境里复现十年前业务系统的运维和实施同学，也适合刚接触虚拟化、被网卡命名规则绕晕的新手。

1. 先把问题想明白：SUSE 10 的网络为什么在 VMware 里格外难缠

1.1 时间差：内核 2.6.16 与当前虚拟硬件的代沟

SUSE Linux Enterprise Server 10 的内核基线是 2.6.16，即便打到最后一个服务包，也仍然停留在 2.6.16.x 这条线上。这个内核出生的年代，VMware 的半虚拟化网卡vmxnet3还没有进主线，vmxnet3驱动大规模合入是 2.6.25 之后的事情。这意味着你在虚拟机硬件设置里如果顺手选了"VMXNET 3"，系统装完之后很可能连网卡设备都枚举不出来，lspci里看不到、dmesg里也没有任何以太网控制器的记录。很多人第一反应是"VMware 坏了"或者"系统装失败了"，其实是虚拟硬件和客户机内核之间根本没有握手成功。

除了驱动，还有一整套配置体系的年代差。今天的 Linux 发行版网络配置基本交给了 NetworkManager，nmcli一把梭；SUSE 10 用的是纯sysconfig体系，配置文件躺在/etc/sysconfig/network/目录下，靠ifup/ifdown和rcnetwork脚本驱动。网卡的持久化命名也不是大家熟悉的/etc/udev/rules.d/70-persistent-net.rules，而是 SUSE 自己的一套30-net_persistent_names.rules。你在网上搜到的绝大多数"Linux 改网卡名"的教程，对这台机器都是无效的，照抄只会越改越乱。

再说工具层面。SUSE 10 里的ifconfig、route、netstat都还在，iproute2也有，但没有ss的常用习惯、没有nmcli、systemctl更是完全不存在，服务管理走的是/etc/init.d/加chkconfig。所以当你在别的机器上习惯性敲出systemctl restart network的时候，SUSE 10 只会给你一句 command not found。把这些前提摆清楚，后面的每一步操作才有依据，不然就是在盲改。

1.2 三种网络模式怎么选：桥接、NAT、仅主机的取舍逻辑

VMware Workstation 提供三种主要联网方式，选哪一种不是个人偏好问题，而是由这台虚拟机要承担的角色决定的。我在实际项目里通常按下面这张表来判断：

判断逻辑很直接：这台机器要不要被局域网里别的设备访问？要，就桥接。只是自己用、要装软件包、要连外网，就 NAT。多个虚拟机之间要组一个封闭的小集群、不碰外网，就仅主机。这里有个容易被忽略的细节：桥接模式下虚拟机的 MAC 地址会直接暴露在物理网络上，如果办公网做了端口安全或者 MAC 准入，虚拟机是拿不到地址的，表现为"网卡是通的，但 DHCP 永远超时"，这时候换 NAT 是最省事的解法，而不是去和网络管理员扯皮。

还有一个选择依据是 IP 规划的可控性。NAT 模式下 VMnet8 的子网完全由你在"虚拟网络编辑器"里定义，不受办公网段影响，改起来不会牵连别人；桥接模式下你的 IP 必须和物理网段保持一致，一旦物理网络调整，虚拟机跟着全部要改。老系统往往一次配好就长期不动，我倾向于把它放在 NAT 后面，减少后期维护的变量。

1.3 动手之前必须确认的五件事

很多人上来就开虚拟机改配置，改到一半发现方向错了，回滚又没快照，最后只能重装。我现在的习惯是先花五分钟确认五个前提，这五分钟能省下后面两小时。

第一，确认虚拟网卡型号。打开虚拟机的.vmx配置文件或者虚拟机的"设置 - 网络适配器 - 高级"，看用的是e1000、vmxnet3还是vlance。这个信息决定了系统里能不能看到网卡。

第二，确认 MAC 地址。不管是ifcfg-eth0还是按 MAC 命名的配置文件，MAC 都是绑定关系里的关键字段。把虚拟机的 MAC 抄下来，改配置的时候随时对照。

第三，确认 IP 规划。网段、掩码、网关、DNS 四个值先写在纸上或者记事本里。NAT 模式下如果打算用静态地址，必须落在 VMnet8 的子网内，而且不能和 DHCP 池重叠。

第四，确认防火墙状态。SUSE 10 默认会装上SuSEfirewall2，外部区域默认策略可能挡住你用来验证的 ICMP 或某些端口，导致"配置明明对但就是不通"。

第五，确认手边有控制台通道。VMware 的控制台是你改网络时的安全带，rcnetwork restart一下 SSH 就断的情况太常见了，别指望通过 SSH 远程改完再远程验证。

提示：这五件事里如果有任何一项拿不准，先给虚拟机打一个快照再动手。网络配置错误的排查成本远高于回滚成本。

2. 虚拟机侧的准备工作：网卡型号与虚拟硬件参数

2.1 网卡型号选型：e1000 是这台机器上最省心的答案

在 SUSE 10 上做网络配置，网卡型号的选择几乎决定了后面一半的工作量。三种常见型号里，vlance（AMD PCnet32）最老、性能最差，但兼容性最好；vmxnet是 VMware 的半虚拟化驱动，需要装 VMware Tools 才有，性能不错但老版本驱动在 2.6.16 内核上偶有丢包和协商异常；vmxnet3性能最好，可惜这个内核根本认不出来；e1000是模拟 Intel 82545EM 千兆网卡，驱动e1000是 2.6.16 内核自带的，加载即成，不需要装任何额外组件。

选型的判断依据其实就三条：内核有没有驱动、需不需要额外装东西、性能是否够用。对一台复现老业务系统的虚拟机来说，网络吞吐从来不是瓶颈，稳定加载和可预期行为才是。所以我基本固定用e1000。如果你在虚拟机设置界面看到"网络适配器 - 高级 - 虚拟设备"里有多个选项，选e1000对应的那个即可；如果虚拟机已经创建好并且系统也装了，改型号需要关机后到.vmx里改，或者删掉网卡重新加一块。

有个坑要提前说：新版本的 VMware 创建虚拟机时，默认往往给vmxnet3，而且在你选客户机操作系统为"其他 Linux 2.6.x 内核"时也不会自动降级。装完系统发现没网卡，别急着查系统，先去虚拟机设置里把型号换掉，往往一步解决。换完型号后，系统里原来那块网卡对应的配置文件和 udev 规则可能还留着，记得一并清理，否则新网卡会以eth1的身份出现。

2.2.vmx文件里的关键参数与改动姿势

.vmx是虚拟机的描述文件，纯文本，所有虚拟硬件参数都在里面。和网络相关的几行通常是这样的：

ethernet0.present = "TRUE" ethernet0.connectionType = "nat" ethernet0.networkName = "VMnet8" ethernet0.virtualDev = "e1000" ethernet0.addressType = "generated" ethernet0.generatedAddress = "00:0c:29:1a:2b:3c"

virtualDev控制网卡型号，connectionType控制联网模式，networkName指定用的是哪个虚拟网络。要改这几行，必须先把虚拟机关机，然后在 VMware 完全退出的情况下编辑，否则图形界面退出时会用内存里的状态把文件覆盖回去，你改的内容就白改了。改完之后重新打开虚拟机，进设置界面确认一下型号是否已生效，再开机。

另一个容易被忽略的参数是ethernet0.addressType。设成generated时 MAC 由 VMware 自动生成，设成static时用address字段里写死的值。做模板或者需要固定 MAC 绑定的场景，用static更可控，但要注意同一个网络里不能出现重复的 MAC。改 MAC 相当于换了块网卡，系统里的 udev 规则会认为这是新硬件，网卡名随之变化，这一步和下一小节说的问题是同一件事。

2.3 克隆与复制带来的 MAC 变化，是最隐蔽的一个坑

虚拟机做完一台当模板，克隆出第二台，开机之后发现ifconfig里只有eth1，没有eth0，原来的 IP 配置也全都不生效。这不是配置丢了，而是 SUSE 10 的持久化命名机制在起作用：系统记录了"MAC 地址 A 对应接口名 eth0"，克隆出来的机器 MAC 变成了 B，系统找不到 A 对应的设备，于是把新设备按顺序命名为eth1，而ifcfg-eth0仍然绑在旧的 MAC 和旧接口上，自然起不来。

这个机制本身是合理的，它保证多网卡的机器重启后网卡名不会乱跳。问题出在克隆场景下它变成了阻碍。处理思路有两条：一是"清理派"，克隆完成后进系统把 udev 规则和相关配置文件全部清掉，让系统重新认一遍；二是"顺应派"，不清理，直接把新网卡名eth1的配置写出来。前者干净，适合做批量模板；后者快，适合临时用一下就扔的机器。我一般选清理派，因为模板机器如果带着旧 MAC 的规则到处克隆，后面每一台都要单独处理，成本会累积。

清理动作不复杂，但要清干净。除了 udev 规则文件，/etc/sysconfig/network/下形如ifcfg-eth-id-00:0c:29:xx:xx:xx的文件也要删掉，这类文件名里带着 MAC，是 SUSE 早期的绑卡方式，留着会和新配置打架。清理完重启，系统会用新 MAC 重新生成eth0的规则。

3. SUSE 10 系统内网络配置的完整实操

3.1 第一步永远是确认系统认没认到网卡

配置之前先做诊断，别急着写文件。按顺序敲下面几条命令，基本能判断出问题出在哪一层：

lspci | grep -i ethernet hwinfo --netcard dmesg | grep -i -E "eth|e1000" lsmod | grep e1000 ifconfig -a ip link show

lspci能看到以太网控制器，说明虚拟硬件在 PCI 层面被识别了，问题不大；如果lspci里什么都没有，说明网卡型号选错或者虚拟机根本没加网卡，回虚拟机设置里改。hwinfo --netcard是 SUSE 上的利器，它会把网卡的 PCI ID、驱动模块、MAC 地址、链路状态一次性列出来，比lspci信息更全。dmesg里找e1000相关的行，能看到驱动初始化和链路协商的过程，如果是e1000: eth0: e1000_probe: ...这样的记录，说明驱动加载成功。

ifconfig -a里的-a很关键，不加-a只会显示已经 up 的接口，一块没配置的网卡是看不到的，很多人就是在这里误判成"系统没认到网卡"。如果ifconfig -a里出现了eth0但没有 IP，那恭喜，这已经是最好处理的情况，直接进配置环节就行。

3.2 写ifcfg-eth0：SUSE 的配置文件和别家不一样

SUSE 10 的网络配置文件放在/etc/sysconfig/network/下，一块网卡一个文件，文件名就是接口名。一个典型的静态配置长这样：

# /etc/sysconfig/network/ifcfg-eth0 BOOTPROTO='static' IPADDR='192.168.137.20' NETMASK='255.255.255.0' BROADCAST='192.168.137.255' NETWORK='192.168.137.0' STARTMODE='auto' USERCONTROL='no' MTU='1500'

逐行说一下为什么这么写。BOOTPROTO取static或dhcp，静态地址必须显式写static，不写的话在某些补丁版本上会被当成未配置。IPADDR、NETMASK、BROADCAST、NETWORK是一组，后两个严格来说可以省略，系统能算出来，但写上去的好处是配置文件本身就是一份完整的网络规划文档，别人接手一眼就懂，排查时也能快速发现"广播地址和掩码对不上"这类低级错误。也可以把NETMASK换成PREFIXLEN='24'，两种写法等价，看你习惯。

STARTMODE='auto'表示开机自动启用这块网卡，另外两个可选值是manual（需要手动ifup）和hotplug（热插拔时启用）。老系统上经常有人写成manual，然后抱怨开机没网，其实配置本身没错，只是没让它自动起。USERCONTROL='no'这一行值得单独说：它表示这块网卡不接受用户态工具（比如早期的一些图形化网络管理组件）的接管，避免出现"你改完文件，某个后台服务又把配置改回去"的诡异现象。在没有 NetworkManager 的环境里，写上它更稳。

注意：SUSE 的 ifcfg 文件用的是单引号，这个细节不影响功能，但保持一致能避免和其他工具生成的配置混在一起时出现格式争议。

如果你的目录下同时存在ifcfg-eth0和ifcfg-eth-id-00:0c:29:xx:xx:xx两个文件，SUSE 的ifup会优先采用按 MAC 命名的那个。这是很多人改了ifcfg-eth0却不生效的真正原因。处理办法很简单：只保留一个。要么把按 MAC 命名的删掉，要么把它重命名成ifcfg-eth0。我在 SLES 10 上反复验证过这个优先级，删掉多余文件后配置立刻生效。

3.3 默认路由、DNS 与 hosts 三件套的配合

网卡配好只是有了地址，能不能出网还得看路由和 DNS。SUSE 10 的默认网关不写在ifcfg-eth0里，而是写在/etc/sysconfig/network/routes：

# /etc/sysconfig/network/routes default 192.168.137.2 - -

三个字段分别是目的网络、网关、掩码，最后那个短横线是占位。写default表示默认路由。如果机器有多块网卡、需要按接口区分路由，可以用/etc/sysconfig/network/ifroute-eth0这种按接口命名的文件，格式一样，但只在这块网卡启用时生效。单网卡场景用全局的routes就够。

DNS 配在/etc/resolv.conf：

nameserver 192.168.137.2 nameserver 192.168.137.3 search example.local

这里有个 SUSE 特有的机制要提醒：系统里有个netconfig组件，在网络服务重启时会根据/etc/sysconfig/network/config里的策略重新生成resolv.conf。如果你手写的内容在rcnetwork restart之后被覆盖了，就是它在起作用。要么把 DNS 配置写进/etc/sysconfig/network/config的对应字段里让它统一管理，要么调整那个策略开关让它别管。不同服务包版本上这个开关的默认值不完全一样，遇到被覆盖的情况先去翻这个文件，别怀疑自己写错了。

/etc/hosts在老系统上建议顺手补上本机记录，很多依赖主机名解析的组件（包括一些数据库和中间件）在启动时会反查本机名，hosts里没有对应条目会拖慢启动甚至报错：

127.0.0.1 localhost 192.168.137.20 suse10-node1

3.4 用 YaST 图形化配置：省事，但要知道它改了什么

不想手写文件的话，SUSE 10 自带 YaST，在终端里执行yast lan或者yast2 lan就能进入网卡配置界面。流程是选中网卡、点编辑、填 IP 和掩码、切到"路由"页填网关、切到"主机名/DNS"页填 DNS，一路确定下去。它对新手友好，字段校验也做得不错，掩码和网关不在同网段时会提示。

但我建议即使全程用 YaST，事后也要用cat把生成的配置文件看一遍。原因有两个：一是 YaST 在某些版本上会生成按 MAC 命名的ifcfg-eth-id-*文件而不是ifcfg-eth0，你按接口名去找会找不到，误以为没写进去；二是 YaST 会同时维护 udev 规则，克隆场景下这些规则会跟着跑，需要手动清理。知道它改了什么，出问题时才有排查方向。

另外 YaST 的防火墙模块也顺手一起看。执行yast firewall可以查看当前区域和开放的服务。如果只是做内部实验，把防火墙临时停掉验证连通性是可以的，但验证完记得恢复，别让一台裸奔的机器长期挂在网络上。

3.5 启停与验证：按层次一步步确认

配置写完后不要直接重启整台机器，先用服务脚本重启网络：

rcnetwork restart # 或者 /etc/init.d/network restart

单块网卡可以用ifup eth0和ifdown eth0单独操作。这里有个实操细节：如果你是通过 SSH 连上去的，ifdown eth0执行的瞬间连接就断了，后续的ifup根本执行不到，机器就处于断网状态。所以改网络时要么在 VMware 控制台里操作，要么写成一条命令ifdown eth0; ifup eth0一起执行，别分成两次。

验证要按从近到远的顺序，一层层排除：

ifconfig eth0 # 看地址、掩码、UP 标志、收发包计数 ethtool eth0 # 看 Link detected 是否为 yes route -n # 看默认路由是否在 ping -c 4 192.168.137.2 # 先 ping 网关 ping -c 4 192.168.137.1 # 再 ping 同网段其他机器 ping -c 4 114.114.114.114 # 有外网需求再 ping 外部地址 ping -c 4 www.example.com # 最后验证 DNS

ethtool eth0里的Link detected: yes是物理层通不通的直接证据。如果这里是no，说明虚拟网卡和虚拟交换机之间没连上，问题在 VMware 侧，不在系统里，检查虚拟机设置里"已连接"和"启动时连接"两个复选框是不是都勾了。如果Link detected是yes但 ping 网关不通，往路由、IP 网段、防火墙方向查。如果 ping 得通 IP 但域名不行，问题一定在 DNS。

4. 常见问题与排查技巧实录

4.1 网卡变成 eth1、eth2：出现频率最高的一类问题

现象是ifconfig -a里只有eth1，没有eth0，而/etc/sysconfig/network/下的配置文件叫ifcfg-eth0，于是配置不生效。根因在 udev 的持久化命名规则：系统按 MAC 记录接口名的映射，MAC 变了就分配新名字。

SUSE 10 上这个规则文件在/etc/udev/rules.d/30-net_persistent_names.rules，内容形如：

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0c:29:1a:2b:3c", IMPORT="/lib/udev/rename_netiface %k eth0"

处理方式有三种，按场景选：

我偏向第二种。清理完重启，系统会用当前 MAC 重新生成规则，网卡稳稳回到eth0，配置文件不用动。执行前记得把/etc/sysconfig/network/下所有带eth-id的文件列一遍，用ls -l看清楚再删，别把有用的配置一起清了。

4.2 只有 lo：网卡根本没被系统枚举

比网卡改名更麻烦的是压根看不到以太网接口。判断路径是：lspci | grep -i ethernet有没有输出。

有输出但ifconfig -a里没有eth*，说明驱动没加载。先modprobe e1000手动加载试试，然后dmesg | tail -30看有没有报错。如果手动加载后网卡出现了，说明是模块没有开机自动加载，需要在/etc/modprobe.conf.d/目录下建一个配置文件写入alias eth0 e1000，让它持久化。这个目录是 SUSE 的模块配置习惯，和很多发行版用的单文件/etc/modprobe.conf不同，别找错地方。

lspci里完全没有以太网控制器，那基本可以判定是虚拟机硬件层面的问题：网卡型号选了内核不支持的（比如vmxnet3），或者虚拟机根本没有添加网络适配器。回到虚拟机设置里换成e1000再开机，问题通常当场消失。

还有一种少见情况：lspci有设备、驱动也加载了、dmesg里却报e1000: ... Hardware Error之类。这多半是虚拟机文件层面出了问题，重建一块网卡比继续排查划算。

4.3 IP 通了但域名不通：DNS 链路上的三个断点

ping 8.8.8.8能通、ping www.example.com报unknown host，说明 IP 层没问题，问题在名称解析。按顺序查三处。

第一处，cat /etc/resolv.conf，看nameserver那几行在不在、地址对不对。见过不少情况是这个文件被清空了，或者指向了一个已经下线的 DNS 服务器。第二处，确认 DNS 服务器本身可达：ping一下那个地址，或者用nslookup www.example.com 192.168.137.2指定服务器查询，能出结果说明服务器没问题，是本地配置的事。第三处，检查resolv.conf是不是被netconfig覆盖了——表现是每次rcnetwork restart之后内容又变回原样。这时候要去/etc/sysconfig/network/config里找 DNS 相关的策略配置项，统一在那边维护。

还有一个隐蔽的坑：/etc/nsswitch.conf里hosts那一行的顺序。如果是hosts: files dns，会先查/etc/hosts，如果hosts文件里有一条错误记录（比如把某域名指到了 127.0.0.1），查询就会命中错误结果，看起来像 DNS 坏了。排查时用getent hosts 域名看一眼实际解析结果，比ping直观。

4.4 桥接不通与 NAT 不通：两种模式各自的坑

桥接模式的典型症状是网卡链路正常、ifconfig有地址，但 ping 不通同网段的任何机器。排查顺序：先在虚拟机设置里确认桥接的目标物理网卡选对了。宿主机有多块网卡（有线、无线、虚拟专用网卡）时，VMware 默认的"自动"选择经常选错，手动指定成你实际在用的那块。如果宿主机用的是无线网卡，部分无线驱动对桥接支持不好，可以直接换 NAT 绕开。再就是宿主机的安全软件和网络过滤驱动，它们有可能拦掉虚拟机的帧。

NAT 模式的症状是拿不到地址或者拿不到正确网关。首先确认宿主机的两个 VMware 服务在运行：NAT 服务和 DHCP 服务。这两个服务停了，虚拟机会表现成"链路正常但永远 DHCP 超时"。其次是网段判断：NAT 模式下虚拟网络的网关固定是子网的第二个地址（比如192.168.137.2），DHCP 池通常在子网的后半段（192.168.137.128到192.168.137.254）。如果你手配的静态地址是192.168.137.200，正好落在 DHCP 池里，就可能和别的虚拟机撞地址，表现为时通时不通。规划静态地址时避开池子，选.10到.100这段比较安全。

4.5 防火墙挡在中间：最容易误判的一层

SuSEfirewall2是 SUSE 10 的默认防火墙组件，用SuSEfirewall2 status看状态、iptables -L -n看具体规则。典型的误判场景是：配置全对，从宿主机ping虚拟机不通，但虚拟机自己ping网关是通的。这时候先确认虚拟机的防火墙规则有没有把入向的 ICMP 或目标端口挡掉。

验证方法很直接，临时停掉防火墙再测一次：

SuSEfirewall2 stop # 测试完成后恢复 SuSEfirewall2 start

注意：停防火墙只用于定位，不要停在生产状态。确认是防火墙问题后，应该用yast firewall把需要的服务或端口加到允许列表，而不是一停了之。

4.6 问题速查表

5. 把配置固化下来：可复现的几条习惯

5.1 规划网段时先做一次冲突检查

NAT 模式虽然省事，但 VMnet8 的默认子网经常和办公网撞车。假设宿主机所在网段是10.10.8.0/24，你把虚拟机网络也设成10.10.8.0/24，或者设成和某个要访问的内网服务同段，路由就会打架，表现为"虚拟机自己能通、访问某个内网地址却跑到虚拟机里去了"。动手前先在宿主机上看一眼路由表（Windows 用route print，Linux 用ip route），确认你要用的网段没有被占用。

顺带算一下容量。/24的网段可用主机地址是 254 个，广播地址是.255，网络地址是.0；如果拆成/26，每段只有 62 个可用地址，掩码是255.255.255.192，四段分别是.0-.63、.64-.127、.128-.191、.192-.255。老系统集群一般不超过十台机器，/24足够，拆得越细后面越容易记混。我的做法是给虚拟化环境统一留一个专用网段，比如192.168.137.0/24，网关用.2，静态地址从.10开始往后排，DHCP 池留在.128之后，静态和动态永远不重叠。

5.2 配置备份与模板化

网络配置涉及的目录不多，打包很简单：

tar czf /root/net-config-backup.tar.gz \ /etc/sysconfig/network/ \ /etc/udev/rules.d/30-net_persistent_names.rules \ /etc/resolv.conf \ /etc/hosts \ /etc/modprobe.conf.d/

这个包在改配置之前打一次，出问题解压回去重启网络就能恢复。做模板机器的话，克隆之前要先清理，清理脚本大致这几步：清空 udev 规则文件、删掉/etc/sysconfig/network/下所有按 MAC 命名的配置文件、清掉/etc/resolv.conf里的 DNS、检查/etc/hosts里有没有写死的主机名。清理完关机，再用这台机器做模板，克隆出来的每一台都能干净地重新生成eth0。

5.3 快照与变更记录

网络配置是所有变更里最容易把自己锁在门外的一类。我的习惯是改之前打快照，名字写清楚"改网络前-静态IP-192.168.137.20"，别用默认的"快照1"。改完之后如果验证通过，再打一个"改网络后"的快照，两个快照之间就是这次变更的可回滚区间。

变更记录同样重要。老系统往往一年才动一次，下次再碰这台机器的人可能是别人。我会在/root/下留一个network-change.log，写清楚改了什么文件、改前是什么值、改后是什么值、为什么改。三行字，能省掉后面半小时的考古。

5.4 几条踩坑心得

第一条，永远在 VMware 控制台里改网络，不要通过 SSH 改。rcnetwork restart一旦失败，SSH 断了你就没有任何入口，只能强制重启，运气不好还会丢未保存的数据。

第二条，改完配置后不要只ifup eth0，要rcnetwork restart整体重启一次网络服务。单接口ifup有时候不会重新读路由和 DNS 配置，你看到的现象和实际配置状态不一致，误导判断。

第三条，ifcfg-eth0和ifcfg-eth-id-*不要同时存在。这是 SUSE 10 上最高频的"改了没生效"原因，没有之一。

第四条，克隆前清理的价值远大于事后修复。每台克隆机都单独排查名称问题，成本会翻好几倍，不如在模板阶段一次解决。

第五条，验证顺序不能跳。ethtool看链路、ifconfig看地址、route看路由、ping网关、ping外网、ping域名，这六步每一步都能把问题范围缩小一半。很多人跳过前面的步骤直接去ping外网，结果连是链路问题还是 DNS 问题都分不清，白折腾。

我个人在实际维护这类老系统时的体会是，SUSE 10 的网络配置本身并不复杂，文件就那么几个、字段就那么几个，真正花时间的全在"名字对不上"和"配置被覆盖"这两类事上。把 udev 规则和ifcfg文件的优先级关系搞清楚，把netconfig会不会重写resolv.conf这件事提前确认好，剩下的基本就是按顺序验证。至于网卡型号，记住一条就够了：内核 2.6.16 上e1000是最稳的选择，别去追新。这套配置我用了很多年，从单机实验到几台机器的小集群，改完打包备份、打快照、按层次验证，基本没有翻过车。