在错误中成长 VMware管理员五大误区

2011-04-07 10:08:11

云计算

虚拟化当VMware管理员谈论工作中所犯的错误时，我经常说，如果你没在犯错，那么你就没在学习。以下是特约专家Mike Nelson曾经看到、听到和经历过的令人难忘的VMware管理员所犯的错误。

当VMware管理员谈论工作中所犯的错误时，我经常说，如果你没在犯错，那么你就没在学习。

一些错误是由于尝试导致，其他一些是由于缺乏知识。而还有一些是我们应该已经知道不该去做的蠢事。但是最后，因为曾经犯的错误，我们成为了更好的VMware管理员。

以下是特约专家Mike Nelson曾经看到、听到和经历过的令人难忘的VMware管理员所犯的错误。

VMware管理员错误1:虚拟机重命名

这种错误非常典型。在vCenter中对虚拟机重命名非常简单：右键单击客户机，选择“重命名”,然后输入新的名字。

但是这个操作仅仅是重命名vCenter数据库中的对象指针，和虚拟机关联的目录和文件仍然在原来的名字下。对于VMware管理员来说，快速清理数据存储过程，删除虚拟机目录和文件，只需要点一下鼠标，非常容易，尤其是在没有客户机和当前目录相匹配的情况下。我已经看到过这种事情发生，而且后果很严重。

VMware管理员错误2:塞满整个LUN

我多年前参加一个会议，是和VMware ESX 3新特性有关的活动。演示人员在SAN上创建了一个100GB的LUN,并把它分配给一个用于演示的包含两个节点的集群。

他在这个LUN上创建了三个虚拟机，每个虚拟机有32GB的硬盘以及2GB ISO共享数据存储。计算一下，使用的存储空间为：（32GBx3）+ 2GB = 98GB.对于一个100GB的LUN来说，还有足够的空间，是这样吗？

他一个个地启动了所有的虚拟机。当启动第三个虚拟机时，所有的虚拟机都死机了。看来是他忘记了启动虚拟机时会创建交换文件。这些交换文件填满了整个LUN,更有趣的是因为他不知道为什么会发生这种情况，所以他再次尝试启动虚拟机。

是的，他是一个VMware工程师。

VMware管理员错误3:网络名称

我曾经是Citrix公司一个小机构项目的顾问，这个机构的存储工程师在管理新的虚拟化环境。一天，我接到了他的一个电话。在进行vMotion操作时，他遇到了问题，并且分布式资源调度（DRS）也产生了许多错误。（我提到这家伙是个存储工程师了吗？

我登录到vCenter上，发现所有的ESX主机并没有设置在相同的网络上。每个虚拟交换机在每个主机上具有不同的名字，当ESX主机没有被同时创建或者没有遵循命名规则（或者甚至不存在命名规则）时，这是一个很常见的错误。VMotion要求DRS集群中所有主机的虚拟交换机名称是相同的。

VMware管理员错误4:蜜月和角色

有个VMware管理员在去度蜜月前不得不修复一个虚拟化问题。在他离开前，他确定在vCenter中从角色中移除人员，锁定基础设施。

但是他移除了vCenter对象–不仅仅是虚拟机或集群，具有访问权限的角色。这个操作阻止任何人有权限去访问vCenter对象。

我从他的新娘那听到了这个故事，因为错误操作导致蜜月搁浅，她压根儿就不高兴。

VMware管理员错误5:网卡全军覆没

了解的VMware主机配置文件在一年后才出现，我有些等不及了，迫不急待地在超过500个主机的基础实施中快速部署标准的主机。但是当我最终使用主机配置文件时，一下子全错了。

我创建了一个新的主机配置文件并在实验室主机上进行测试。在主机上测试一些虚拟机后，看起来并没有任何问题。因此我决定在生产环境中包含16个主机的集群上应用主机配置文件。

稍后，vCenter看起来一切正常。我刚刚高兴了5秒钟，就产生了告警。我所有的虚拟机和主机都不能通过网络进行访问。

ESX主机配置文件的一个问题就是不管网卡速率在配置文件中设置为多少，所有读取配置文件的主机速率默认都设置为自适应模式（当然，VMware称之为它的一个特性）。

这个设置在网络中交换机端口被硬编码为1000M或者无故障恢复的Full模式时，不能运行（实验室网络端口是auto模式，所以能够正常运行）。一旦将这个设置应用到所有的主机上，整个集群被拖垮了。我不得不在重新每个主机上手动配置14块网卡，这整整花费了一天时间。

神马？VMware自己也犯错？

记得ESX 3.5 Update 2吗？世界各地上千台主机在惨败之后宕机了。

VMware不会轻易承认用户群发现的bug是存在的。如果你安装了ESX 3.5 Update 2，一旦时钟改到2008年8月12日上午12:01，你不能进行vMotion或者启动任何的虚拟机。

VMware最终承认问题是由于一段代码导致了许可证过期，并且这段代码以某种方式通过了测试版的测试和质量控制而引起的。这个“计时炸弹”bug造成了严重的问题，唯一的解决办法就是禁用服务器上的网络时间协议（NTP），并且设置时钟可追溯至2008年8月10日。 VMware在8月14日发布了一个补丁，但众多的客户将会对VMware的产品和它所做的测试持谨慎态度。

VMware首席执行官Paul Maritz先生给客户发送电子邮件，就bug进行了道歉，表示这种问题将永远不再发生。

【编辑推荐】