工作的内容有变动，以前主要做网络维护，现在开始弄虚拟化了。

    新部门有3个ESXI远程主机（IP：10.70.*.*），领导让我在其中一个上面安装VCSA，用于管理这三台主机。

    但是又听领导说，部门原有一个VCSA（10.69.*.*），现在无法添加那3台主机，如果能加上就最好了。

    作为一个喜欢解决问题的好同志，我准备研究一下VCSA为什么加不上主机，先登录到VCSA上，尝试添加主机，结果任务执行到80%卡住了，最后失败了，提示“无法访问指定的主机（X.X.X.X）。此主机在网络上不可用、网络配置有问题或主机上的管理服务无响应”。

    看起来是个网络问题？先ping一下试试。使用本机进行ping测试，ESXI主机可以ping通，VCSA也能ping通。使用ssh登录到VCSA所在的虚拟机（VCSA）上，能ping通ESXI；在ESXI上开启ssh服务后，登录上去，却ping不通VCSA。单通？看来真是网络问题啊。我把自己分析的结果告诉领导，自认为应该很好解决。

    接下来，用tracert命令从两端进行测试，发现从源地址到目的地址中间有3跳，在ESXI主机上做tracert测试时，第2跳结束后就不通了。于是去网络组找同事查看路由是否有问题。由于公司内网的网段很多，使用了OSPF动态路由，同事查了很久后告诉我路由是正常的。

    这几天正在搞护网行动，猜测是不是网络那边加了什么安全策略，于是又请网络组同事帮忙，查询结果仍然是没有问题，并没有针对VCSA和ESXI主机所在的网段做安全策略。我把那几台三层交换机的配置数据要了过来，自己检查了一遍，确实没有问题。

    那是怎么回事呢？为了验证这是个网络问题，我利用华为的ENSP模拟器搭建了一个网络拓扑，把IP、网段和OSPF的路由都按真实的数据配置到了模拟器上，进行ping测试，结果正确。

    之后我针对VCSA这边配置了访问控制列表，启用了包过滤，发现两边都无法ping通了。看来真的与这3台交换机的配置无关了，因为安全策略会让两边都ping不通，而不是单通。

    虽然排除了交换机配置的问题，但是根据tracert测试的结果，问题确实存在于右边两个交换机之间，再次找网络组同事核实，两个交换机之间是否还有其它设备。同事告诉我，确实还有一个TAC（准入系统），我感觉豁然开朗，一定是TAC闹的。于是让那位同事检查了TAC的配置，并把ESXI那几台主机的IP地址加入到了TAC的例外中。再一测试，两边都能ping通了。

    我兴高采烈地到VCSA上去添加主机，结果又可耻的失败了。报错的内容与之前一模一样，就跟没有处理过网络问题一样。我考虑到TAC是否在端口或协议上有什么限制，同事告诉我，没有任何限制。看来我只能从VCSA和ESXI上找原因了。在VCSA上打开了任务控制台，选中了刚才那个失败的任务，相关事件中列出了如下内容：

    竟然看到了用户名和密码不正确的提示？怎么可能呢，我用root帐号登录ESXI是没有问题的呀。我又到ESXI的管理页面上查看，发现VCSA在添加ESXI主机时，要创建一个vpxuser用户，而且创建失败了，说是用户已存在。这是怎么回事呢？百度了一下才了解到，原来VCSA会在添加主机时，使用root在ESXI主机上创建vpxuser用户，并为它授权，以后都会用vpxuser来管理ESXI，而且vpxuser的密码会自动定期更换。难道是这个主机以前被VCSA管理过，所以早就存在了这个用户？与领导核实了一下，确实如此，我正在检查的这个VCSA和ESXI主机，以前本来就是连通的，只是不知道什么时候就断开了，都过了很久了，一直也管理不上，添加不了。

    我想既然vpxuser已存在，创建用户失败了，那我把这个用户删除应该就可以了吧。到ESXI的页面管理上查看用户，看不到vpxuser，于是ssh到ESXI上，看到/etc/passwd文件里，确实存在vpxuser，但是失望的发现没有userdel命令，那该怎么删除用户呢？于是开始百度linux系统的用户创建和删除的原理。经过一番研究，发现主要是/etc/passwd  、/etc/shadow、/etc/group等几个文件，只要把文件中对应用户名的记录删除就可以了。到ESXI上操作了一遍后，vpxuser删除了。兴冲冲地到VCSA上添加主机，结果再次失败了。我快崩溃了！VCSA的任务控制台显示的结果与之前一样，只是ESXI页面上的提示有所变化，vpxuser用户创建成功了。然并卵……

    又开始了不停的百度与测试，无论是中国网站还是外国网站都查了，一直没有解决问题。无奈之下，我只想再判断一下，到底是VCSA有问题还是ESXI主机有问题。我在远程的ESXI主机上使用OVA模板部署了一个新的vsca，对3台主机做了添加测试，发现有一个添加成功了，暂时命名为ESXI主机C，而另外两台（暂时命名为A和B）都添加失败，并提示主机已被10.69.X.X管理了，我就很奇怪，明明A和B在老的VCSA上添加失败了，为什么还有这个提示呢，应该是有什么数据没有清除掉吧。我去问了一下经验丰富的领导，他告诉我把ESXI主机A和B重启一下（运维人员的三板斧啊），我照做后，在新的VCSA上果然添加成功了。既然3个ESXI主机都能被添加到新的VCSA上，是否说明老的VCSA配置上有问题呢。报着这个怀疑，我又上网查了好久，有的说VCSA版本要高于ESXI，这个我不需要考虑，因为我这边的VCSA以前是可以管理这3台ESXI的，版本都是6.7，新的VCSA和老的VCSA只是在小版本号上有点差别。在vmware官网的问答里，我看到有人说，在VCSA的配置——高级VCSA设置中，把vpxd.certmgmt.mode的值由vmca改为thumbprint后问题解决，于是我也照着做。先到新的VCSA上看了一下配置，发现值是vmca，看来应该与这个值无关，不过试一下也好，反正也没有好办法。

    我上到老的VCSA上，却发现高级设置页面并没有“编辑设置”按钮，这该怎么办呢？上网查了一番无果后，我决定到vcsa的数据库里去修改。根据查询到的资料显示，vcsa里内置了一个PostgreSQL数据库，对这个数据库我也不太熟，又经过一番学习后，我找到了高级VCSA设置使用的表，是在VCDB库中的vpx_parameter表。然后修改了vpxd.certmgmt.mode的值为thumbprint。但是到页面上一看，值没有变过来，于是把vcsa虚拟机给重启了一下，这回值变了：

    然后又到VCSA上添加主机，再次失败了。

    没有办法，实在找不到相关的资料了，我开始查看ESXI和vcsa上的各种日志文件，并使用tail -f命令监控一些日志文件的同时，在两个vcsa上添加ESXI主机做对比。日志的内容太多了，在不太了解原理的情况下，对我并没有什么帮助。我没有在日志中找出什么有用的信息，可能主要还是因为我看不太懂。两个vcsa添加主机的日志对比，我也没有看出什么特别的异常。

    我已经快绝望了，都准备告诉领导，不行就用新的VCSA吧。但是报着试一试的态度，我决定在VCSA添加主机的时候在两端抓包。以前倒是使用过wireshark抓包，会简单的查看通信过程，但是当前的环境使用wireshark就不太方便了。好在vcsa和ESXI的系统都支持tcpdump命令，我以前虽然没用过，但是可以现学现卖。于是我分别在VCSA和ESXI系统上执行了下面的命令：

tcpdump host  X.X.X.X  -w  test.cap

    PS:    IP地址为目地IP。即VCSA上的目的IP为ESXI，ESXI上的目的IP为VCSA。

    使用老VCSA和新VCSA分别做了一次添加主机的操作，并把数据包抓取了下来，使用ssh命令拷到了本地。

    当我用wireshark打开抓包结果，做了一番对比后，果然发现了一点不同。老VCSA添加主机失败的那个数据包，里面有不少重传的TCP包，目标指向ESXI的902端口。

    这些由VCSA发往ESXI的902端口的数据包，都没有得到回应。而新的VCSA添加ESXI主机成功时，这样的数据包是有正常回应的。难道是ESXI的902端口对VCSA有访问限制？在老的vcsa虚拟机上使用wget命令测试ESXI的902端口，确实不通，而新的vcsa上测试访问ESXI的902端口，是能通的。又百度了一下902端口的用途，大部分资料显示说UDP 902端口用于VCSA对ESXI主机做心跳检查，超过60秒没有回应，就会自动断开与主机的连接。通过上图的抓包结果来看，No.1170到No.1171，两个记录之间的时间间隔为65秒，看起来像是这么回事。但是我的抓包显示是TCP而不是UDP呀，没明白怎么回事。也有的说902端口用于认证？或用于VNC？我不太确定，不过这个端口不通应该是不行的。

    在几个路由节点上，我分别进行了端口测试，最后发现测试到拓扑图中的最左边的交换机时，端口就不通了，与网络组同事核实后，确认在拓扑图中左边的两个交换机之间有个天融信的防火墙，里面默认阻止了大部分端口，于是让同事给添加了策略，这回端口终于通了。这里要吐槽一下这个防火墙，关闭和退出意义混淆，点了关闭后，又点了取消，结果防火墙直接关机了。害我赶紧骑上自行车到了远端机房把防火墙重新开机。开机后，之前配的策略还没了，让同事又重新配置了一下。

    端口通了以后，老的VCSA添加ESXI主机终于成功了！

    这个问题继继续续困扰了我一周的时间，最后总算解决了。但是处理问题的过程中，我学到了很多知识，包括重温了OSPF路由和访问控制策略、了解了linux系统中用户创建的过程、VCSA管理ESXI的部分原理、PostgreSQL数据库以及tcpdump的使用等。所以说，解决问题的结果虽然很有成就感，但是处理过程中学习到的知识才是最珍贵的。在日常的维护工作中，经常遇到问题、解决问题，才能学到更多的知识和原理，一切运行良好是很舒服，不过那样很难深刻的学习到知识。

    最后，可见获取更加全面的信息多么重要，如果一开始就把所有网络配置与设备拓扑整理出来，或许很快就能发现并解决问题了，不过还是那句话，解决的越快，学到的越少。