間違いで成長するVMware管理者の5つの間違い

VMwareの管理者が職場での間違いについて話すとき、私はあなたが間違いを犯していないのであれば、学習していないとよく言います。

エラーの中には試行によるものもあれば、知識不足によるものもあります。そして、私たちがすでに知っているべきではないいくつかの愚かなことがあります。しかし、最終的には、ミスをしたため、VMware管理者が増えました。

Mike Nelsonがこれまでに見たこと、聞いたこと、経験したことがあるVMware管理者による最も忘れがたい間違いのいくつかを次に示します。

VMware管理者エラー1：仮想マシン名の変更

この種のエラーは非常に一般的です。 vCenterで仮想マシンの名前を変更するのは簡単です。クライアントを右クリックして[名前の変更]を選択し、新しい名前を入力します。

ただし、この操作ではvCenterデータベース内のオブジェクトポインタの名前が変更されるだけで、仮想マシンに関連付けられているディレクトリとファイルは元の名前のままです。 VMware管理者にとって、特にクライアントと現在のディレクトリが一致しない場合は、データストアプロセスのクリーンアップ、仮想マシンのディレクトリとファイルの削除、およびマウスのクリックだけで簡単に行えます。私はこれが起こるのを見ました、そして、結果は非常に深刻です。

VMware管理者エラー2：LUN全体を詰め込む

私は何年も前に会議に出席しましたが、これはVMware ESX 3の新機能に関する活動です。プレゼンターはSAN上に100GBのLUNを作成し、それをプレゼンテーション用に2つのノードのクラスターに割り当てました。

このLUN上に3台の仮想マシンを作成しました。それぞれに32GBのハードドライブと2GBのISO共有データストアがあります。計算すると、使用されているストレージ容量は、（32GB×3）+ 2GB = 98GBです。100GBLUNの場合、十分な容量があります。

彼はすべての仮想マシンを一つずつ起動しました。 3番目の仮想マシンが起動されると、すべての仮想マシンが停止しています。仮想マシンの起動時にスワップファイルを作成するのを忘れたようです。これらのスワップファイルはLUN全体を埋め尽くしますが、なぜこれが起こるのかわからないので、彼は仮想マシンを再起動しようとします。

はい、彼はVMwareのエンジニアです。

VMware管理者エラー3：ネットワーク名

ストレージエンジニアが新しい仮想化環境を管理していたCitrixの小規模な組織プロジェクトのコンサルタントでした。ある日、私は彼から電話を受けました。彼はvMotion操作の実行中に問題に遭遇し、分散リソーススケジューリング（DRS）も多くのエラーを生み出しました。 （私はこの人がストレージエンジニアだと言った？

私はvCenterにログインし、すべてのESXホストが同じネットワーク上に設定されていないことを発見した。それぞれの仮想スイッチはそれぞれのホストで異なる。名前、ESXホストが同時に作成されない、または命名規則に従わない（または命名規則に従わない）場合、これはよくある間違いです。VMotionでは、DRSクラスタ内のすべてのホストの仮想スイッチ名が同じである必要があります。

VMware管理者エラー4：新婚旅行と役割

VMware管理者は、新婚旅行に行く前に仮想化の問題を解決しなければなりませんでした。

しかし、彼はvCenterオブジェクトを削除しました - 仮想マシンやクラスタ、アクセス権を持つロールだけではなく、この操作により、誰もがvCenterオブジェクトにアクセスできなくなります。 >

彼の花嫁からこの話を聞きました。間違った操作が新婚旅行をひきつける原因になったので、彼女はまったく幸せではありませんでした。

VMware管理者エラー5：カードが完全に台無しにされた

VMwareホストの設定ファイルが登場したのは1年後のことで、待てず、500台を超えるホストの基本的な実装で標準ホストをすばやく展開するのも待ちきれません。ホスト構成ファイルを最後に使用したとき、それはすぐにすべて間違っていました。

新しいホスト構成ファイルを作成してラボのホスト上でテストしました。問題はありませんでしたので、運用環境で16台のホストを持つクラスターにホスト構成ファイルを適用することにしました。

その後、vCenterは問題なく動作し、5秒間満足しました。アラーム：すべての仮想マシンおよびホストにネットワーク経由でアクセスできない。

ESXホストプロファイルの問題の1つは、構成ファイルに設定されているNICレートに関係なく、構成ファイルを読み取るためのすべてのホストレートがデフォルトであることです。どちらもアダプティブモードに設定されています（もちろんVMwareはこれを機能と呼びます）。

この設定はネットワークのスイッチポートで1000Mにハードコードされているか、フルモードのトラブルフリーリカバリでは実行できません（ラボネットワークポートは自動モードであるため、通常どおり実行できます）。この設定をすべてのホストに適用すると、クラスタ全体がドラッグされ、各ホストを再起動する必要があります。手動で14枚のNICを設定するのに1日かかった。

Shenma？VMware自身が間違いを犯した？

ESX 3.5 Update 2を覚えてる？世界中で何千ものホストが大失敗の後にダウンタイム。

VMwareは、ユーザーベースによって発見されたバグが存在することを容易に認めていません。 ESX 3.5 Update 2がインストールされている場合、2008年8月12日に一度クロックを午前12:01に変更すると、vMotionを実行したり、仮想マシンを起動したりすることはできません。

VMwareはついに、問題がライセンスの期限切れを引き起こしたコードの一部によって引き起こされたことを認め、そしてこのコードはどういうわけかベータテストと品質管理に合格しました。この "時限爆弾"のバグは深刻な問題を引き起こしていましたが、唯一の解決策はサーバー上でネットワークタイムプロトコル（NTP）を無効にしてクロックを2008年8月10日に戻すことでした。 VMwareは8月14日にパッチをリリースしたが、多くの顧客はVMwareの製品とそれが行うテストについて慎重になるだろう。

VMwareのCEOであるPaul Maritz氏がクライアントにEメールを送り、この問題は二度と起こらないだろうと言ってバグについて謝罪した。