Growing in Errors VMware Administrator's Five Mistakes

When VMware administrators talk about mistakes made at work, I often say that if you are not making mistakes, then you are not learning.

Some errors are due to attempts, others are due to lack of knowledge. And there are some stupid things that we should already know should not do. But in the end, we became better VMware administrators because of the mistakes we made.

Here are the unforgettable mistakes made by VMware administrators that Mike Nelson has seen, heard, and experienced.

VMware Administrator Error 1: Virtual Machine Rename

This type of error is very typical. Renaming a virtual machine in vCenter is straightforward: right-click on the client, select Rename, and enter a new name.

But this operation simply renames the object pointer in the vCenter database, and the directories and files associated with the virtual machine are still under the original name. For VMware administrators, it's easy to quickly clean up the data store process, delete virtual machine directories and files, and just click on the mouse, especially if there is no client and current directory match. I have seen this happen and the consequences are very serious.

VMware Administrator Error 2: Stuffing the Entire LUN

I attended a conference many years ago and is an activity related to the new features of VMware ESX 3. The presenter created a 100GB LUN on the SAN and assigned it to a cluster of two nodes for presentation.

He created three virtual machines on this LUN, each with a 32GB hard drive and a 2GB ISO shared data store. Calculate, the storage space used is: (32GBx3) + 2GB = 98GB. For a 100GB LUN, there is enough space, is that true?

He started all the virtual machines one by one. When the third virtual machine is started, all the virtual machines are dead. It seems that he forgot to create a swap file when starting the virtual machine. These swap files fill up the entire LUN, and more interesting because he doesn't know why this happens, so he tries to start the virtual machine again.

Yes, he is a VMware engineer.

VMware Administrator Error 3: Network Name

I was a consultant to a small institutional project at Citrix, where the storage engineer was managing the new virtualization environment. One day, I received a call from him. He encountered problems when doing vMotion operations, and distributed resource scheduling (DRS) also produced a lot of errors. (I mentioned this guy is a storage engineer?

I logged into vCenter and found that all ESX hosts are not set up on the same network. Each virtual switch has a different on each host. Name, this is a common mistake when ESX hosts are not created at the same time or do not follow naming conventions (or even no naming rules). VMotion requires that the virtual switch names of all hosts in the DRS cluster be the same.

VMware Administrator Error 4: Honeymoon and Roles

A VMware administrator had to fix a virtualization problem before going to honeymoon. Before he left, he decided to move from the role in vCenter. In addition to personnel, the infrastructure is locked.

But he removed the vCenter object -- not just a virtual machine or cluster, a role with access rights. This action prevents anyone from having access to the vCenter object. >

I heard this story from his bride, because the wrong operation caused the honeymoon to run aground, she was not happy at all.

VMware administrator error 5: The card is completely ruined

The VMware host configuration file only appeared a year later, I can't wait, and I can't wait to quickly deploy a standard host in the basic implementation of more than 500 hosts. When I finally used the host configuration file, it was all wrong at once.

I created a new host configuration file and tested it on the lab host. After testing some virtual machines on the host, it looks There was no problem. So I decided to apply the host configuration file on a cluster with 16 hosts in the production environment.

Later, vCenter looks fine. I just got happy for 5 seconds and it happened. Alarm. All my virtual machines and hosts cannot be accessed over the network.

One problem with ESX host configuration files is that regardless of the NIC rate set in the configuration file, all host rate reading configuration files defaults. Both are set to adaptive mode (of course, VMware calls it a feature).

This setting is hardcoded to 1000M in the network. In the Full mode of trouble-free recovery, it cannot be run (the lab network port is auto mode, so it can run normally). Once this setting is applied to all hosts, the entire cluster is dragged. I have to re-restart each host. Manually configuring 14 network cards, it took a whole day.

Shenma? VMware itself made mistakes?

Remember ESX 3.5 Update 2? Thousands of hosts around the world after the fiasco Downtime.

VMware will not easily admit that the bugs discovered by the user community exist. If you have ESX 3.5 Update 2 installed, once you change the clock to 12:01 AM on August 12, 2008, you can't vMotion or start any virtual machine.

VMware finally admitted that the problem was caused by a piece of code that caused the license to expire, and this code was somehow passed the beta test and quality control. This "time bomb" bug caused serious problems. The only solution was to disable the Network Time Protocol (NTP) on the server and set the clock back to August 10, 2008. VMware released a patch on August 14, but many customers will be cautious about VMware's products and the tests it does.

Mr. Paul Maritz, CEO of VMware, sent an email to the customer and apologized for the bug, saying that this problem will never happen again.