Veeam Backupで取得するVMware vSphere環境の変更を行った。新しい環境のバックアップを行ったところ、別の仮想サーバとして認識され、使用されるライセンス数が2倍になった。
Inventoryで不要なサーバを削除しても使用されるライセンスは減らない。（Inventoryで不要なサーバを削除するためには、利用されているバックアップタスクの削除も必要）
不要なサーバで、使用されているライセンスを減らすには、以下の作業でライセンス割り当てを解除する。
1. Veeam Backup の管理コンソールを開く
2. メニューからライセンス（License）を開く
3. 「Instances」のタブを開く
4. 「Manage…」をクリックする
5. ライセンスを使用しているサーバの一覧が表示されるので、NameとHostをみて、不要になったサーバを選択して、「 Revoke」をクリックする
6. 「Revoke」のところ、不要な台数だけ繰り返す。
7. 終わったら、OKで閉じていく。
Veeam Backupで仮想基盤のバックアップを取得している場合、vCenter Server や、ダイレクト登録しているESXiを入れ替えて、仮想マシンを移行すると、同じ仮想マシン名でもVeeam Backup上は別のVMとして認識される。そのため、既存のバックアップタスクでは、移行先のホストをVeeam Backupに登録しても、バックアップ対象の仮想マシンは切り替わらない。
新しい仮想基盤にVMを移行させた場合は、Veeam Backupのバックアップタスクで、バックアップ対象となるVMを、指定しなおす必要がある。具体的には、個別のタスクで旧ホスト側のVMを削除して、新しいホストのVMを指定しなおす。このとき、別VM扱いになるので、バックアップ容量は気を付ける必要がある。
今月の1日（5月1日）から始まったVMwareアカウントからBroadcomアカウントへの移行は、やっと終わったみたいである。
まだ、移行中のメッセージは表示されているが、保有ライセンスは表示される。ライセンスのバージョンアップグレードは、怖くて試していないがメニューはある。ソフトのダウンロードはできた。概ね、ライセンスの移行は終わったようだ。
vCenter Server Applianceで、アラート表示として、”/storage/archive/” の使用量警告がでる。
この使用量のアラートは、動作には影響がないとのこと。公式のナレッジによると、誤った警告表示で、仕様だとか。
https://kb.vmware.com/s/article/57829?lang=ja
100%まで使用するとどうなるかというと、もともと容量を100%まで使い切る使用で、いっぱいになると自動的にクリーンアップされるとのこと。公式のナレッジには、次の記述がある。この警告については、無視するかない。
/storage/archive パーティションは、仕様で残り容量がなくなるまで使用できるため、この問題が vCenter Server のいずれかの操作に影響することはありません。
このボリュームには、可能な限り多くの WAL 履歴が保存されます。アーカイバ サービスによって自動的にクリーンアップされるときは、最も古い WAL セグメントが自動的に削除されます。
vCenter Server 6.7 だけでなく、vCenter Server 8.0系でも発生するとのこと。
VMwareアカウントが、Broadcomアカウントに移行されるという通知が来たのが4月末ごろ。日本のゴールデンウィーク期間にBroadcomアカウント側にライセンスなどが移行されるとされていたのだが、まだ終わっていないようだ。Broadcomのアカウントでログインすると、まだ移行中であることが表示されている。メンテナンスの期間は終わっているはずなんだが。保有ライセンスも、ライセンスキーも、アップグレードもできないので、早く移行が終わってほしい。
Xの投稿をみていると、ユーザによっては、GWの期間に通知されたようで。休みの間にVMware側のアカウントが使えなくなっているとか。いまに始まったことではないが、Broadcomの対応は急というか雑というか、ひどいものだ。
VMware Toolsのバージョンアップ後、Windowsの画面解像度の変更ができなくなった。かつ、VMware Toolsの入れ替え前と比べて、解像度もひくくなった。
これの対応としては、ESXiやvCenterで、仮想マシンのビデオカードの設定を、「設定の自動検出」に変更する。
1. vCenter ServerまたはESXiのウェブUIにログインする。
2. 該当の仮想マシンをシャットダウンする。
3. 「設定の編集」をクリックする
4. ビデオカードの設定を開いて、「設定の自動検出」を選択する。
5. 保存して、仮想マシンを起動する。
6. 仮想マシン（Windows）にログオンして、画面解像度を変更する。
BroadcomによるVMwareの買収が完了したとのこと。カスタマー向けのお知らせメールも届いた。
https://www.broadcom.com/blog/broadcom-announces-successful-acquisition-of-vmware
はっきり言って、この先が不透明。オンプレ用のESXiは提供はされ続けるだろうけれど、新機能などはどうなるだろうか。枯れたシステムとして、保守されていくような気がしてならない。あとは、サポートの質がさらに悪くなる気がする。保守やライセンス継続のコストも心配なわけで。
Symantec Endpoint ProtectionがBroadcomの配下になったときも、めちゃくちゃ使いにくくなった。というか、管理サイトやサポートサイトへのログインがめんどくさいことになった。この先の一年くらいで同じようになるのではないかと考えると、微妙な気持ちになる。
VMwareのESXi以外となると、Hyper-Vか、Linux KVMか、Xenか。Windows OSを利用することを考えると、管理面を考えなければ、Hyper-Vなんだろうな。
VMware（vSphere）のDRS環境で、同じホスト（同じハードウェア）で稼働させたくないサーバ群がある場合は、アンチアフィニティルールを設定する。
アンチアフィニティルールを使うことで、クラスタを組んでいるサーバが同一のハードウェアで稼働しないようになる（仮想サーバ間の稼働ホストの排他制御のようになる）。これにより、ホストの物理サーバで障害が発生しても、クラスタを組んでいるサーバが一斉にダウンするということは避けられる。クラスタを組んでいなくても、ホットスタンバイのサーバも同時にダウンすることをアンチアフィニティルールの設定でさけることができる。
アフィニティルールのマニュアル
https://docs.vmware.com/jp/VMware-vSphere/8.0/vsphere-resource-management/GUID-94FCC204-115A-4918-9533-BFC588338ECB.html
VMware Toolsの脆弱性の評価は、CVSSv3基本スコアで、CVE-2023-34057は「7.8」（Important）。ゲスト仮想マシンへのローカルユーザーアクセスを持つ悪意のある攻撃者が、仮想マシン内の権限を昇格できる可能性があるとのこと。
「VMware」のゲストOS向けアプリ「VMware Tools」に重大な脆弱性 ～対策版への更新を – 窓の杜 (impress.co.jp)
https://forest.watch.impress.co.jp/docs/news/1543401.html
脆弱性が修正されたバージョンへのVMware Toolsの更新が必要。
対象となるVMware Toolsのバージョン 12.xx、11.xx、10.3.x
脆弱性対応されたバージョン 12.3.5
https://www.vmware.com/security/advisories/VMSA-2023-0024.html
ダウンロードのURLは下記。ダウンロードには、VMwareのCUSTOMER CONNECTのアカウントが必要。
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にインストールできない。