VCF 9.1でNVMe Memory Tieringを有効化する前に確認する：esxcli memtier、DRAM:NVMe比率、VM制約の実務ポイント

3行まとめ：VCF 9.1のNVMe Memory Tieringはコマンド入口から確認する

このテーマをもう少し広げて見るなら、VCF 9.xでDell PowerFlexを使う前に確認する：SDC、NVMe/TCP、グリーンフィールド制約の実務ポイント と VCF 9.1でvSANネットワークを設計前に確認する：10GbE、VMkernel、MTU/vmkpingの実務ポイント も合わせて確認してください。NVMeデバイスやホスト設計を確認する流れで、VCF 9.xの外部ストレージ連携とNVMe/TCPの制約も比較できます。

esxcli memtier

9.1では有効化、確認、比率変更、無効化をmemtier名前空間から整理します。

専用NVMeとmaintenance mode

NVMeの用途混在を避け、変更前後のmaintenance modeを手順に入れます。

比率とVM制約

DRAM:NVMe比率、active memory、tieringに参加しないVMタイプを分けて確認します。

最初に見るのはコマンド名ではなく、専用デバイス、比率、VM影響、戻し手順までそろったRunbookかどうかです。

VCF 9.1やvSphere 9.1でMemory Tiering over NVMeを扱うときは、まずesxcli memtierの名前空間で有効化、確認、比率変更、無効化を整理します。

専用NVMe、maintenance mode、DRAM:NVMe比率、VMタイプごとの扱いを確認しないまま有効化すると、容量効率だけを見て本番ワークロードの制約を見落としやすくなります。

この記事では2026年6月13日時点のBroadcom TechDocs、Broadcom DeveloperのESXCLI command reference、Broadcom KB 398302をもとに、導入前のRunbook確認ポイントをまとめます。

BroadcomはVCF 9.1を、AIとKubernetesに対応したprivate cloud基盤として位置づけています。ただし、Memory Tiering over NVMeは「AI基盤だから入れる機能」ではありません。ホストのメモリ容量をどう伸ばすか、どのワークロードを載せるか、どのVMをtiering対象から外すかを決めてから使う機能です。VCF 9.1全体の移行計画は、公開済みのVCF 5.2.xから9.1への移行前チェックと合わせて読むと、旧手順の棚卸しがしやすくなります。

VCF 9.1でまず変わったのは有効化コマンドの入口

項目	内容	見方
旧Runbookの確認		Advanced System Settings、旧コマンド、再起動前提の記述が残っていないかを探します。
9.1の入口		enable、disable、config get、config set、device listをesxcli memtierで確認します。
比率オプション		–tier-size-pctは容量値ではなく、DRAMに対するtiering sizeの割合として扱います。
一次情報の位置づけ		需要シグナルは参考にしつつ、最終確認はBroadcom TechDocsとESXCLI referenceに寄せます。

9.0以前の知識が間違いという意味ではなく、9.1向けRunbookでは入口をmemtier中心にそろえることが重要です。

2026年6月12日にWilliam Lam氏がVCF 9.1のNVMe Tiering向けESXCLIコマンドを取り上げたことで、運用者側では「これまでの手順書をそのまま使ってよいのか」という需要が出ています。これは需要シグナルとして重要です。一方で、記事本文の事実確認はBroadcomの一次情報に寄せる必要があります。

Broadcom DeveloperのESXCLI command referenceでは、9.1.0のコマンドセットとしてesxcli memtierが確認できます。memtier enable、memtier disable、memtier config get、memtier config set、memtier device listが並び、--tier-size-pctはDRAMに対するtiering sizeの割合として扱われます。

なぜ今この確認が必要か

Memory Tiering over NVMeは、単にNVMeを追加してメモリ容量を大きく見せる仕組みではありません。Broadcom TechDocsは、専用の直接接続NVMeを使うこと、DRAM:NVMe比率を考えること、変更作業ではmaintenance modeを前提にすることを説明しています。古い運用メモのまま進めると、次のようなズレが起きます。

根拠

• 9.1のESXCLI command referenceではmemtier名前空間に有効化、無効化、構成取得、構成変更、デバイス一覧の操作がまとまっています。
• vSphere 9.1のMemory Tiering Configurationは、vCenter Configuration Manager、ESXCLI、PowerCLIで構成できると説明しています。
• vSphere 9.1のBest Practicesは、専用NVMe、デフォルト1:1のDRAM:NVMe比率、active memoryを見た変更判断を説明しています。

注意点

William Lam氏の記事は、運用者が何を気にしているかを示す材料として扱います。公式コマンド、比率、VM制約の根拠は、Broadcom TechDocs、Broadcom Developer、Broadcom KBで確認します。スクリーンショットや失敗例をそのまま公式仕様のように扱わないことが大事です。

9.1ではesxcli memtierを入口にする

Runbookに入れるなら、まず次のように役割を分けます。実行対象のデバイス名は環境ごとに異なるため、本文ではプレースホルダーで示します。

esxcli memtier device list --available
esxcli memtier device list --configured
esxcli memtier enable --devices <device>
esxcli memtier config get --enable
esxcli memtier config get --devices
esxcli memtier config get --tier-size-pct
esxcli memtier config set --tier-size-pct <1-400>
esxcli memtier disable

ここで見たいのは、コマンドを覚えることではなく、運用手順の入口が変わっているかです。旧Runbookにsystem tierdevice、MemoryTiering、Mem.TierNvmePct、storage core adapter device listなどが残っている場合は、9.1向けにそのまま使う前に公式ドキュメントで読み替えます。

確認項目

• 9.1向けRunbookでmemtier名前空間を使っているか
• 自動化スクリプトやKickstartに旧手順が残っていないか
• --tier-size-pctを容量値としてではなく、DRAM基準の割合として扱っているか
• 有効化後の確認コマンドまで手順に入っているか

評価基準

「有効化コマンドが通る」だけでは足りません。候補デバイス、構成済みデバイス、有効化状態、tier-size、VM影響、無効化時の手順まで同じRunbookに入っている状態を目標にします。

有効化前に見るNVMeデバイスとmaintenance mode

1. 1候補NVMeを確認

   対象ホストでMemory Tieringに使えるNVMe候補を洗い出します。

2. 2専用性を確認

   vSAN、データストア、ログ、ゲストI/Oと同じ物理NVMeを共有していないかを確認します。

3. 3ホスト差分を確認

   同じクラスタ内でNVMe構成や容量差が大きすぎないかを見ます。

4. 4maintenance modeを固定

   有効化、無効化、構成変更、比率変更で必要になる作業条件をRunbookに入れます。

5. 5構成後に確認

   device list、config get、status getで候補デバイスと構成済みデバイスを分けて確認します。

NVMeを見つけたことと、Memory Tiering専用デバイスとして使えることは別の確認です。

Memory Tiering over NVMeの事前確認で最初に見るのは、対象ホストにNVMeがあるかどうかではありません。そのNVMeをMemory Tiering専用として扱えるかです。Broadcom TechDocsのBest Practicesは、ホストにMemory Tieringで使える専用NVMeデバイスがあることを確認するよう説明し、同じ物理NVMeドライブをNVMe tieringとvSANで混在させない例を挙げています。

この時点で、VCF 9.1のCPU/サーバー互換性チェックも見ておくと、Memory Tieringだけでなくホスト全体の更新可否を同じ棚卸しに入れられます。

NVMeはMemory Tiering専用として扱えるか

NVMeデバイスを見つけても、すぐ有効化しないほうがよい場面があります。たとえば、同じ物理デバイスをvSANやデータストア用途、ゲストI/O用途と共有している場合です。Best Practicesは「専用」「直接接続」「NVMeがDRAM以上であることを一般的な目安にする」といった前提を示しています。

根拠

vSphere 9.1のBest Practicesは、ホストのメモリ容量を拡張する場合にデフォルトの1:1 DRAM:NVMe比率を使うことを説明しています。1TB DRAMに1TB分のNVMeを割り当てると、合計2TBのホスト容量として扱える例も示されています。ただし、これは説明用の例であり、どのワークロードでも同じ性能になるという意味ではありません。

確認項目

• 対象ホストのNVMeがMemory Tiering専用にできるか
• NVMeがvSAN、データストア、ログ、ゲストI/Oと混ざっていないか
• 同じクラスタ内でホストごとの構成差が大きすぎないか
• 障害時にデバイス交換や無効化の手順を戻せるか

device listで候補と構成済みデバイスを分ける

9.1ではmemtier device listで、候補デバイスと構成済みデバイスを分けて確認します。これは、Runbookの中で「利用可能なNVMeを探す作業」と「すでにMemory Tiering用に使われているデバイスを確認する作業」を混ぜないためです。

コマンド候補

esxcli memtier device list --available
esxcli memtier device list --configured

--availableは候補を見るため、--configuredは構成済みの確認に使います。どちらの出力も、実環境のデバイス名に依存します。記事や手順書に固定デバイス名を写すより、運用チームが自環境で確認したデバイス名を作業記録に残すほうが安全です。

注意点

候補が表示されても、容量、接続形態、用途、保守手順が確認できるまで本番クラスタでの有効化に進まないほうがよいです。Memory Tieringはメモリ管理に関わるため、あとから「実はvSANでも使っていた」という状態は避けたいところです。

maintenance modeが必要な作業を手順の前に固定する

vSphere 9.1のMemory Tiering Configurationは、ESXCLIやPowerCLIでMemory Tieringの有効化、無効化、再構成を行う前に、ESXホストをmaintenance modeにする必要があると説明しています。9.0のTechDocsにも、VMが稼働している間はtiered memoryに使うNVMeデバイスのパーティションを変更してはならないという注意があります。

条件

次の作業は、Runbook上でmaintenance modeの確認を前に置きます。

• Memory Tieringの有効化
• Memory Tieringの無効化
• 対象デバイスの変更
• --tier-size-pctの変更
• 旧手順から9.1手順へ移すときの再構成

失敗時の見方

コマンドが失敗したときは、デバイス名だけでなく、maintenance mode、既存構成、構成済みデバイス、VM配置も確認します。エラーを見てすぐ別のNVMeを指定するより、構成状態を戻せるかを先に見るほうが、運用事故を減らせます。

DRAM:NVMe比率は増やせる容量ではなくワークロード前提で読む

項目	内容	見方
–tier-size-pct 100		NVMe tiering 1TB相当。デフォルト1:1の考え方に近い読み方です。
–tier-size-pct 50		NVMe tiering 0.5TB相当。active memoryと性能許容を見て抑える例です。
–tier-size-pct 25		NVMe tiering 0.25TB相当。DRAM:NVMe比率を4:1として読む例です。
値の範囲		ESXCLI referenceでは1から400の範囲として確認します。

この表は説明用であり推奨値ではありません。実際の値はワークロード、active memory、性能要件、戻し手順を見て決めます。

Memory Tieringで誤解しやすいのは、NVMeを足せば常にホストメモリを安く増やせる、という読み方です。Broadcom TechDocsは、デフォルトの1:1 DRAM:NVMe比率を幅広いワークロードと環境に適した出発点として説明しています。同時に、設定変更は過去のactive memory使用量を評価した後に行うとも説明しています。

デフォルト1:1を出発点にする理由

デフォルト1:1は、DRAMと同量のNVMe tiering容量を想定する読み方です。たとえば1TB DRAMのホストに1TB分のNVMeを割り当てると、説明上は合計2TBのホストメモリ容量として考えられます。

根拠

Best Practicesは、ホストのメモリ容量を拡張するためにデフォルトの1:1 DRAM:NVMe比率を使うと説明しています。この比率は広い種類のワークロードと顧客環境に適しているとされています。

注意点

この説明は、性能保証ではありません。Memory Tieringは、hot pageとcold pageの分類や専用NVMeを使う点でswapとは異なりますが、すべてのワークロードが同じ効率で動くわけではありません。active memoryが高いワークロード、低遅延を求めるVM、セキュリティ機能やnested構成が絡むVMは、別に棚卸しします。

--tier-size-pctはDRAM基準の割合として説明する

ESXCLI command referenceでは、memtier enableとmemtier config setに--tier-size-pctがあります。この値はDRAMに対する最大tiering sizeの割合で、範囲は1から400です。vSphere 9.1のConfigurationでは、値を25にするとDRAM合計の25%がNVMe tiered memoryとして構成され、DRAM:NVMe比率が4:1になる例が示されています。

説明用の値	DRAM 1TBの例	読み方
--tier-size-pct 100	NVMe tiering 1TB相当	デフォルト1:1の考え方に近い
--tier-size-pct 50	NVMe tiering 0.5TB相当	active memoryと性能許容を見て抑える例
--tier-size-pct 25	NVMe tiering 0.25TB相当	TechDocsの4:1比率の例と同じ読み方

この表は説明用です。推奨値ではありません。実際の設定は、メモリ使用傾向、VMの種類、性能要件、保守時間、ロールバック手順を見て決めます。

確認項目

• --tier-size-pctをDRAM基準の割合として説明できるか
• 値の範囲が1から400であることをESXCLI referenceで確認したか
• active memoryの実績を見たうえで比率変更を検討しているか
• 比率変更前にmaintenance modeを入れているか

評価基準

容量効率を上げる前に、どのVMがcold pageを多く持つのか、どのVMが低遅延を求めるのか、どのVMをtiering対象から外すのかを決めます。Memory Tieringはコスト削減の言葉だけで導入すると危険です。運用チームが性能の上振れと下振れを同じ表で説明できる状態が、検証開始の目安になります。

VM単位の制約は起動できるとtieringに参加するを分ける

項目	内容	見方
起動可否		KB 398302のエラー文を手がかりに、対象VMが起動条件を満たすかを確認します。
tiering参加		9.1で実行できるVMでも、Memory Tieringには参加しないタイプがある前提で棚卸しします。
VMタイプ		Low Latency VM、Security VM、ftCP VM、Monster VM、Nested VMを個別に確認します。
配置と期待値		対象クラスタに載せるVM、例外にするVM、性能確認が必要なVMを分けます。

「起動できる」と「NVMe tiered memoryを使う」は同じ意味ではありません。VM単位の例外を先にRunbookへ残します。

Broadcom KB 398302は、Memory Tiering有効環境でVM起動時に「This type of VM is not supported when software memory tiering is enabled」というエラーが出るケースを扱っています。ここで大切なのは、9.1での扱いを単純に「解決済み」と読まないことです。

KBは、ESX 9.0以前では対象VMのパラメータ変更や無効化が回避策になると説明し、解決策としてESX 9.1へのアップグレードを示しています。そのうえで、特定のVMタイプは物理9.1 ESXホスト上でMemory Tieringが有効でも実行できるが、Memory Tieringには参加しないと説明しています。

KB 398302のエラーを読者の確認項目に変換する

このKBを読むときは、エラー文そのものよりも、VMタイプの棚卸しに使うのが実務的です。対象クラスタに低遅延VM、セキュリティVM、ftCP VM、大規模VM、nested VMがある場合、Memory Tieringを有効化する前に配置と期待値を分けます。

根拠

KB 398302は、9.1でMemory Tieringが有効な物理ESXホスト上で実行できるようになったが、Memory Tieringへの参加は無効のままになるVMタイプとして、Low Latency VM、Security VMs、ftCP VMs、Monster VMs、Nested VMsを挙げています。

注意点

起動できることと、Memory Tieringで容量効率を得られることは別です。特定VMがtieringに参加しないなら、そのVMのメモリ消費は設計上の余白として残す必要があります。

9.1で起動できてもMemory Tieringに参加しないVMタイプ

KBの表現を導入判断に置き換えると、次のようになります。

VMタイプ	9.1での読み方	導入前の確認
Low Latency VM	ホスト上で実行できてもtiering参加は別	遅延許容値と予約メモリを確認する
Security VM	セキュリティ機能の前提を確認	暗号化、SEV、SGX、TDXなどの扱いを棚卸しする
ftCP VM	可用性設計と切り分ける	フォールトトレランス前提を確認する
Monster VM	大規模VMとして別扱い	メモリ予約、vCPU数、配置先を確認する
Nested VM	デフォルトではMemory Tiering無効	VBS例外とnested hypervisorサポートを混同しない

対象

重要VMを多く持つクラスタでは、Memory Tieringの導入前に「どのVMがtieringに参加しないか」を一覧化します。ここを飛ばすと、ホスト全体の見かけ容量と、実際に余裕を持って動かせるワークロード数がズレます。

評価基準

Memory Tieringを入れるクラスタに、低遅延、セキュリティ、FT、大規模、nestedのVMがどれだけあるかを事前に確認します。多い場合は、クラスタを分ける、PoCだけにする、対象VMを除外する、別の容量増強策を検討するなど、設計の選択肢を残します。

Nested VMとVBS例外の扱い

KB 398302は、Nested VMではデフォルトでMemory Tieringが無効だと説明しつつ、VBS VMについてはsched.mem.enableNestedTieringをTRUEに設定できる例外を示しています。本文でこの設定を扱う場合は、VBS VMの文脈に絞ります。

条件

VBS VMでMemory Tieringを検討する場合でも、Broadcom KBはワークロードの性質を事前にレビューし、テストするよう促しています。本番VMに対して、設定名だけを見て一括適用するのは避けます。

注意点

Broadcom KBは、VMware vSphere ESX上でVM内にnested hypervisorを実行することのサポートについても別KBへの確認を促しています。Nested VM、VBS VM、nested hypervisorのサポート可否は同じ話ではありません。

有効化後はvSphere ClientとESXCLIの両方で確認する

項目	内容	見方
クラスタ		vSphere ClientのMemoryカードでMemory Tieringのホスト構成情報を確認します。
ホスト		ホスト単位でMemory Tieringが有効化され、意図しない構成差がないかを見ます。
デバイス		構成済みNVMe、候補NVMe、専用性、入れ替え条件をRunbookと照合します。
比率		enable値、devices、encryption、tier-size-pctを分けて確認します。
戻し手順		disable、–delete-devices、config set、maintenance modeの扱いを事前に決めます。

すべてのホストを同じ値にすることが正解とは限りませんが、意図しない差分は消す必要があります。

Memory Tieringは、有効化コマンドを実行して終わりではありません。クラスタ、ホスト、デバイス、比率、VM影響、無効化手順を確認して、初めてRunbookとして使える状態になります。

クラスタとホストの表示で見る項目

vSphere 9.1のConfigurationは、vSphere ClientでクラスタのSummaryタブにあるMemoryカードから、Memory Tieringのホスト構成情報を確認できると説明しています。ホスト単位でも、vSphere ClientまたはESXCLIで構成状態を確認できます。

確認項目

• クラスタのMemoryカードでMemory Tieringの構成が見えるか
• ホスト単位でMemory Tieringが有効化されているか
• 対象ホストごとの構成差が意図したものか
• 表示上の容量増加だけで判断していないか

注意点

画面に容量が増えたように見えても、VM制約、比率、デバイス専用性、性能許容値の確認は別です。監視ツールや運用台帳にも、Memory Tieringを有効化したホスト、対象NVMe、比率、例外VMを残します。

ESXCLIで見る項目

ESXCLIでは、構成取得コマンドをRunbookに入れておくと、変更後の状態を確認しやすくなります。

esxcli memtier config get --enable
esxcli memtier config get --devices
esxcli memtier config get --tier-size-pct
esxcli memtier status get

コマンド候補

config getは、enable値、devices、encryption、tier-size-pctを分けて確認できます。status getは、現在デプロイされているMemory Tiering構成を見るための入口として使えます。

評価基準

Runbookには、期待値と実測値を並べます。たとえば「対象ホストAは--tier-size-pct 100、対象ホストBは検証中のため無効」といった形です。すべてのホストを同じ値にすることが正解とは限りませんが、意図しない差分は消す必要があります。

無効化や変更をRunbookに含める

導入前のRunbookに無効化手順がない場合、まだ本番に進めないほうがよいです。ESXCLI command referenceにはmemtier disableがあり、--delete-devicesでデバイス削除を伴う選択肢もあります。構成変更ではmemtier config setを使います。

確認項目

• 無効化する場合にVM配置をどう戻すか
• --delete-devicesを使う条件を明確にしているか
• デバイス入れ替え、mirror構成、比率変更を扱うか
• 作業前後のmaintenance mode確認が入っているか

注意点

無効化や構成削除は、検証環境で一度戻してから本番手順に入れます。導入手順だけ整っていて戻し手順がない状態は、運用の片道切符になりがちです。

9.0以前の手順を持っている環境で見直すもの

旧コマンド

tierdevice、MemoryTiering、storage core adapter device listなどの検索語で手順書を探します。

高度設定

VMKernel.Boot.memoryTieringやMem.TierNvmePctの記述を9.1向けに読み替えます。

再起動前提

旧手順にある再起動、NVMeパーティション作成、保守作業の前提を洗い出します。

確認方法

9.1ではmemtierのconfig、status、device確認を中心にRunbookを更新します。

旧手順の詳細をそのまま引き継ぐのではなく、9.1で使う入口、確認方法、戻し方に置き換えます。

vSphere 9.0のMemory Tiering Configurationでは、ホストのAdvanced System SettingsでVMKernel.Boot.memoryTieringをtrueにして再起動する流れや、Mem.TierNvmePctで比率を扱う説明が出てきます。また、NVMeデバイスの一覧確認やtier partition作成の手順も、9.1のmemtier中心の読み方とは入口が異なります。

ここは、9.0以前の手順が間違っていたという話ではありません。9.1向けにRunbookを更新するなら、旧手順の知識をそのまま持ち込まない、という話です。

旧手順のまま9.1へ持ち込まない

9.0以前のRunbookに、Advanced System Settings、VMKernel.Boot.memoryTiering、Mem.TierNvmePct、system tierdevice、NVMeパーティション作成、reboot前提が入っている場合は、9.1での公式手順と照合します。

根拠

vSphere 9.0のTechDocsには、Advanced System SettingsでVMKernel.Boot.memoryTieringを有効化してホストを再起動する説明があります。9.1のESXCLI command referenceではmemtier名前空間が前面に出ています。両者を混ぜると、作業者がどのバージョン向けの手順を実行しているのか分かりにくくなります。

注意点

9.0以前の詳細手順を9.1記事の本文で長く再現すると、読者が旧手順を実行してしまう可能性があります。この記事では、旧手順は棚卸しキーワードとして扱い、9.1では公式ドキュメントでmemtierの現行手順を確認する方針に寄せます。

自動化スクリプトの検索観点

Runbookだけでなく、Ansible、PowerCLI、Kickstart、社内Wiki、変更申請テンプレートにも旧表現が残りやすいです。検索語を決めて、変更前に洗い出します。

確認項目

• tierdevice
• MemoryTiering
• VMKernel.Boot.memoryTiering
• Mem.TierNvmePct
• storage core adapter device list
• system maintenanceMode
• tier-size-pct
• memtier

評価基準

検索結果を「削除する」「9.1向けに置き換える」「バージョン分岐を入れる」「参照資料として残す」に分けます。VCF 9.1のPoCや検証計画に進む場合は、VCF 9.1 Hands-on LabsとPoCの確認記事のように、本番前の検証項目へ落とし込むと実務に戻しやすくなります。

導入判断のまとめ：本番投入前に5つを残す

memtier入口

9.1ではesxcli memtierを入口にし、旧Runbookをそのまま流用しません。

専用NVMe

Memory Tiering用NVMeは、vSANやデータストア用途と混ぜない前提で確認します。

DRAM基準の比率

デフォルト1:1を出発点にし、–tier-size-pctはDRAM基準の割合として読みます。

VM制約

起動可否とMemory Tiering参加可否を分け、例外VMを棚卸しします。

確認と戻し

vSphere ClientとESXCLIの両方で確認し、無効化や変更の手順もRunbookに含めます。

容量効率だけで判断せず、限定クラスタで候補NVMe、比率、対象VM、例外VM、戻し手順を確認してから本番に広げます。

VCF 9.1のMemory Tiering over NVMeは、容量効率の話としてだけ見ると魅力的です。しかし、本番運用で見るべき順番は、有効化コマンドより前にあります。

この記事の判断メモ

確認項目

1. 9.1ではesxcli memtierを入口にし、旧Runbookをそのまま流用しない。
2. Memory Tiering用のNVMeは専用性を確認し、vSANやデータストア用途と混ぜない。
3. デフォルト1:1のDRAM:NVMe比率を出発点にし、--tier-size-pctはDRAM基準の割合として読む。
4. Low Latency VM、Security VM、ftCP VM、Monster VM、Nested VMは、起動可否とtiering参加可否を分けて棚卸しする。
5. 有効化後はvSphere ClientとESXCLIの両方で構成状態を確認し、無効化や変更の手順もRunbookに含める。

実務での次の一手

まずは1台または限定クラスタで、候補NVMe、構成済みNVMe、--tier-size-pct、対象VM、例外VM、戻し手順を確認します。そのうえで、容量効率や性能の見立てを自社ワークロードで検証します。BroadcomのVCF 9.1公式発表はAIとKubernetes native private cloudの文脈を示していますが、Memory Tieringの実装判断はホスト、NVMe、VM、運用手順の確認で決めるのが安全です。

この記事はBroadcomおよび関係会社とは非提携の確認メモです。製品名、商標、仕様、サポート条件は必ず公式ドキュメントで確認してください。株価や投資判断を目的にした内容ではありません。

---

次に読むなら

参照した主な情報源

• Broadcom TechDocs, VMware vSphere 9.1, Memory Tiering Configuration, 確認日 2026年6月13日

https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-1/vsphere-resource-management/memory-tiering-over-nvme/memory-tiering-configuration.html

• Broadcom TechDocs, VMware vSphere 9.1, Memory Tiering Considerations and Best Practices, 確認日 2026年6月13日

https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-1/vsphere-resource-management/memory-tiering-over-nvme/memory-tiering-considerations-and-best-practices.html

• Broadcom Developer, ESXCLI Command Reference, esxcli memtier Commands, 確認日 2026年6月13日

https://developer.broadcom.com/xapis/esxcli-command-reference/latest/namespace/esxcli_memtier.html

• Broadcom Knowledge Base, Article ID 398302, Error "This type of vm is not supported when software memory tiering is enabled", 確認日 2026年6月13日

https://knowledge.broadcom.com/external/article/398302/error-this-type-of-vm-is-not-supported-w.html

• Broadcom News, Broadcom Announces VMware Cloud Foundation 9.1, 確認日 2026年6月13日

https://news.broadcom.com/releases/broadcom-announces-vmware-cloud-foundation-9-1

• WilliamLam.com, VCF 9.1 – Are You Using the Correct ESXCLI Command to Enable NVMe Tiering?, 需要シグナルとして確認, 確認日 2026年6月13日

https://williamlam.com/2026/06/vcf-9-1-are-you-using-the-correct-esxcli-command-to-enable-nvme-tiering.html

更新履歴

1. 2026年6月13日

   Broadcom TechDocs、ESXCLI command reference、Broadcom KB 398302、VCF 9.1公式発表を確認しました。

2. 需要シグナル

   William Lam氏の2026年6月12日の記事は、運用者が確認したい論点として扱いました。

3. 今後の確認

   ESXCLI referenceのlatest表示、TechDocs、KB更新があれば本文を見直します。

公式仕様、KB、需要シグナルを分けて残すと、後日の更新でどこを確認すべきか追いやすくなります。

• 2026年6月13日: Broadcom TechDocs、Broadcom Developer ESXCLI command reference、Broadcom KB 398302、Broadcom VCF 9.1公式発表を確認し、初版を作成。