VMware VCSA 6.7 安装遇坑记：没有DNS服务器，我是如何用自带dnsmasq搞定FQDN的
VMware VCSA无DNS环境部署实战：巧用dnsmasq实现FQDN解析
当你带着精心准备的部署方案走进机房，却发现客户现场连最基本的DNS服务器都没搭建时，那种感觉就像厨师带着全套法餐厨具走进了一个只有微波炉的厨房。最近一次为客户部署VMware vCenter Server Appliance (VCSA) 6.7的经历让我深刻体会到：在IT基础设施不完善的环境下，真正的专业技能不是按部就班执行完美方案，而是能在资源限制中创造性地解决问题。
1. 当FQDN需求遇上DNS缺失：一个真实的部署困境
那是一个周四的下午，客户要求使用完全限定域名(FQDN)方式部署VCSA 6.7，理由很充分——他们计划未来可能调整vCenter的IP地址，而使用FQDN可以避免后续与其他系统对接时的配置变更麻烦。问题在于，他们的DNS服务器还停留在规划文档里，而项目上线时间已经锁定在下周一。
典型的企业IT现状：
- 网络基础设施往往滞后于虚拟化建设
- 临时搭建Windows DNS或Bind服务器至少需要半天时间
- 客户不允许修改现有网络架构（即使只是临时添加一台DNS服务器）
更棘手的是，VCSA安装分为两个阶段：
- 第一阶段：部署虚拟机基础系统
- 第二阶段：配置vCenter服务
而第二阶段必须能够解析FQDN，否则安装会直接失败。这就是为什么很多工程师在无DNS环境下安装VCSA时，第一阶段顺利完成却在第二阶段卡住的原因。
2. 发现隐藏的救星：VCSA内置的dnsmasq服务
在反复检查VCSA文档时，我注意到一个常被忽略的细节——VCSA默认安装了dnsmasq服务。dnsmasq是一个轻量级的DNS转发器和DHCP服务器，通常用于小型网络。关键在于，它可以被配置为本地DNS解析器！
2.1 第一阶段安装的关键配置
在VCSA安装程序的第一阶段，网络配置页面有一个极易被忽视的细节：
DNS服务器： [192.168.1.100] ← 这里要填写VCSA自身的IP地址！这个配置决定了后续所有DNS查询的走向。填错这里，后面所有努力都将白费。
第一阶段完整流程：
- 运行VCSA安装程序（GUI或CLI）
- 设置目标ESXi主机和虚拟机名称
- 配置网络时：
- IP地址：按规划设置
- 子网掩码：按实际填写
- 网关：按实际填写
- DNS服务器：填写VCSA自身的IP地址
- 完成基础部署，等待第一阶段结束
重要提示：第一阶段结束后，你会看到"无法连接到vCenter管理界面"的警告，这是正常现象，直接关闭即可。
3. 深度配置dnsmasq：不只是改个配置文件
通过SSH登录到新部署的VCSA虚拟机（记得先启用SSH服务），我们需要对dnsmasq进行三项关键配置。
3.1 修改dnsmasq.conf核心参数
首先备份原始配置：
cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak然后执行两个关键修改：
# 启用外部hosts文件 sed -i 's/no-hosts/addn-hosts=\/etc\/dns_add_hosts/g' /etc/dnsmasq.conf # 更改监听地址（将xx.xx.xx.xx替换为VCSA实际IP） sed -i 's/listen-address=127.0.0.1/listen-address=xx.xx.xx.xx/g' /etc/dnsmasq.conf参数解析：
| 参数 | 原始值 | 修改后值 | 作用 |
|---|---|---|---|
| no-hosts | 启用 | 替换为addn-hosts | 禁止/允许使用外部hosts文件 |
| listen-address | 127.0.0.1 | VCSA的IP | 控制服务监听范围 |
3.2 创建自定义hosts文件
新建/etc/dns_add_hosts文件，添加FQDN解析记录：
echo "xx.xx.xx.xx vcsa01.example.com" > /etc/dns_add_hosts（请将IP和域名替换为你的实际值）
3.3 服务重启与测试
应用配置并测试：
systemctl restart dnsmasq nslookup vcsa01.example.com xx.xx.xx.xx nslookup xx.xx.xx.xx xx.xx.xx.xx预期成功输出：
- 正向解析应返回VCSA的IP地址
- 反向解析应返回完整的FQDN
4. 完成第二阶段安装：避开那些看不见的坑
现在可以访问https://[VCSA-IP]:5480继续第二阶段安装。几个容易出错的点：
SSO域名配置：
- 必须与FQDN后缀一致
- 例如FQDN是vcsa01.example.com，SSO域名就应该是example.com
证书警告处理：
- 由于使用自建DNS，浏览器会显示证书警告
- 这是预期行为，临时解决方案是手动信任证书
时间同步检查：
- 确保VCSA与ESXi主机时间一致
- 时间偏差可能导致认证失败
安装后验证：
/usr/lib/vmware-vmafd/bin/vmafd-cli get-site-name --server-name localhost应返回正确的SSO域名。
5. 临时方案的局限性与长期规划
这种方案虽然能应急，但存在明显限制：
- 单点故障：所有解析依赖单台VCSA
- 管理不便：需要手动维护hosts文件
- 扩展性差：新增系统需要手动添加记录
迁移到正式DNS的步骤：
- 在正式DNS服务器上创建正向/反向区域
- 添加VCSA的A记录和PTR记录
- 修改VCSA网络配置，将DNS服务器地址改为正式DNS
- 在所有客户端清除DNS缓存
实际项目中，我们在次周就协助客户部署了Windows DNS服务器，并平滑迁移了解析服务。整个过程对运行中的vCenter零影响，验证了这种过渡方案的可行性。
那次经历让我明白，真正的专业不是永远拥有完美环境，而是在不完美的条件下依然能交付可靠的结果。现在每当我看到VCSA的安装界面，都会想起那个与dnsmasq"斗智斗勇"的下午——它教会我在看似无解的问题面前，解决方案往往就藏在系统的某个角落里，等待我们去发现。