GCP中RHEL7实例串行控制台连接失败及网络访问故障求助

我之前在GCP上维护RHEL实例时碰到过几乎一模一样的情况，给你整理几个亲测有效的排查和修复步骤：

一、先确认串行控制台的基础配置 #

• 首先检查VM实例的串行控制台是否真的启用：在GCP控制台找到你的RHEL7实例，点击「编辑」，下拉到「远程访问」区域，确保「启用串行控制台」选项是勾选状态。有时候网络配置变更时，这个选项可能被意外重置。
• 同时查看VM的监控指标（CPU、内存使用率），如果实例负载过高，会导致内部的串行控制台服务无法正常响应，这也会出现偶尔能连上、多数时候失败的情况。

二、用启动脚本修复网络配置（不用连接实例也能操作） #

既然是网络配置变更导致的SSH/ping失败，我们可以通过GCP的启动脚本强制修复网络：

1. 编辑你的VM实例，找到「自定义元数据」部分，点击「添加项目」。
2. 键填startup-script，值填以下脚本（根据你的情况调整，比如之前是静态IP配置错误，就重置为DHCP）：

   #!/bin/bash
   # 重置eth0为DHCP模式（如果之前静态IP配置有误）
   sed -i 's/BOOTPROTO="static"/BOOTPROTO="dhcp"/' /etc/sysconfig/network-scripts/ifcfg-eth0
   # 重启网络服务
   systemctl restart network
   

3. 保存修改后重启VM，启动脚本会自动执行，修复网络后应该就能正常SSH连接了。

三、趁串行控制台偶尔能连上时修复内部服务 #

如果运气好能连上串行控制台，赶紧做这几步：

• 检查串行控制台服务状态：systemctl status serial-getty@ttyS0.service，如果服务报错或者未运行，执行systemctl restart serial-getty@ttyS0.service，并设置开机自启：systemctl enable serial-getty@ttyS0.service。
• 查看系统日志排查问题：cat /var/log/messages | grep ttyS0 或者 dmesg | grep serial，看看有没有串行端口相关的错误（比如驱动问题、端口占用）。

四、换用gcloud命令行连接串行控制台 #

Web控制台有时候会有缓存或服务端临时问题，试试用GCP命令行工具连接，稳定性更高：

gcloud compute connect-to-serial-port YOUR_INSTANCE_NAME --zone=YOUR_INSTANCE_ZONE

注意替换成你的实例名称和区域。

五、终极方案：挂载磁盘到其他实例修复 #

如果以上方法都不行，还可以：

1. 给故障实例的磁盘创建快照。
2. 用快照创建一个新磁盘，挂载到一台正常运行的RHEL7实例上。
3. 挂载后直接编辑磁盘里的/etc/sysconfig/network-scripts/ifcfg-eth0文件，恢复正确的网络配置。
4. 卸载磁盘，重新挂载回原实例，启动后应该就能正常访问了。

内容的提问来源于stack exchange，提问作者Abhishek Kane