VMware Toolsのバージョンアップ後、Windowsの画面解像度の変更ができなくなった。かつ、VMware Toolsの入れ替え前と比べて、解像度もひくくなった。
これの対応としては、ESXiやvCenterで、仮想マシンのビデオカードの設定を、「設定の自動検出」に変更する。
1. vCenter ServerまたはESXiのウェブUIにログインする。
2. 該当の仮想マシンをシャットダウンする。
3. 「設定の編集」をクリックする
4. ビデオカードの設定を開いて、「設定の自動検出」を選択する。
5. 保存して、仮想マシンを起動する。
6. 仮想マシン（Windows）にログオンして、画面解像度を変更する。
VMware ESXi 6.7環境（vSphere 6.7）に、新しくWindows 2000 Server をインストールした。インストールの時と、インストール後に、vCenter Serverの「Web コンソール」だと、マウスが動かなかった。
Webコンソールではなく、「VMware Remote Console」を使ったところ、マウス操作を行うことができた。ただし、VMware toolsがインストールはできていないので、マウス操作は安定しない。
なお、ESXi 6.7 のVMware toolsのインストーラーだと、Windows 2000 Serverにインストールできない。
Veeam Backup Ver.11a で、ESXi上の仮想マシンのバックアップを取るとき、Windows Server 2003（Windows Server 2003 R2）の仮想マシンで、SQL ServerやOracle Databaseのバックアップを行うオプションを指定している場合、Ver.11aではWindows Server 2003（2003 R2）は、サポート対象外になっているため失敗する。
Veeam Backupで表示されていたエラーは下記。
Failed to prepare guest for hot backup. Error: Unable to perform application-aware processing: Microsoft Windows Server 2003 (Standard) guest OS is not supported
Error: Unable to perform application-aware processing: Microsoft Windows Server 2003 (Standard) guest OS is not supportedVeeam Backup Ver.11aは、仮想マシンとしてはESXiで動作しているものはバックアップが正常に取得できる。Ver.11aでWindows Server 2003などのVeeam Backup 対象外のOSは、バックアップ設定で、「Enable application-aware processing」や「Enable guest file system indexing」のチェックを外し、設定を無効化することで、仮想マシンのイメージとしてのみ、バックアップがされるようになる。これでエラーは発生しない。
仮想マシンのバックアップだが、バックアップの指定方法によっては、バックアップの対象外になるため、注意が必要。
VMwareの仮想マシンのバックアップをVeeam Backupで取得している。Windows Server 2022のバックアップを新しく追加し、スケジュール実行したところ、他の仮想マシンのバックアップも含めて大量に失敗していた。
ログを調べたところ、下記のような表記があり。VMware ESXiのデータストアの空き容量が足りずにスナップショットに失敗し、その結果、バックアップに失敗している。
Getting VM info from vSphere
Production datastore datastoreX is getting low on free space (0.0 B left), and may run out of free disk space completely due to open snapshots.
Error: Insufficient free disk space on production datastore datastoreX.詳細を調べてみると、新しくバックアップを追加したWindows Server 2022のVMDKファイルの容量が増えていた。シンプロビジョニングで、Windows OS上から見たときの使用量は増えてい居ない。VMDK上はディスクの割り当てがされており、限界まで肥大化していた。
VMwareのナレッジを調べてみると、下記のナレッジがあることが分かった。
Thinly provisioned Virtual Disks inflates to a larger size during snapshot removal process (56608)
https://kb.vmware.com/s/article/56608?lang=ja
これによると、「一連の手順を実行すると、シンプロビジョニングされた仮想ディスクのディスク使用量が増加することがある。」という迷惑なもの。VMFS6のデータストアを使用しているので、これに該当したようだ。Windows Serverのバージョンは、Windows Server 2012以降ということなので、影響するOSは多い。
とても厄介。
VMware vCenter Converter Standalone 6.2 でWindows Server 2003 を仮想マシンに変換しようとしたところ、Agentのデプロイで「Error code: 1,603」でエラーになった。
サポート範囲を調べてみると、Windows Server 2003は、Windows Server 2003 R2 SP2がサポート対象で、R2が付かないバージョンはサポート対象外だった。
サポート外だが、無理やりP2Vできなかと、Converter Agentだけのインストールをためしてみたが、サービスをオンにするところで、失敗してロールバックした。
調べてみると、VMware vCenter Converter Standalone 5.0 であれば、無印のWindows Server 2003にインストール可能。試してみたところ、5.0であればインストールはできた（過去にインストーラーを取得しておいてよかった）。しかし、VMware vCenter Converter Standalone 6.2からの接続は、接続経路の暗号化方式の不一致により、エラーになった。
今度は、vCenter Converter Standalone 5.0 から、ESXi6.7に対して、P2V先を指定してみたが、これも通信時の暗号方式の問題で接続できずエラーになった。
Veeam Backupのエージェントを、Windows Server 2003（無印）にいれて、イメージバックアップして、そのイメージを仮想マシンとして復元する方法も試した。Veeam BackupもVersion 9.5でも.net frameworkのバージョンが古すぎて、Windows Server 2003（無印）にエージェントのインストールができず。イメージバックアップを取得して、仮想マシンとしてリストアする方法についても失敗した。
そのため、vCenter Converter Standalone 5.0を使って、Windows Server 2003（無印）を一度、VMware Workstation形式の仮想ファイルに変換した。次に、このVMware Workstation形式のファイルを、vCenter Converter Standalone 6.2で指定し、V2V（Virtual to Virtual）で、ESXi6.7に対して保存した。これで、なんとかP2Vは成功した。ネットワークの設定などは、変わっているため、仮想マシンの設定を編集して、新しくネットワークインターフェースの割り当てを行った。これで無事にWindows Server 2003（無印）のP2Vは完了した。
仮想化すれば延命はできるが、物理サーバとして存在していると、そもそもP2Vでの仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。
ESXiのデータストアのVMFSのバージョンを、vSphere Clientで行う方法。
vSphere Client （ウェブ版）
vSphere Client （クライアント版）
PowerCLIは、WindowsのPowershellを使って、ESXiなどのvSphereを管理するツール。これのバージョン情報は、「Get-PowerCLIVersion」で表示できる。
PowerCLI C:\> Get-PowerCLIVersion PowerCLI Version ---------------- VMware PowerCLI 6.5 Release 1 build 4624819 --------------- Component Versions --------------- VMware Cis Core PowerCLI Component 6.5 build 4624453 VMware VimAutomation Core PowerCLI Component 6.5 build 4624450 VMWare ImageBuilder PowerCLI Component 6.5 build 4561891 VMWare AutoDeploy PowerCLI Component 6.5 build 4561891 VMware Vds PowerCLI Component 6.5 build 4624695 VMware Cloud PowerCLI Component 6.5 build 4624821 VMware HA PowerCLI Component 6.0 build 4525225 VMware HorizonView PowerCLI Component 7.0.2 build 4596620 VMware Licensing PowerCLI Component 6.5 build 4624822 VMware PCloud PowerCLI Component 6.5 build 4624825 VMware Storage PowerCLI Component 6.5 build 4624820 VMware vROps PowerCLI Component 6.5 build 4624824 VMware vSphere Update Manager PowerCLI 6.5 build 4540462
ESXi6.0を再起動したとき、ESXiの時間が現在よりも9時間早い時間（9時間の未来）に設定されていた。 そのため、該当のESXiの上に仮想マシンをvMotionさせたときに、仮想マシンの時間が9時間早い時刻になった。
いろいろと調べたところ、ESXiの設定要件として、BIOS上の時間をUTCで設定する必要がある。 これは、ESXiがBIOSの時間を設定にかかわらず、UTCとして認識するため。ESXiにタイムゾーンが設定されている場合は、その時間に合わせて設定されるため、時間がずれる。
まとめると、下記。
ESXi 5.1から仮想マシンをエクスポートして、ESXi6.7にデプロイしたとき、下記のエラーが表示されて、デプロイが失敗した。
参照するオブジェクトまたはアイテムを検出できませんでした。 OVF パッケージのデプロイに失敗しました。
何度もエクスポートしたが、同じ仮想マシンだけ同じエラーでデプロイが失敗する。 そのため、エクスポートされたOVFファイルの内容をチェックしていたところ、仮想マシンの設定の中で、 CD/DVDの項目のところに、接続はされていないものの、データストア上のISOファイルが指定されていた。 このISOファイルは、デプロイ先には存在しないため、デプロイのとき、OVFファイルの中身を展開したときに、 このISOファイルのところでエラーになり、デプロイが失敗しているようだ。
試しに、ISOファイルをマウントされていない状態で行ったところ、無事にデプロイに成功した。
ESXiの仮想マシンのCD／DVDドライブでISOファイルを指定したまま、エクスポートするとデプロイ時に同じ場所にそのISOファイルがないと、エラーになることがわかった。
vCenter Serverの起動時に下記のアラートが、vCenter Serverが通知してくる。
CPU Exhaustion on vcenter
調べてみると、vCenter Server のCPUが消耗している（＝負荷が高くて、使いきっていた）状態であることを通知していた。vCenter Serverの起動後、暫くすると（10分ちょっと）、アラートは消えた。CPU負荷が高い状態で「CPU Exhaustion on vcenter」が発生する。
同様にメモリに負荷が増えたときは、「MEMORY Exhaustion on vcenter」が発生する。
これらは、vCenter Serverの監視のアラーム設定で定義されている。