タグ: vCenterServer

  • VMwareのサブスクリプションライセンスが切れたときの影響

    VMwareのサブスクリプションライセンスが切れたときの影響を調べた。2025年秋に更新されていた。

    結論としては、サブスクリプションライセンスに切り替えていると、サブスクリプションライセンスの期間が過ぎると、まともに使えない。vCenterは使えなくなる、ESXiは稼働を続けるけれど、仮想サーバの電源ONはできなくなるので、仮想サーバの電源が落ちたら、そこでおしまい。

    もう、Broadcom税というか、システムを人質にとられているような印象を受ける。ライセンス料が安いのならば、これでもいいのだけど、高額なのがなんとも複雑だ。

    ■1つめ

    https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vcenter-and-host-management-8-0/license-management-host-management/licensing-for-products-in-vsphere-host-management.html

    ESXi ホストのライセンスと評価期間の有効期限

    ESXi ホストの場合、ライセンスまたは評価期間が期限切れになると、ホストが vCenter Server から切断されます。パワーオン状態のすべての仮想マシンの実行は継続されますが、パワーオフ状態の仮想マシンをパワーオンすることはできません。使用中の機能の現在の設定を変更することはできません。ライセンスが期限切れになる前に使用していない機能は使用することはできません。

    有効期限のあるライセンスの場合、ライセンスが期限切れになる 90 日前に通知が表示されます。

    ■2つめ

    https://knowledge.broadcom.com/external/article/397471/vcenter-esxi.html

    ESXiホストライセンスの有効期限が切れた場合:

    vSphere Client 上でホストが切断状態になります。

    このホスト上の仮想マシンは vSphere Clinet でも切断されます。したがって、ホストとその仮想マシンはすべて切断されているため、それらに対してアクションを実行することはできません。

    ホストUIへのアクセス(ブラウザからこのホストのIPアドレスに直接接続)は問題ありません。

    実行中の仮想マシンは引き続き使用できますが、以前にシャットダウンされた仮想マシンはパワーオンできません。

    仮想マシンの作成は問題ありませんが、電源を入れると失敗します。

    vCenterライセンスの有効期限が切れた場合:

    vSphere Client 上のすべてのホストとその仮想マシンが切断されます。

    vCenter からホストを削除することはできますが、vCenter にホストを追加すると失敗します。

  • vCenter Serverから証明書更新のアラートがでたときの対処

    vCenter Serverから下記の証明書更新のアラートがでたときの対処について。

    [Critical] Alarm alarm.CertificateStatusAlarm on Folder Datacenters
    because Certificate 'C=US,CN=hostname' from 'MACHINE_SSL_CERT' expires on YYYY-MM-DD hh:mm:ss.000.

    下記URLのナレッジで更新する。GUIでできるので楽。

    vSphere Client を使用した新しい VMCA 署名付き証明書への VMCA 証明書の更新 https://techdocs.broadcom.com/jp/ja/vmware-cis/vsphere/vsphere/8-0/vsphere-authentication-8-0/vsphere-security-certificates-authentication/managing-certificates-with-the-web-interface-authentication/renew-all-certificates-from-the-psc-web-interface-authentication.html

  • vCenter Server Appilanceにパッチを適用する手順

    vCenter Server Appliance 8.0 u2にパッチをあてたので、その作業のメモ。

    1. ISOファイルをBroadcomのサポートページからダウンロードする。

    2. vcenter appliance  がアクセスできる領域にISOをアップロードする

    3. ISOファイルをvSphereの操作としてマウントする

    4. SSHで、vcenterにアクセスする(root権限のあるユーザを使う)

    5. パッチをステージングする(このコマンドはBashモードにはない。Bashは起動させずに、sshでログインした最初の状態で行う)

    software-packages stage --iso

    6. ステージングされたパッチのリストを確認する。見るだけなので、気にならなければ、手順を飛ばしても良い。

    software-packages list --staged

    7. ステージングされたパッチをインストールする。(ここは時間がかかった)

    software-packages install --staged

    8. 再起動を求められる場合は、vCenter Server Appliance を再起動する

    shutdown now -r "patch reboot"

    これで完了。

    参考: https://docs.vmware.com/jp/VMware-vSphere/8.0/vsphere-vcenter-upgrade/GUID-3E7C2187-42A4-4DD4-9EC8-80D8B0077F82.html?hWord=N4IghgNiBcIApgC4GMAWBLAdgcwASNQFNcA3AYUM0UICdcBlWk23AQQAd2J0xNlCQAXyA

  • CLIでvCenter Server Applianceのバージョンを調べるコマンド(APIコマンド)

    CLIでvCenter Server Applianceのバージョンを調べるコマンド(APIコマンド)は、下記。SSHでログインした後に実行する。

    com.vmware.appliance.version1.system.version.get

    実行例

    Command> com.vmware.appliance.version1.system.version.get
    Version:
       Version: 8.0.2.00400
       Product: VMware vCenter Server
       Build: 23929136
       Type: vCenter Server with an embedded Platform Services Controller
       Summary: Patch for VMware vCenter Server 8.0
       Releasedate: June 13, 2024
       Installtime: 2024-07-11T02:22:34.170Z
    
    Command>

    セッション切れでの失敗例

    Command> com.vmware.appliance.version1.system.version.get
    Session expired.
    
    Command>
  • vCenter Server Applianceで「/storage/archive/」の使用量警告がでる

    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系でも発生するとのこと。

  • vSphere 8.0のvCenter Serverのインストーラーのシステム要件

    vSphere 8.0の vCenter Serverのインストーラーを動作させることができるOSは、下記のインストール資料に載っている。

    https://docs.vmware.com/jp/VMware-vSphere/8.0/vsphere-vcenter-801-installation-guide.pdf

    vCenter Serverのインストールとセットアップ – VMware vSphere 8.0
    19ページ。

    インストーラーがサポートされているOSとシステム要件を抜きだすと、下記。

    • Windows OS
      • サポートされているバージョン
        • Windows 10、11
        • Windows 2016 x64ビット
        • Windows 2019 x64ビット
        • Windows 2022 x64ビット
      • 最適なパフォーマンスを得るために最低限必要なハードウェア構成
        • 4 GB RAM、2.3 GHz の 4 コア CPU(× 2)、32 GB ハード ディスク、NIC(× 1)
    • Linux
      • サポートされているバージョン
        • SUSE 15
        • Ubuntu 18.04、20.04、21.10
      • 最適なパフォーマンスを得るために最低限必要なハードウェア構成
        • 4 GB RAM、2.3 GHz の 2 コア CPU(× 1)、16 GB ハード ディスク、NIC(× 1)
        • CLI インストーラには 64 ビット OS が必要です。
    • Mac
      • サポートされているバージョン
        • macOS 10.15、11、12
        • macOS Catalina、BigSur、Monterey
      • 最適なパフォーマンスを得るために最低限必要なハードウェア構成
  • vCenter ServerのイベントでvmsyslogcollectorがRed判定される

    vCenter Serverのヘルスチェックのアラームで、「vmsyslogcollector」がRedとして判定されることがある。通知されるアラートとしては下記。

    [VMware vCenter Server - アラーム alarm.HealthStatusChangedAlarm] vmsyslogcollector のステータスが green から red に変更されました

    vCenter Server上に、vmsyslogcollectorがRedの状態(サービスが落ちっぱなし)で残り続けなければ、放置でよし。vCenter Serverでの健全性チェックとローテーションのタイミングが重なったことで、vmsyslogcollectorのこの検知が発生することがある。vmsyslogcollectorがログローテーションなどを行うサービスなので、ローテーションのタイミングであり得るわけだ。

  • VMware vCenter Converter Standalone 6.2 でWindows Server 2003 の変換がエラーになる。

    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での仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。

  • Windows版のvCenter Server 6.7は、”CVE-2021-22005”の影響を受けない。

    VMwareのKBを見たところ、Windows版のvCenter Server 6.7は、”CVE-2021-22005”の影響を受けないとのこと。Windows版のvCenter Serverが存在するのは、6.7まで。

    https://kb.vmware.com/s/article/85717

    なお、 vCenter Server Appliance (vCSA)での暫定対処(影響の軽減方法)については、上記のKBにやり方が記載されている。