ad1

ラベル ESXi の投稿を表示しています。 すべての投稿を表示
ラベル ESXi の投稿を表示しています。 すべての投稿を表示

2025年7月4日金曜日

エンタイトルメントのないアカウントでの VMware ESXi ・ vCenter のパッチダウンロード方法 (復刻版)

 3月に書いた記事、「2025年3月以降の vSphere ESXi ・ vCenter のパッチダウンロードとアップデート方法」で解説しましたが、
2025年2月末の Broadcom Support Portal サイトのシステム変更でソフトウェアダウンロードの仕組みに変更が入り、Broadcom Support Portal サイトを経由でのソフトウェアのパッチファイルのダウンロードが一部制限が入りました。

その結果、以前は可能だった「製品エンタイトルメントのないアカウント」、「製品 SnS、サブスクリプションの期限が切れたアカウント」でのパッチダウンロードが不可となってしまいました。

これらの制限については、6月辺りから再び緩和され、VMSA で報告される Severity  : Critical な脆弱性に関する修正パッチは、エンタイトルメントのないアカウントでもダウンロードできるようになりました。


今回の修正により、もともと昨年に CEO の Hock Tan が Blog : A changing market landscape requires constant evolution: our mission for VMware customers で表明していた

"To ensure that customers whose maintenance and support contracts have expired and choose to not continue on one of our subscription offerings are able to use perpetual licenses in a safe and secure fashion, we are announcing free access to zero-day security patches for supported versions of vSphere, and we’ll add other VMware products over time."

、および

KB : Zero Day (i.e., Critical) Security Patches for vSphere (7.x and 8.x) Perpetual License Customers with Expired Support Contracts にて説明されている Severity : Critical - CVSS Score 9 以上の脆弱性に関するパッチの提供が再開されたことになります。


修正パッチのダウンロードリンクにアクセスする方法は主に以下2つ

それぞれ簡易に紹介します。

※ どちらのパターンも事前に有効な Broadcom Support Portal のアカウントを作成し、必要情報を入力して Profile を完成させておきます。

2025年4月14日月曜日

vSphere Hypervisor (無償版 ESXi) の提供再開と入手方法、通常版との比較

2025年4月10日(日本時間11日)に公開された ESXi 8.0 U3e (P05) のリリースノートに、vSphere Hypervisor (無償版の ESXi)の提供再開が追記されました。

Broadcom makes available the VMware vSphere Hypervisor version 8, an entry-level hypervisor. You can download it free of charge from the Broadcom Support portal (https://support.broadcom.com/group/ecx/free-downloads).

※ 4/15 追記 : KB の説明に若干の追記があったので以下参照

Broadcom makes available the VMware vSphere Hypervisor version 8, an entry-level hypervisor. 
No Broadcom support is available for this offering and it is for non-production use. vSphere Hypervisor cannot connect to vCenter and therefore cannot be centrally managed. 
You can remotely manage individual vSphere Hypervisor hosts by using the VMware Host Client. vSphere Hypervisor supports a maximum of 8 virtual CPUs per virtual machine. 
You can download it free of charge from the Broadcom Support portal (https://support.broadcom.com/group/ecx/free-downloads).

※ 元々 vSphere Hypervisor の提供は Broadcom による VMware の買収完了後に提供が終了となっていましたが、改めて提供方法を変更して再開されました。

本投稿では再開された vSphere Hypervisor のバイナリの入手方法、通常版の ESXi との違い、従来の vSphere Hypervisor との違いなどを解説します。

本投稿の内容

vSphere Hypervisor (無償版の ESXi) の入手方法

前回の投稿「2025年3月以降の vSphere ESXi ・ vCenter のパッチダウンロードとアップデート方法」の冒頭で記しましたが、2025年2月末の Broadcom サポートポータルのソフトウェアの配布方法の変更により、有効なサブスクリプションを持つユーザーがダウンロードできるソフトウェアと、フリーで提供されるソフトウェアのダウンロードが明確に分けられました。

昨年末に無償化された VMware Workstation Pro や Fusion Pro はフリーで提供されるソフトウェアに分類されていましたが、今回の vSphere Hypervisor も同様のカテゴリにて配布されます。

Broadcom サポートポータルのアカウントが未作成の場合は作成してください。Gmail などフリーメールアドレスを利用したアカウントの場合も、今回の vSphere Hypervisor や VMware Workstation Pro など無償化された製品はダウンロードできます。


Broadcom サポートポータルの「My Download」を開くと、従来はサブスクリプションのエンタイトルメントを持たないアカウントでも全製品の一覧が表示されましたが、2025年3月以降は非表示となります。

Free Software Downloads available HERE のリンクをクリックし、https://support.broadcom.com/group/ecx/free-downloads を開きます。

VMware 以外のソフトウェア製品も表示されるのでフィルタする場合は Division 欄で VMware のチェックを入れるか、


Product Name を "VMware" などで絞り込んでください。 Workstation Pro や Fusion Pro に並んで、下の方に "VMware vSphere Hypervisor" がリストされます。
※ 今回、併せて "VMware vSphere ESXi Drivers" も追加されました。


2025年4月11日時点では Release Note にある通り、ESXi 8.0U3e (P05) のみが表示されています。


再公開された vSphere Hypervisor のダウンロードは ISO イメージのインストーラファイルのみが公開されており、オフラインバンドル (オフラインデポ)の Zip ファイルは無いようです。

ダウンロード直リンク

右側の雲のアイコンをクリックしてダウンロードできます(初めてダウンロードするときは "I agree to theTerms and Conditions" のチェックボックスが表示されるのでエンドユーザー規約を確認の上、チェックを入れてください)。


アカウントに住所設定がされていない場合、製品輸出入規制の制約に関連して、アカウントに国、住所などの連絡先が設定されてる必要があるためメッセージが表示されます。画面に沿って必要事項を入力してください。


"I agree to theTerms and Conditions" を以前にチェックしている場合はそのままダウンロードできるはずです。

ここでダウンロード可能な vSphere Hypervisor の Build 番号は、Release Note に書かれている 24674464 と異なり、24677879 と表示されています。この違いについては後述します。

ISO イメージがダウンロードできたら、今まで通りインストーラとして初期セットアップに利用したり、既存の vSphere Hypervisor のバージョンアップに利用できます。

通常版の ESXi と vSphere Hypervisor は何が違うのか?

落とした ISO を比べてみると無償版の vSphere Hypervisor のほうが Build No が大きく、ファイルサイズも僅かに大きい。

  • (通常版) VMware-VMvisor-Installer-8.0U3e-24674464.x86_64.iso 648341504
  • (無償版) VMware-VMvisor-Installer-8.0U3e-24677879.x86_64.iso 648374272

通常版の ESXi 8.0 U3e は Build No 24674464 でファイルサイズは 648,341,504 Byte、無償版の vSphere Hypervisor ESXi 8.0 U3e は Build No 24677879 でファイルサイズは 648,374,272 Byte

Metadata 内の BaseImage のコンフィグを見比べるとコアパッケージと一部のドライバ周りで9個ほどそれぞれの Build No のものがありますが、基本的には同一のようです。

イメージプロファイルも同じように Build No 入りで別のプロファイルです。

  • ESXi-8.0U3e-24677879-standard
  • ESXi-8.0U3e-24677879-standard

vSphere Hypervisor (無償版の ESXi) のライセンス状態

無償版 ESXi 8.0U3e は新規インストールすると無期限の vSpehre Hypervisor ライセンスが適用された状態で起動します。

機能は従来の vSphere Hypervisor と同じく、8 vCPU までの VM をサポートする制限がかかっています。当然、vCenter Server 配下iに登録することなどはできず、Standalone での利用が前提です。

※ ライセンスキーは無償版とはいえ直接公開するのはよろしく無いので各自で確認してください。

デフォルトで入っている vSphere Hypervisor ライセンスキーを削除すると、期限切れの状態となり、仮想マシンの作成・起動含めた操作ができなくなります。

新規インストールした際の 60日評価モードは利用できないので、それらが必要な場合は通常版のインストーラを利用します。


再度、vSphere Hypervisor のライセンスキーを当て直したり、別の商用ライセンスキーを適用することは可能です。

vSphere Standard や vSphere Foundation などのライセンスキーを適用すれば通常の ESXi と同じく vCenter Server に組み込めます(商用ライセンスキーの適用はサポートされる構成です)

ちゃんと機能も限定解除されます。

Build No、イメージプロファイルが通常版とは異なりますが、今後パッチを適用する際にプロファイルを更新することで Build No も通常版と同じになります。

vSphere Hypervisor (無償版の ESXi) の ISO を利用したバージョンアップ時の操作、注意点

再公開された vSphere Hypervisor (無償版の ESXi) は ISO イメージのインストーラのみで、Zip のオフラインバンドルはありません。

既存で利用している vSphere Hypervisor をバージョンアップする際には ISO をマウントしてホストの再起動からアップデートを適用する方法で対応します。

※ ISO インストーラのみの提供なので、個別のドライバ VIB などをインストールしている既存環境の場合、バージョンアップができない場合があります。

ESXi 8.0.x (ライセンス適用済み) に無償版 ESXi 8.0U3e を適用してみる

ライセンスが適用された ESXi 8.0.x、または 60日評価モード期間中の ESXi 8.0.x に無償版 ESXi 8.0U3e を適用した場合、元のライセンスキー、または評価モード状態が維持されます。

試しに ESXi 8.0U3 (ESXi-8.0U3-24022510-standard) に vSphere Foundation のライセンスを当てて無償版 ESXi の ISO でバージョンアップしてみます。

60日評価モードの ESXi 8.0U3

VVF ライセンス適用後の ESXi 8.0 U3

無償版 ESXi 8.0U3e の ISO イメージをマウントして再起動、アップグレードを実行


バージョンアップを実行後のイメージプロファイルは ESXi-8.0U3e-24677879-standard に更新されています。

バージョンアップ前に適用したライセンスは維持されます。

なお、60日評価モードを利用している ESXi をバージョンアップした際は評価モードの残日数が引き継がれます。

ESXi 7.0.x (ライセンス適用済み) に無償版 ESXi 8.0U3e を適用してみる

ESXi 7.0.x に vSphere Hypervisor ライセンスを適用した状態で無償版 ESXi 8.0U3e の ISO イメージを利用してバージョンアップしてみます。



ISO からバージョンアップします。


メジャーバージョンアップなので、評価モードに戻るよ、のメッセージ。

メジャーバージョンアップ完了後、イメージプロファイルは ESXi-8.0U3e-24677879-standard に更新されています。

ESXi 7.0.x のラインセンスは ESXi 8.0.x では利用できないので 60日評価モードで起動します。これは元々の通常版 ESXi でのメジャーバージョンアップ時の挙動です。


vSphere Hypervisor のライセンスが適用された状態では起動しないので要注意。 無償版 ESXi 8.0U3e の vSphere Hypervisor ライセンスキーが必要な場合は、空き PC や Nested ESXi 上にインストールして、ライセンスキーをコピーしておいてください。

60日評価モード状態で vSphere Hypervisor で利用できること以上の設定を行うと、vSphere Hypervisor ライセンスキーの適用ができないので注意してください。キーを当てる場合は当該機能の設定を初期値に戻す必要があります。

ESXi 6.7.x (ライセンス適用済み) に無償版 ESXi 8.0U3e を適用してみる

ESXi 6.7.x からのバージョンアップも ESXi 7.0.x のときと同様です。

ESXi 6.7 以前と ESXi 7.0.x 以上では ESXi 起動領域のパーティションレイアウトが異なるため、アップグレード時のメッセージが異なります。


再起動後、ESXi 8.0U3e は評価モードで起動します。vSphere Hypervisor ライセンスキーが必要な場合は前述した通り、別途新規でインストールした環境からキーをコピーします。

vSphere Hypervisor (無償版の ESXi) の機能制限、利用規約

機能制限

vSphere Hypervisor の機能制限は従来通りで、Standalone で動く前提のため vCenter Server への接続はできず、vCenter Server が提供する機能 (Clone、vMotion、HA など) は利用できません。

仮想マシンの作成 (1VM 辺り 8 vCPU まで)、削除、起動・停止、Snapshot の取得、OVF のインポート・エクスポートはサポートされます。

ESXi として標準スイッチ (vSS) を利用した NIC チーミング、外部ストレージのマウンドなどはサポートされます。 

PowerCLI や REST など API での仮想マシン操作などは非サポートなので要注意。

利用規約

EULA (End User License Agreement) は ESXi の以下で確認できます。

/usr/lib/vmware/weasel/EULA

内容は非常に長いテキストなので割愛しますが、公開された Web 上では以下の Broadcom の契約ドキュメントサイトに掲載されたものとおそらく同一です。

製品ごとの細かいライセンス仕様については SPD (Product Specific Documentation) に記載があるのですが、vSphere Hypervisor としてのカテゴリは現状無いようです。

Workstation Pro や Fusion Pro は VMware Desktop Hypervisor Pro として SPD があるので、これに準拠するのか? 情報が追加されたら追ってここにも記載します。



2025年3月17日月曜日

2025年3月以降の vSphere ESXi ・ vCenter のパッチダウンロードとアップデート方法

Broadcom Support サイトからのソフトウェアアップデートのダウンロード制限

※ 本投稿はサポート契約・エンタイトルメントを持たないホームラボユーザー向けに書いています。

※ 2025/6/16 Update
2025年2月末の Broadcom Support の仕様変更により、有効な製品エンタイトルメント、SnS が無いアカウントでのパッチダウンロードが不可となりましたが、VMSA に報告された深刻な脆弱性に関してのパッチファイルは、VMSA に掲載されたリンク経由で、エンタイトルメントのないアカウントでもダウンロード可能に戻りました。

また、該当するアカウントで Broadcom Support の My Download にアクセスし、Free Downloads > VMware vSphere > Solutions にアクセスすることで、VMSA 経由で公開された分のパッチファイルのダウンロードにもアクセス可能になりました。


※ 2025/3/24 Update
本投稿で利用している公開オンラインリポジトリは 2025/4/23 以降は利用不可となります。今後はトークンを利用した各アカウントごとの URL を vCenter などに設定して運用する形となります。

参考 :

SBCS の平田さんがわかりやすい記事を日本語で書いてくださいました。

----

2025年2月末の Broadcom Support からのソフトウェアダウンロードの仕組みに変更が入り、Broadcom Support サイトを経由でのソフトウェアのパッチファイルのダウンロードが一部制限が入りました。

具体的には

  • 有効な製品エンタイトルメント、SnS が無いアカウントでの Broadcom Support サイトからのアップデート用ファイルのダウンロードが停止
  • Gmail などフリーメール(非企業メールアドレス)を利用したアカウントでの Broadcom Support サイトからのアップデート用ファイルのダウンロードが停止
    ※ もともとフリーメールでアカウントを作成している場合には Site ID やエンタイトルメントの設定ができませんが、ESXi のパッチファイルなどは Broadcom Support からダウンロードできた
  • 2025/6/16 Update
    有効な製品エンタイトルメント、SnS が無いアカウントでのパッチダウンロードができなくなっていましたが、VMSA に報告された深刻な脆弱性に関してのパッチファイルは、VMSA に掲載されたリンク経由で、エンタイトルメントのないアカウントでもダウンロード可能に戻りました。

のような変更が入っています。

サイト上の通知文面を見る限り、ソフトウェア使用許諾に違反した利用が増加しているためシステム改修を進めている様に読み取れます。昨年以降、サードパーティ保守サポートを売りにしたサービスが出てきており、バイナリが非正規ルートで流れている話もコミュニティで見かけるのでその対策でしょうか...

ただ、タイミング悪く、脆弱性 VMSA-2025-0004(CVE-2025-22224、CVE-2025-22225、CVE-2025-22226)がアナウンスされ、脆弱性対応しようにも従来の Broadcom Support からの Offline Depot ファイルのダウンロードが出来なくなってしまいました※ 2025/6/16 Update : 再度ダウンロード可能に戻りました。

この記事では昨年まで提供されていた無償版の vSphere Hypervisor (ESXi) を利用している方々のパッチ適用で不自由も生じているようなので、2025年3月時点の適切なパッチの適用方法をまとめます。アップデートがあり次第、適宜修正は掛けていきます。

※ 2025/4/14 Update

2025/4/10 に公開された ESXi 8.0U3e にて、従来の vSphere Hypervisor (無償版 ESXi) のライセンス組み込みの ISO イメージが全てのユーザー向けに再公開されました。

この ISO イメージを利用した既存 ESXi のバージョンアップも可能となったので、以下に確認した内容をまとめました。

本記事の見出し


【非正規ルートのバイナリ使用の注意】
昨今、vSphere の脆弱性を狙った攻撃が多数報告されていますが、パッチを適用する際には必ず正規ルート(Broadcom Support 経由)のバイナリ、または OEM メーカー経由のもののみを適用してください。
第三者が展開するバイナリは改竄されている可能性が否めないため、使用するのは控えてください。

なお、VMware Workstation Pro や Fusion Pro、vCenter Converter など無償ツールは Free Software としてダウンロードは可能です。

2023年9月20日水曜日

最近の ESXi では以前のクラスタで作成した vSAN パーティションを Host Client の GUI から消せる

最近、お客様の PoC 環境の再構築を手伝う中で気付いたことですが、ESXi 6.7 U3、ESXi 7.0.x と ESXi 8.0.x の Host Client で以前利用していた vSAN データストアの情報が残った vSAN ドライブの中のパーティションを簡単に削除できるようになっていました。
いつからこの機能使えたのだろうか?

今まで esxcli vsan storage remove -u <Disk UUID> コマンドで一つづつ削除したり、 ESXi のインストール時の Kickstart で clearpart --all 仕掛けていた手間を考えたらかなり楽...

ここ数年は Nested 環境で検証することがメインだったので、たまには実機器で検証して手を動かさないとだめですね...

2023年5月29日月曜日

vSphere 8.0 U1・vSAN 8.0 U1 機能強化・アップデート情報

vSphere 8.0 U1、及び vSAN 8.0 U1 が3月に発表され、4月18日に GA され一ヶ月以上経ってしまいましたが整理できてなかったので、今更ながら質問されたときの私自身のポインター用にまとめました。

公式のアナウンス関連はこちら

今回は vSphere、vSAN 以外にも PowerCLI と SRM/vSR と Converter にいい感じの Update が降ってきたのでご紹介

リリースノート

※ その後、2023/6/1 に vCenter と ESXi (特に vSAN) に関しての重大なバグ修正が入った vSphere 8.0u1a がリリースされているので特に既存環境からのバージョンアップ時には 8.0u1a を必ず使用してください。

Core Tech Zone Blog

公式 Blog 系

PowerCLI 関連の Update

Site Recovery Manager と vSphere Replication

今回も個人的に興味を持っている vSphere・vSAN の機能強化についてまとめました。

それぞれのページ内リンクはこちらから

vSAN 8.0 Update 1 で気になる機能強化

  • vSAN Disaggregated Storage (旧称 vSAN HCI Mesh)の機能強化、サポート拡大
    • vSAN ESA の Disaggregated Storage
    • vSAN ストレッチ クラスタの Disaggregated Storage (vSAN OSA)
    • 複数の vCenter Server を使用したクラスタ全体の Disaggregated Storage (vSAN OSA)
  • パフォーマンスの最適化、持続性・柔軟性の向上
    • vSAN ESA Adaptive Write Path
    • vSAN ESA Helper Threads による VMDK 単位の処理能力向上
    • vSAN ESA での持続性コンポーネント (Durability Components)
    • カスタマイズ可能なネームスペースオブジェクト
  • 管理の簡素化
    • vSAN ESA デフォルト ストレージ ポリシーの自動ポリシー管理
    • Skyline Health インテリジェント クラスタの健全性スコア、診断、修正
    • より詳細なパフォーマンス解析 (サンプリング間隔の短縮)
    • VM I/O トリップアナライザーのタスクスケジューリング
  • クラウドネイティブストレージ関連機能の強化
    • ESA におけるCloud Native Storage のサポート
    • Data Persistence Platform (vSAN DPp) の通常 vDS サポート
    • vSAN Direct Configuration を使用した Persistent Volume のシックプロビジョニング

vSAN は ESA (Express Storage Architecture) の機能拡大と旧称 HCI Mesh の vSAN Disaggregated Storage (日本語訳だと"分離されたストレージ"...とかなり変...)の強化が大きなポイント、その他管理系の機能の最適化が実施されました。

vSphere 8.0 Update 1 で気になる機能強化

これ以外にも多々、詳細はリリースノートや公式 Blog を参照願います。
やはり、無印 → U1 だと機能強化項目が多いですね

その他関連するプロダクトの最新情報

2023年5月17日水曜日

UEFI のブートエントリが見つからずにインストールした ESXi が起動できない場合の対処

 半年ほど前に Twitter にて呟いた ESXi 8.0 (or 7.0) が動いていた ESXi に ESXi 6.7 をクリーンインストールし直したら ESXi が起動しなくなってしまった事象について、備忘録としてここにもメモ _φ(・_・

事象

ESXi 8.0 が動作している検証環境 ( Intel Skylake | UEFI )を ESXi 6.7 で再インストール後、ESXi 6.7 が起動してこない、試しに ESXi 7.0u3 をインストールし直すと起動する。

----
Booting from VMware ESXi
Boot Faild : VMware ESXi
----

原因

ESXi 7.0 以降で UEFI の Boot Entry (ブートエントリ) "VMware ESXi" が作成されるようになり、ESXi 6.7 以前に戻した場合も UEFI の Boot Entry "VMware ESXi" を探しに行くが実態がなく起動ができない。

対処方法

詳細は以下の公式ドキュメントに記載がありました

手順的にはサーバー起動時の BIOS (UEFI) の設定メニューから Boot Order (起動順序) の画面を見ていくと、利用できない " Unavalable : VMware ESXi " がエントリされています。
※ PowerEdge Gen14 での例


ESXi をインストールしたデバイスの中を掘り下げて \EFI\BOOT\BOOTx64.EFI を選択。

指定した Boot Entry が一番最初に来るように Boot Order を変更。

無事に起動できました。



以上、普通は遭遇することは無いとは思いますが、検証環境など初期化して使い回す際はご注意ください。




2022年11月22日火曜日

ESXi の Shell コンソールがシリアルポートにリダイレクトされてしまった時の対処

 PoC 検証支援で遭遇した事象の対処方法として覚え書き

最近のバージョンの VxRail の初期化で "Node Image Management Tool" (NIM Tool) を利用してノードの初期化を行うと ESXi の標準の Shell の出力が COM 指定になっている、とのこと。

この状態で ESXi の背面の VGA ポートにディスプレイを接続して DCUI から Alt + F1 で直接 Shell にログインしようとしたり、iDRAC などを利用してリモート KVM にアクセスしようとすると

"Redirecting console to the serial port..."
 

と表示され Shell にログインが出来ません。

別の場所で移設した検証機などを立ち上げたがネットワークの問題などで SSH にログインができない、そんな時に Local Shell にアクセスすることは多々ありますが、この状態ではそれが出来ません。

対処方法

この状態の VxRail は iDRAC で Serial Over LAN が有効になっているようなので、ipmitool などで iDRAC ネットワーク経由で Shell にアクセスが可能です。

ipmitool -H <iDRAC IP / BMC IP> -I lanplus -U <User> -P <Password> sol activate
 

通常のモニタ越しの ESXi Shell だと文字のコピーペーストは不可ですが、Serial Over LAN だと文字のコピペが出来るので案外便利です。

また、Shell の出力を標準ディスプレイに戻すには ESXi の Shell にログインして、

esxcfg-advcfg -s none /Misc/ShellPort
 

で元に戻せます。

※ キーストロークシーケンスでも変更できるので詳細は後述を参照。

現在の設定値のは -g オプションで確認できます。

esxcfg-advcfg -g /Misc/ShellPort
 

これらシリアルポートへの出力の変更は公式ドキュメント "ヘッドレス システムの操作" に詳細が説明されています。

ESXi の Shell や DCUI をシリアル側に出力する方法は、Raspberry Pi など VGA レスの端末に Arm 版 ESXi をインストールした場合などにも役だちます。 

詳細は各ドキュメントを参照して下さい。

# シリアル ポートの切り替え
[ログ モード]   esxcfg-advcfg -s com1 /Misc/LogPort
[シェル モード]  esxcfg-advcfg -s com1 /Misc/ShellPort
[DCUI モード]  esxcfg-advcfg -s com1 /Misc/ConsolePort
[GDB モード]  esxcfg-advcfg -s com1 /Misc/GDBPort

# デフォルトに戻すには -s none をセット
[ログ モード]   esxcfg-advcfg -s none /Misc/LogPort
[シェル モード]  esxcfg-advcfg -s none /Misc/ShellPort
[DCUI モード]  esxcfg-advcfg -s none /Misc/ConsolePort
[GDB モード]  esxcfg-advcfg -s none /Misc/GDBPort

# キーストローク シーケンスでもシリアル ポートの切り替えが可能
[ログ モード] Ctrl+G, Ctrl+B, 1
[シェル モード] Ctrl+G, Ctrl+B, 2
[DCUI モード] Ctrl+G, Ctrl+B, 3
[GDB モード] Ctrl+G, Ctrl+B, ?


2022年10月6日木曜日

vSphere 8.0・vSAN 8.0 機能強化・アップデート情報

発表からだいぶ時間が経ってしまいましたが、8月末に開催された VMware Explore で最新の vSphere バージョンである vSphere 8.0、vSAN 8.0が発表、さらには従来の vRealize 製品群が VMware Aria とブランドが変更される事も発表されました。

※ 毎年晩夏に開催されていた VMware の年次イベント VMWorld が 今年から VMware Explore となりました。

覚え書きを兼ねて公式情報へのリンクと個人的に気になる部分を整理しておきます。

公式のアナウンスはこちら

vSAN 8 関連

Aria・VCF 関連

その他、公式 Blog や Tech Zone に多く記事が上がっているので上記リンクからたどってみて下さい。

今回も個人的に興味を持っている vSphere・vSAN の機能強化についてまとめました。

それぞれのページ内リンクはこちらから

2021年12月24日金曜日

Software Design 誌 2022年1月号 おうちクラウド 第3回 "仮想化基盤を作ってみよう" おまけコンテンツ

 今回はこのブログではなく、執筆を担当した Software Design 誌 2022年1月号 おうちクラウド 第3回 "仮想化基盤を作ってみよう"  の参照情報をまとめた Github 情報と、以前にコミュニティの LT に登壇した際のスライドへのリンクを共有となります。

この企画は Intel NUC などの小型ベアボーンを利用して VM だけではなく Kubernetes などコンテナ環境に対応した自宅ラボを構築するための Tips を連載で紹介するものですが、第3回では vSphere on NUC にフォーカスを当てて紹介しました。

ぜひ、皆様も "逸般の誤家庭" と呼ばれる HomeLab の沼に足を踏み入れてみてください。
きっと逃げられなくなります。





そして時期も丁度良かったので vExperts Advent Calendar 2021 の 12/24 担当分のネタを兼ねています。

Github 上にまとめたものは以前に VMware DevOps Meetup #10 の LT で紹介した以下の資料を再編した形となりますので以下も併せて参照頂ければ幸いです。 


年末年始の自宅らぼ活動の参考になれば幸いです。

2021年6月24日木曜日

仮想マシンの OVF・OVA エクスポートと仮想ディスク形式

先日 VMTN に仮想マシン、仮想ディスクのバックアップ・リストア時のディスクタイプの挙動について質問があり、久しぶりに OVF / OVA への仮想マシンエクスポート・インポートの挙動を試したのでその覚え書き。

※ 2025/2/15 : 旧 VMware Docs、VMware KB のリンクを Broadcom.com に修正

OVF (Open Virtualization Format) / OVA (Open Virtualization Format Archive)

OVF (Open Virtualization Format) は DMTF (Distributed Management Task Force) で規格化された仮想化環境共通の仮想マシンテンプレート形式みたいなものです。
※ 異なる仮想化環境間での仮想マシンの動作互換性を保証するものではありません。

OVF (Open Virtualization Format) は vSphere 環境では以下のファイルで構成されます。

  • .ovf ファイル : 仮想マシンの構成情報、仮想ハードウェア情報などが xml 形式で記載されたファイル
  • .mf ファイル : マニュフェス。各ファイルの SHA ダイジェスト値が記載されたファイル
  • .vmdk ファイル : 仮想ディスク。vSphere ESXi 環境だと VMDK ファイルですが、他の Hypervisor 環境では別形式の場合もあります
  • .nvram ファイル : vSphere ESXi 環境では vSphere 6.7 以降に含まれます。.nvram ファイルが含まれていると 6.5 以前の環境へのインポートに失敗するので、その際は次の KB を参照の上、ファイルの修正をしてください 
OVA (Open Virtualization Format Archive) は上記の OVF の各ファイルを tar で1つに固めたものになり、拡張子は .ova です。
OVA の方が単一ファイルで管理可能で運用が楽なのでお勧めします。

OVF / OVA 形式での仮想マシン・仮想ディスク (vDisk) のエクスポート方法・インポート方法

仮想マシンを起動した状態でバックアップするのであれば、3rd Party のバックアップソフトを使って VADP バックアップを取得する方法や、vSphere Replication や外部ストレージのレプリケーション機能で筐体間コピーする方法がありますが、
今回は無償で利用できる OVF / OVA 形式でエクスポートする方法です。

OVF / OVA 形式でエクスポートするためには対象の仮想マシンは事前にシャットダウン状態 (パワーオフ) にします。 

OVF / OVA 形式に仮想マシン・仮想ディスクをエクスポート・インポートするための以下 4つの方法を紹介します。

  1. vSphere Client (Host Client) を利用する
  2. OVFTool を利用する
  3. PowerCLI を利用する
  4. vCenter Converter Standalone を利用する
それぞれに特徴があり使い易さや機能が異なり、特にインポート時に Thin / Thick など選べる仮想ディスクが異なるものがありますので参考にして頂ければ幸いです。

2020年12月6日日曜日

vSphere クラスタの鉄板構成・サイジングのポイント 2021 年版

 ここ数年、様々なお客様環境のアセスメントを実施して、現状の課題と改善案を説明してきた中で vSphere 仮想化基盤のサイジングに関する考慮点や、性能を最大限かつ安定的に発揮する構成、設計についてディスカッションする機会が多くありました。

vSphere のベストプラクティスを挙げていくとキリがありませんが、それらの中で特にサーバーやストレージの物理のデザインにも関連した内容で頻繁に紹介してきたもの集めてみました。(本投稿の内容は基本的に公式のガイドに沿ったデザインの内容ですが、一部個人の経験に基づく内容もありますのでご了承ください)。

※ 本投稿は vExperts Advent Calendar 2020 の 12/6 分を担当しております。
非常に長文ですが、オンプレミス環境の vSphere クラスタデザインの参考にしていただければ幸いです。

2020年6月15日月曜日

ESXi 6.x 以降でシステムリソースの予約値を変更する方法

vSphere 5.5 (ESXi 5.5) までは vSphere Client で値の変更が出来たシステムリソース(ESXi Kernel のリソース)の予約値ですが、vSphere 6.0 以降では変更が出来なくなってしまいました。
あえて修正しなくてもベストな値が自動で反映されているので通常は修正する必要はありませんが、各 ESXi 毎に予めシステムリソースの予約値を多めに確保しておきたい場合や、ホームラボ用途で予約値を減らしたいという場合もあるので、本記事では PowerCLI を利用して変更する方法を記します。

※ 正式な手順ではないので設定する場合は必ず事前検証、場合によっては各メーカーサポートへの確認を行ってください。変更すると公式サポートが受けられない可能性があります。
※ あと、だいぶ前に見た KB で今見つからなかったのですが、vSphere のバージョンアップ時などに設定がリセットされる事象があったのでもしかしたら今のバージョンでも元に戻る仕様かもしれません。

本記事は LucD さんの VMTN での助言をベースにしています。

システムリソースの予約値とは?

システムリソースの予約とは、ESXi が動作するために最低限確保している CPU とメモリのリソース予約値で vSphere Client からホストを選択し、設定 > システム > システムリソースの予約 を開く事で確認できます。


このシステムリソースの予約、vSphere 5.5 までは vSphere Client の画面上にて編集する事が可能でしたが、vSphere 6.0 以降では vSphere Client では編集が出来ません(上記画面上で編集ボタンがそもそもない)。
※ これは設定に応じて適切な値が自動で予約されており、意図的にリソースを減らされて ESXi Kernel が不安定になる事を防止するために変更されたものと思われます。

今回はこの値を PowerCLI を利用して変更する方法をご紹介します。

2020年4月16日木曜日

ESXi 7.0 で変更されたブート領域(Boot Bank)のパーティションについて

vSphere 7.0 が先週 GA され多くの新機能の情報が出てきておりますが、
本投稿では少し地味に ESXi 7.0 で大きく変更された ESXi のブート領域(ブートバンク, スクラッチ, 診断パーティションその他)について紹介します。
※ 昨年の vFORUM で vSphere Deep Dive のセッションに出られた方はその資料も併せてご覧ください。

追記1 : 2020/5/28 : 公式ブログの方でも詳細解説「vSphere 7 – ESXi System Storage Changes」が掲載されました。
https://blogs.vmware.com/vsphere/2020/05/vsphere-7-esxi-system-storage-changes.html

追記2 : 2020/7/22 : さらにメジャーバージョンアップ時の詳細解説「vSphere 7 – System Storage When Upgrading」が掲載されました。
https://blogs.vmware.com/vsphere/2020/07/vsphere-7-system-storage-when-upgrading.html

追記3 : 2021/1/15 : ESXi 7.0u1c からシステムパーティションのカスタマイズが systemMediaSize オプションで可能になりました KB : Boot option to configure the size of ESXi system partitions (81166)

追記4 : 2021/4/30 : SD カードや USB メモリをブートデバイスとして利用した場合のリスク KB : VMFS-L Locker partition corruption on SD cards in ESXi 7.0 (83376)、耐久性の高い SSD の利用推奨について追記しました

追記5 : 2021/9/17 : 【重要】今後は SD カード、USB フラッシュメディアを利用したブートデバイスが推奨でなくなる (高耐久 SSD が強く推奨) 事が明記された KB が公開されました現在の環境はサポートは継続が続きますが、次期 ESXi バージョン (8.x) 等で SD カードのみ、USB メディアのみで構成されたブート領域は非サポートとなります (OSData 領域をフラッシュメディア以外の領域に要設定)。
KB : Removal of SD card/USB as a standalone boot device option (85685)

ESXi のブート領域(Boot Bank)のパーティションについて

ESXi は VMware ESX 3.5 (この頃はまだ vSphere という名称ではなかった) から登場し、vSphere 5.0 以降では全て ESXi が Hypervisor となり、USB メモリなど小容量デバイスにもインストールできる軽さが特徴でした。
今回、ESXi 7.0 ではそのブート領域のデザインが大きく変更され
環境(自宅ラボなど)によっては、新規に ESXi をインストールする際にインパクトが大きいと思われるので参考にしていただければと幸いです。

ESXi ハードウェア要件の変更

まず、公式ガイドの ESXi ハードウェア要件を見てみます。
ESXi のインストール用デバイスについてはドキュメント上でも明確に記載が変わっており、要約すると以下のようになります。
  • ESXi 6.7 まで
    • 最低 1 GB の起動デバイス
    • VMFS ボリュームと 4 GB のスクラッチ パーティションを起動デバイスに作成するには、5.2 GB 以上のデバイスが必要(HDD/SSD/SAN/iSCSI)
    • SD カード、USB メモリをブートデバイスとする場合はコアダンプパーティションの保存に利用するため 4GB 以上、推奨は 16 GB 以上の高品質のフラッシュドライブの利用が推奨
  • ESXi 7.0 から
    • 最低 4 GB の起動デバイス
    • SD カード、USB メモリをブートデバイスとする場合は 8 GB 以上が推奨
    • HDD、SSD、NVMe などのその他のデバイスでは 32 GB 以上が推奨され、ブート パーティションと ESX-OSData ボリュームが作成されます
    • 128GB を超える HDD、SSD、NVMe ドライブの場合は ブート パーティション、ESX-OSData ボリューム、および VMFS データストアが作成されます
  • ESXi 6.x から 7.0 へのバージョンアップ
    • ESXi 6.x から ESXi 7.0 へのアップグレードには、最低 4 GB のブートデバイスである必要があります。

文字だけだと分かりにくいですが、
恐らく自宅ラボなどで ESXi を利用している方はブートドライブとして SSD, HDD を利用する場合、ESXi のブート領域の余りを VMFS として仮想マシンなどのデータを置く領域として利用しているかと思います。
※ ESXi 6.7 までは 5.2 GB以降は VMFS として利用可能

USB メモリや SD カード、HDD・SSD の表記上の容量は "SI 接頭辞( 1000 で繰り上がる KB,MB,GB,TB,PB)" で表記されていますが、実際にコンピュータの中では "2進接頭辞( 1024 で繰り上がる KiB,MiB,TiB,PiB)" で計算されます。
その為、32GB の SD カードを利用した場合でも実際は 29.8 GiB として認識され、パーティションの構成は 32GB 未満として作成されますのでご注意下さい。

※ この後、図やグラフ、CLI の出力結果に記載している "サイズ" は "GB" 表記ですが "2進接頭辞" での "GiB" を意図しています。

ESXi 7.0 では新しく ESX-OSData ボリュームという VMFS-L フォーマットの新しい領域が作成され、ここにコアダンプやスクラッチなど様々な領域が統合されます。※ VMFS-L は元々 vSAN 用のファイルシステムとして利用されています。
ESXi 7.0 では可変の OSData が 120GiB まで拡張されるため、VMFS として利用できるのは 128GiB 以降となってしまうので注意が必要です

デバイスの種類は、ESXi 7.0 以降でも USB メモリや SD カードをブートデバイスとする事はサポートされますが
BootBank の容量、スクラッチや各種ログの置き場として十分な領域を確保するためには、33GB 以上の M.2 SSD や SSD や HDD を利用する事が推奨されます

※ 2021/4/30 追記
vSphere 7.0u2 のドキュメントに明確に ESXi のブート領域は耐久性の高いフラッシュメディアにインストールするべきと追記されました。
----
ESXi のハードウェア要件
https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.esxi.install.doc/GUID-DEB8086A-306B-4239-BF76-E354679202FC.html
M.2 およびその他の USB 以外の下位のフラッシュ メディアへの ESXi7.0 のインストール
USB フラッシュ デバイスとは異なり、 ESXi インストーラは M.2 およびその他の USB 以外の下位のフラッシュ メディアに、システム ストレージ ボリュームおよび VMFS データストアを作成します。仮想マシンをデプロイしたり、仮想マシンをこの起動デバイス データストアに移行すると、フラッシュ デバイスの耐久性およびワークロードの特性によっては、起動デバイスの老朽化が進む可能性があります。読み取り専用のワークロードでも下位のフラッシュ デバイスで問題が発生する可能性があるため、
ESXi は高耐久性フラッシュ メディアにのみインストールする必要があります
----

パーティションデザインの変更

ここからは細かい話ですが、変更されたパーティションデザインをご紹介します。

ESXi インストール時に作成されるパーティションは ESXi 6.7 までは最大 8 種類のパーティションが切られましたが、
ESXi 7.0 以降では最大 5 種類と大幅に簡略化されています。

ESXi 6.7 までのパーティション



  • Partition #1 : System Partition (4MB)
  • Partition #2 - "/scratch" Partition (4GB)
  • Partition #3 : VMFS Partition (VMFS)
  • Partition #5 - "/bootbank" (250MB)
  • Partition #6 - "/altbootbank" (250MB)
  • Partition #7 - Small CoreDump #1 (110MB)
  • Partition #8 - "/store" (286MB)
  • Partition #9 - Large CoreDump #2 (2.5GB)

CLI でPartitionテーブル見ると次のような感じです(32GiB のデバイスを利用時)。

[root@localhost:~] esxcli --formatter=csv --format-param=fields="Display Name,Is Local,Is SSD,Size" storage core device list
DisplayName,IsLocal,IsSSD,Size,
Local NECVMWar CD-ROM (mpx.vmhba1:C0:T0:L0),true,false,0,
Local VMware Disk (mpx.vmhba0:C0:T0:L0),true,false,32768,

[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
4177 255 63 67108864
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 67108830 AA31E02A400F11DB9590000C2911D1B8 vmfs 0  ← 7.5GB 以降が VMFS で割り当てられる

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      24.5G   1.4G     23.1G   6% /vmfs/volumes/datastore1
vfat       249.7M 148.4M    101.3M  59% /vmfs/volumes/eefbca74-8bec43ca-3f57-2b771eef9805
vfat         4.0G   4.6M      4.0G   0% /vmfs/volumes/5e959a24-46aa910d-69e1-005056b64fa8
vfat       285.8M 173.8M    112.0M  61% /vmfs/volumes/5e959a1c-2a6338cd-39f0-005056b64fa8
vfat       249.7M   4.0K    249.7M   0% /vmfs/volumes/25a74077-d68771e7-74cb-44c65bc80f64
 

ESXi 7.0 からのパーティション


  • Partition #1 : System Partition (100MB)
  • Partition #5 - "/bootbank" (500MB / 1GB / 4GB)
  • Partition #6 - "/altbootbank" (500MB / 1GB / 4GB)
  • Partition #7 - OSData (VMFS-L)
  • Partition #8 - VMFS Partition (VMFS6)
同じく CLI でみると以下の様になります(140GiB のデバイスを利用時)。
System Partition、Boot Bank ともに拡張され、VMFS-L の OSData、VMFS6 のローカルデータストアが作成されている事が確認できます。

[root@localhost:~] esxcli --formatter=csv --format-param=fields="Display Name,Is Local,Is SSD,Size" storage core device list
DisplayName,IsLocal,IsSSD,Size,
Local NECVMWar CD-ROM (mpx.vmhba1:C0:T0:L0),true,false,0,
Local VMware Disk (mpx.vmhba0:C0:T0:L0),true,false,143360,

[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
18275 255 63 293601280
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 208896 8595455 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 8597504 16984063 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 16986112 268435455 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0 ← 128GB まで OSData として VMFS-L で割り当てられる
8 268437504 293601246 AA31E02A400F11DB9590000C2911D1B8 vmfs 0 ← 128GB 以降が VMFS に割り当てられる

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      11.8G   1.4G     10.3G  12% /vmfs/volumes/datastore1
VMFS-L     119.8G   3.0G    116.7G   3% /vmfs/volumes/OSDATA-5e95a002-38c3d94c-c1a9-005056b649df
vfat         4.0G 162.7M      3.8G   4% /vmfs/volumes/BOOTBANK1
vfat         4.0G  64.0K      4.0G   0% /vmfs/volumes/BOOTBANK2
 

起動オプション systemMediaSize によるカスタマイズ

※ 2021/1/15 追記 : 
----
ESXi 7.0u1c から systemMediaSize Boot Option を指定する事でデフォルトのサイズを指定できる様になりました。

自宅 Lab 用途などでブートドライブの VMFS 領域を有効に利用したい場合は以下オプションで適切なサイズでのインストールが可能です。(以下の GB 単位は GiB ではなく SI 接頭辞の GB)

指定方法 : systemMediaSize=<size> 
  • min (33 GB, for single disk or embedded servers)
  • small (69 GB, for servers with at least 512 GB RAM)
  • default (138 GB)
  • max (consume all available space, for multi-terabyte servers)
インストール時のメディアで boot.cfg に kernelopt=runweasel systemMediaSize=small とすることで kickStart などでサイズを指定することも可能です。

----

デバイスサイズによるパーティションデザインの違い

ESXi 7.0 以降は ESXi の Kernel がインストールされる Boot Bank が従来の 250MiB から拡張されブートデバイスのサイズにより 500MiB / 1GiB / 4GiB が自動で選ばれ、その後ろに可変サイズの OSData 領域が作成されます。
また、前述のとおりローカルデータストアとしての VMFS は 128GB 以降に作成されます。
※ Boot Bank の拡張は、近年の vSAN や NSX-T の対応、k8s 対応など ESXi の Kernel が持つ機能が増え、今後の機能設計を幅を広げるためといわれております。

※ 2021/6/30 追記 :
----
7.0u1c のリリース後、リリースノートと公式 Docs の記載が、
4 ~ 10 GB 10 ~ 33 GB 33 ~ 138 GB 138 GB 超
となっており、128GB 超ではなく、138GB 超となった記載が確認できます。
138GB という数字は物理ドライブが採用する SI 接頭辞(10進) での数字で、2進接頭辞に換算すると 128GiB になります。
ブートデバイスの選定時はご注意ください。
起動メディアのサイズ4 ~ 10 GB10 ~ 33 GB33 ~ 138 GB138 GB 超
システム起動100 MB100 MB100 MB100 MB
起動バンク 0500 MB1 GB4 GB4 GB
起動バンク 1500 MB1 GB4 GB4 GB
ESX-OSData残りの容量残りの容量残りの容量最大 138 GB
VMFS データストアメディア サイズが 142 GB より大きい場合の残りの容量
----

※ OSData 領域のサイズをインストール時に変更する際は、ESXi 7.0u1c より実装された systemMediaSize オプションを利用します (上記参照)。

ESXi 7.0 を 4GiB ~ 10GiB のデバイスにインストールした場合

10GiB 未満のデバイスの場合は Boot Bank が二つの 500MiB で構成され、残りが OSData となります。
[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
1044 255 63 16777216
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 208896 1232895 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 1234944 2258943 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 2260992 16777182 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-L       6.8G   3.0G      3.7G  44% /vmfs/volumes/OSDATA-5e95a038-b39a3c28-1601-005056b6d1b2
vfat       499.7M 159.7M    340.0M  32% /vmfs/volumes/BOOTBANK1
vfat       499.7M   8.0K    499.7M   0% /vmfs/volumes/BOOTBANK2
 

ESXi 7.0 を 10GiB ~ 32GiB のデバイスにインストールした場合










10GiB 以上 32GiB 未満のデバイスの場合は Boot Bank が二つの 1GB で構成され、残りが OSData となります。
[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
1305 255 63 20971520
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 208896 2306047 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 2308096 4405247 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 4407296 20971486 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0

[root@localhost:~] df -h
Filesystem    Size   Used Available Use% Mounted on
VMFS-L        7.8G   3.0G      4.7G  39% /vmfs/volumes/OSDATA-5e95a096-6a73bbb9-fd63-005056b6c969
vfat       1023.8M 160.9M    862.9M  16% /vmfs/volumes/BOOTBANK1
vfat       1023.8M  32.0K   1023.8M   0% /vmfs/volumes/BOOTBANK2
 

ESXi 7.0 を 32GiB ~ 128GiB (138GB)のデバイスにインストールした場合









32GiB 以上 128GiB 未満のデバイスの場合は Boot Bank が二つの 4GB で構成され、残りが OSData となります。
ESXi 6.x では作成されたローカルデータストアもこの場合は作成されません。
[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
13054 255 63 209715200
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 208896 8595455 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 8597504 16984063 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 16986112 209715166 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0
                                                             ← 128GB 以下のデバイスでは VMFS6 のパーティションは作成されない

[root@localhost:~] df -h
Filesystem  Size   Used Available Use% Mounted on
VMFS-L     91.8G   3.0G     88.7G   3% /vmfs/volumes/OSDATA-5e959fe3-697dd9c3-7a6a-005056b6bdeb
vfat        4.0G 162.7M      3.8G   4% /vmfs/volumes/BOOTBANK1
vfat        4.0G  64.0K      4.0G   0% /vmfs/volumes/BOOTBANK2
 

ESXi 7.0 を 128GiB (138GB)以上のデバイスにインストールした場合








128GiB 以上のデバイスの場合は Boot Bank が二つの 4GB で構成され、 OSData が 120GiB、残りが VMFS6 のローカルデータストアとなります。

この様に標準でインストールした場合は、ローカルデータストアは 128GiB (138GB) 以上のデバイスで初めて作成されますので、ローカルデータストアの利用を予定されていた場合はご注意ください。
※ OSData 領域のサイズをインストール時に変更する際は、ESXi 7.0u1c より実装された systemMediaSize オプションを利用します (上記参照)。
[root@localhost:~] esxcli --formatter=csv --format-param=fields="Display Name,Is Local,Is SSD,Size" storage core device list
DisplayName,IsLocal,IsSSD,Size,
Local NECVMWar CD-ROM (mpx.vmhba1:C0:T0:L0),true,false,0,
Local VMware Disk (mpx.vmhba0:C0:T0:L0),true,false,143360,

[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
18275 255 63 293601280
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 208896 8595455 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 8597504 16984063 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 16986112 268435455 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0 ← 128GB まで OSData として VMFS-L で割り当てられる
8 268437504 293601246 AA31E02A400F11DB9590000C2911D1B8 vmfs 0 ← 128GB 以降が VMFS に割り当てられる

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      11.8G   1.4G     10.3G  12% /vmfs/volumes/datastore1
VMFS-L     119.8G   3.0G    116.7G   3% /vmfs/volumes/OSDATA-5e95a002-38c3d94c-c1a9-005056b649df
vfat         4.0G 162.7M      3.8G   4% /vmfs/volumes/BOOTBANK1
vfat         4.0G  64.0K      4.0G   0% /vmfs/volumes/BOOTBANK2
 

ESXi を 6.x から 7.0 以降にバージョンアップした場合

既存の ESXi 6.x から 7.0 にバージョンアップした際には、各パーティションが再作成され、Boot Bank は 500MiB に拡張され、診断パーティションやスクラッチは OSData に集約されます。

ESXi 6.7 の時のパーティション

[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
4177 255 63 67108864
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128 ← システムパーティションは 4MB
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
3 15472640 67108830 AA31E02A400F11DB9590000C2911D1B8 vmfs 0 

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      24.5G   1.4G     23.1G   6% /vmfs/volumes/datastore1
vfat       249.7M 148.4M    101.3M  59% /vmfs/volumes/eefbca74-8bec43ca-3f57-2b771eef9805
vfat         4.0G   4.6M      4.0G   0% /vmfs/volumes/5e959a24-46aa910d-69e1-005056b64fa8
vfat       285.8M 173.8M    112.0M  61% /vmfs/volumes/5e959a1c-2a6338cd-39f0-005056b64fa8
vfat       249.7M   4.0K    249.7M   0% /vmfs/volumes/25a74077-d68771e7-74cb-44c65bc80f64
 

ESXi 6.7 → ESXi 7.0 にバージョンアップ後のパーティション

既存環境を ESXi 7.0 にバージョンアップした場合は、ローカルデータストアの VMFS はそのまま維持されます。
自宅ラボ環境などでブートデバイス兼ローカルデータストアとしての容量も必要な方は、いったん 6.7 をインストール後に 7.0 にバージョンアップする事でローカルデータストアの容量を 7.0 を新規インストールした場合に比べて 100GiB 以上確保することが可能です。

※ ESXi 7.0u1c から  systemMediaSize=<size> で指定する事で新規インストール時でも最小 33GB に抑える事が可能となりました。

[root@localhost:~] partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T0:L0
gpt
4177 255 63 67108864
1 64 204863 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128  ← システムパーティションは 100MB に拡張
5 208896 1232895 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 1234944 2258943 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 2260992 15470592 4EB2EA3978554790A79EFAE495E21F8D vmfsl 0
8 15472640 67108830 AA31E02A400F11DB9590000C2911D1B8 vmfs 0  ← VMFS の位置は変わらず

[root@localhost:~] df -h
Filesystem   Size   Used Available Use% Mounted on
VMFS-6      24.5G   1.4G     23.1G   6% /vmfs/volumes/datastore1  ← VMFS はそのまま引き継がれる
VMFS-L       6.2G   3.0G      3.2G  48% /vmfs/volumes/OSDATA-5e95d58b-553b0e70-9f56-005056b64fa8
vfat       499.7M   8.0K    499.7M   0% /vmfs/volumes/BOOTBANK1
vfat       499.7M 159.7M    340.0M  32% /vmfs/volumes/BOOTBANK2
 

メジャーバージョンアップ後に元のバージョンにロールバックしたい場合

上のパーティションの使われ方を見ていただくと分かりますが、メジャーバージョンアップ後は片方の Boot Bank が空になっている事がわかります。
ESXi は二つある Boot Bank を利用して直前のバージョンのイメージを保持しているのでバージョンアップ後に問題が見つかった場合は起動時に Shift+R でリカバリする事が可能ですが、今回のメジャーバージョンアップ後はそれが利用できません。

メジャーバージョンアップ後に 6.7 に戻したい場合は、直前の Build と同じ ESXi を再インストール(VMFS 領域は保持)した後にバックアップしておいたコンフィグを戻すことでリカバリが可能です。

メジャーバージョンアップの前には必ず現在の ESXi Build と同じ ESXi インストーラ、パッチのDepot を用意しておくことと、直前に ESXi のコンフィグをバックアップしておいてください。
How to back up ESXi host configuration (2042141)
Reverting to a previous version of ESXi (1033604)

ESXi 7.0 を 4GB のデバイスにインストールした場合

ESXi 7.0 ではインストールデバイスの最低容量が 4GB となったため、4GB 以下のデバイスでは以下の様にインストールが出来ません。
また、以前のバージョンからのバージョンアップもできない為ご注意ください。

まとめ

ESXi 7.0 から大きく変わるブートデバイスのパーティションについてのご紹介でした。
商用環境などでこれから新規導入する場合は、32GB 以上の SSD、HDD などを利用する事が推奨されます。
最近はブートデバイス専用の M.2 SSD なども各社ラインナップしているのでそれらを利用するのが良いかと思います。

自宅ラボで ESXi をご利用の方は、ESXi 7.0 を新規導入する場合はローカルデータストアの扱いが従来から大きく変更されているのでご注意ください。

過去30日でアクセスの多い投稿