VMware VCSA 6.7 无DNS环境安装实录：巧用自带dnsmasq搞定FQDN难题
VMware VCSA 6.7无DNS环境部署实战：临时解析方案设计与避坑指南
在企业虚拟化平台部署过程中，vCenter Server Appliance（VCSA）的安装往往是整个架构的核心环节。然而在实际运维场景中，我们常常会遇到各种基础设施不完善的"非理想环境"——比如缺乏现成DNS服务器的情况下，却需要以FQDN方式完成VCSA部署。这种看似矛盾的需求背后，通常隐藏着企业对未来IP变更灵活性的考量。
1. 无DNS环境下的FQDN部署挑战与解决方案
当企业计划部署vCenter时，网络团队可能尚未准备好正式的DNS服务，但运维团队又希望避免后期因IP变更带来的连锁反应。这种情况下，传统的hosts文件修改法显得过于原始，而临时搭建完整DNS服务器又显得杀鸡用牛刀。此时，VCSA自带的dnsmasq服务便成为一个优雅的折中方案。
为什么选择dnsmasq？这个轻量级DNS转发器内置于大多数Linux发行版中，VCSA基于Photon OS自然也包含这一服务。与完整DNS服务相比，它具有三大优势：
- 零额外资源消耗：无需部署新虚拟机或容器
- 配置极简：仅需修改两个文件即可启用
- 即用即弃：安装完成后可无缝迁移至正式DNS环境
关键提示：此方案仅适用于安装阶段的临时解析需求，正式生产环境仍需配置企业级DNS服务。
在开始前，请确保已准备好以下信息：
- VCSA的预定IP地址（如192.168.1.100）
- 规划好的FQDN（如vcsa01.example.com）
- ESXi主机的管理权限
- VCSA 6.7的ISO安装镜像
2. 第一阶段部署：关键参数配置解析
第一阶段部署看似常规，但有几个参数配置直接影响后续临时DNS方案的可行性。以下是需要特别关注的步骤及技术原理：
2.1 网络配置中的DNS设置
在安装向导的"网络设置"步骤中，DNS服务器地址的填写需要特别注意：
| 参数项 | 常规配置 | 本方案配置 | 原因分析 |
|---|---|---|---|
| DNS服务器1 | 企业DNS服务器IP | VCSA自身IP | 为后续dnsmasq监听做准备 |
| DNS服务器2 | 备用DNS服务器IP | 留空 | 避免系统尝试外部解析 |
| 主机名 | 短名称(如vcsa01) | 完整FQDN | 确保证书生成正确 |
常见误区警示：
- 填写外部DNS服务器IP会导致安装程序尝试外部解析，在无网络环境下造成超时
- 使用短主机名而非FQDN会导致第二阶段SSO域配置时出现命名不一致
2.2 部署后的初步验证
第一阶段完成后，通过ESXi主机控制台登录VCSA虚拟机，需要确认两个基本条件：
- 网络连通性正常：
ping 192.168.1.1 # 测试网关连通性 - SSH服务已启用（后续配置需要）：
systemctl status sshd
若SSH未启动，可通过控制台执行：
systemctl start sshd systemctl enable sshd3. dnsmasq服务配置：从原理到实践
3.1 配置文件深度解析
dnsmasq的核心配置涉及两个文件，每个修改都有其特定目的：
/etc/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 # 修改监听地址 sed -i 's/listen-address=127.0.0.1/listen-address=<VCSA_IP>/g' /etc/dnsmasq.conf关键修改点解析：
addn-hosts：指定额外hosts文件路径，避免直接修改系统hostslisten-address：允许网络其他设备查询此DNS服务
/etc/dns_add_hosts解析记录文件：
# 格式：IP地址 FQDN [别名] 192.168.1.100 vcsa01.example.com
3.2 服务调试技巧
配置完成后，重启服务并验证：
systemctl restart dnsmasq systemctl status dnsmasq高级验证方法：
- 正向解析测试：
nslookup vcsa01.example.com 127.0.0.1 - 反向解析测试：
nslookup 192.168.1.100 127.0.0.1 - 外部测试（从同网络其他主机）：
# Windows系统 nslookup vcsa01.example.com 192.168.1.100
排错要点：若解析失败，检查防火墙规则是否放行UDP 53端口
4. 第二阶段部署：SSO配置与最终验证
4.1 SSO域命名规范
在第二阶段部署中，Single Sign-On域的设置需要特别注意命名空间规划：
- 推荐格式：
vsphere.local（默认）或与企业域关联的子域 - 避免冲突：不要使用真实的互联网域名（如example.com）
- 大小写敏感：全部小写可避免潜在问题
4.2 安装后验证清单
部署完成后，建议执行以下验证步骤：
- 基础服务检查：
service-control --status --all - Web控制台访问测试：
- 使用FQDN访问：
https://vcsa01.example.com/ui - 检查证书有效性（应显示为可信）
- 使用FQDN访问：
- API接口测试：
curl -k https://vcsa01.example.com/rest/vcenter/vm
客户端临时解决方案： 对于需要访问vCenter的运维工作站，可临时修改hosts文件：
# Windows路径 C:\Windows\System32\drivers\etc\hosts # Linux/Mac路径 /etc/hosts # 添加记录 192.168.1.100 vcsa01.example.com5. 生产环境迁移与后续优化
临时方案终究要过渡到正式环境，以下是平滑迁移的建议步骤：
DNS记录预配置：
- 在企业DNS服务器创建正向(A)记录
- 配置反向(PTR)记录
- TTL设置为较短时间（如300秒）
VCSA网络配置更新：
# 使用VAMI接口（5480端口）修改DNS设置 # 或使用命令行 /opt/vmware/share/vami/vami_config_net服务依赖更新：
# 重启依赖网络识别的服务 service-control --restart vmware-vpxd客户端清理：
- 移除所有临时hosts文件修改
- 清除DNS缓存：
# Windows ipconfig /flushdns # Linux systemd-resolve --flush-caches
在真实的项目环境中，我们曾遇到过一个典型案例：某制造业客户在测试环境使用此方案成功部署后，忘记迁移到正式DNS，三个月后网络改造时才发现问题。这提醒我们，临时方案必须配套严格的文档记录和迁移计划。