VMware / Microsoft 製品はこう使う。

好きなことを好きに描く.

例外はありそうだがVMDirectPath I/O はデフォルトで無効になっている(ESXi 5.5 p10, 6.0 p04, 6.0 U3 and 6.5)

こんにちは。

 

VMDirectPath I/O についてです。

最近VMware KB で、既定値が変わった記述があったり、

状況の変化があったので記事したいと思います。

 

みなさまご存知の通り、VMDirectPath I/O とは、

サーバーに搭載しているHBA(PCI)などを 仮想マシンに直接割り当てることができる機能です。

 

細かいアーキテクチャは一切排除したイメージ図です。

f:id:japan-vmware:20170611012655p:plain

 

VMDirectPath I/Oは、仮想マシンに物理的なハードウェアを連携させる機能なので、

実際に動作保証するのか、それとも保証しないのか、については、

ハードウェアベンダーに依存してしまいます。

 

要件についてはVMware KB に記載がありますので、ご覧頂ければと思います。

VMware vSphere VMDirectPath I/O:プラットフォームとデバイスの要件 (2144754) | VMware KB

 

要件に該当しないものをESXiから仮想マシン VMDirectPath I/Oを使ってみせた場合、

案外使えることが多いですが、動作保証しない(いわゆるNot Supported)な構成になります。

 

動作保証しないものを VMDirectPath I/Oを使って仮想マシンに接続した際に、

何が起こりうるかというと、仮想マシンの停止やESXiのPSOD(Parple Screen of Death)が起こることがあります。

 

様々なWeb上の情報では、VMDirectPath I/Oは直接仮想マシンに接続されるような言い回しになっていますが、
実際にはESXiが少なからず仲介して、仮想マシンにPCIデバイスを接続させています。

多くのハードウェア割り込み処理を行いながら、仮想マシンに対してデバイスを提供しているので、予期せぬハードウェア割り込みが行われたりするとPSODになってしまったりします。

 

そこでまずご紹介したいのが、VMware KB 2079988 です。

割り込み再マッピングを使用した場合、ESXi 6.0.x、ESXi 5.x、ESXi/ESX 4.1 で vHBA および他の PCI デバイスが応答を停止する場合がある (2079988) | VMware KB

 

あまり詳しくないのですが、ESXi/ESX 4.1 以降のバージョンでは、割り込み再マッピング コード(Interrupt Remapping)というものが導入されたらしく、

この機能によって、VMDirectPath I/O が動作するようです。

 

この割り込み再マッピングの動作がイマイチらしく、VMware KB では以下の症状が出ることを紹介しています。

  • ESXi ホストが応答しない
  • 仮想マシンが応答しない
  • HBA が応答を停止する
  • 他の PCI デバイスが応答を停止する
  • vCenter Server で「不明デバイスの不正なパス (Degraded path for an Unknown Device)」というアラートが発生する場合がある
  • HBA がドライバへの応答を停止する少し前に、VMkernel または messages ログに無効なベクトルのエラーが表示される場合がある。エラーは次のようになります。

 

対処は、割り込み再マッピングの無効化だそうです。

# esxcli system settings kernel set --setting=iovDisableIR -v TRUE

※ioDisableIR というのをTureにすることで割り込み再マッピングを無効化できます。
  無効化を有効化するというなんともややこしいパラメータ名......

 

ここまででお気づきの方もいらっしゃるかもしれませんが、

割り込み再マッピングによって VMDirectPath I/O が実装されているので、

もし、上記の事象が発生したときに、対処である割り込み再マッピングの無効化すると、

VMDirectPath I/O を利用中の環境だと動作しなくなってしまいます。

何ヶ月か前のVMware KB 2079988にはこんな記載があったのですが、現在では削除されていました。

================

注: 割り込み再マッピングを無効にすると、VMDirectPath I/O パススルー機能も無効になります。

================



続いて、VMware KB 2147325 のご紹介です。

 

ESXi host fails with a diagnostic screen due to an Intel® Virtualization Technology Erratum (2147325) | VMware KB

 

ざっくりとした内容は、VMDirectPath I/O 機能で利用する割り込み再マッピングが原因でPSODになるというVMware KBです。

 

対処を一部抜粋します。

Resolution

VMWare recommends contacting the hardware manufacturer for updated BIOS or possible workarounds.
 
Note: A prior version of this KB article recommended that customers experiencing the problem described above work around it by configuring ESXi to disable the Intel® VT-d interrupt remapper (setting boot option iovDisableIR=FALSE and rebooting). VMware ESXi 5.5 p10, 6.0 p04, 6.0 U3 and 6.5 by default disable the Intel® VT-d interrupt remapper for this purpose.

まずはじめに、各サーバーベンダーに確認することやBIOSをアップデートすることが記載されています。
 
そして注目すべき点はこの部分です。
「VMware ESXi 5.5 p10, 6.0 p04, 6.0 U3 and 6.5 by default disable the Intel® VT-d interrupt remapper for this purpose.」
非常に重要なことが記載されています…。
以下のESXiからは割り込み再マッピングがデフォルトで無効化されていると記載されています...
 
ESXi5.5 patch10
ESXi6.0 patch4
ESXi6.0 Update3
ESXi6.5 GA 
 
 
OSとしてのデフォルト値について、まさかのVMware KB の一部に記載されています。
もし、今後、VMDirectPath I/Oを利用する環境を構築するときは、割り込み再マッピングを有効化しなければ、仮想マシンにデバイスをうまくパススルーできないと思いますので、注意が必要です。
 
 
私は試してはいませんが、既にVMDirectPath I/Oを利用している環境に対して、
ESXiのバージョンアップを行う際にも注意が必要です。
 
 
理由は、既定値が変更されているので、現在使用中の環境に対してパッチを適用すると、 iovDisableIR が false から true に変更されてしまう可能性があり、
もし、trueに変更されてしまうと、VMDirectPath I/Oがうまく動作しないと思います。
 
ということで、既定値をコマンドで見てみました。
 
■ESXi5.5
~ # vmware -v
VMware ESXi 5.5.0 build-2068190
~ # esxcli system settings kernel list -o iovDisableIR
Name Type Description Configured Runtime Default
------------ ---- --------------------------------------- ---------- ------- -------
iovDisableIR Bool Disable Interrrupt Routing in the IOMMU FALSE FALSE FALSE
 
なるほど。VMware KB のとおりです。
 
■ESXi6.5d 
[root@xxxxx:~] vmware -v
VMware ESXi 6.5.0 build-5310538
[root@xxxxx:~] esxcli system settings kernel list -o iovDisableIR
Name Type Description Configured Runtime Default
------------ ---- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ ---------- ------- -------
iovDisableIR Bool Disable Interrrupt Remapping in the IOMMU. Not applicable for platforms pre-configured by firmware to use x2APIC (e.g., platforms with > 256 logical processors); for these interrupt remapping is always enabled. FALSE FALSE FALSE
 
 
なにやら、コマンド結果の表示が全く異なっています。
 
しかし、「iovDisableIR Bool Disable Interrrupt Remapping in the IOMMU.」と記載されているので、無効ではあるようです。
 
また「Not applicable for platforms pre-configured by firmware to use」と記載があるため、使用するファームウェアによって事前に構成されている場合は適用されないという記載もあるので、VMware KB の記述は正しいということになるかと思います。
 
 
長々と記載しましたが、私自身、時間が経つと確実に忘れそうな
内容だったので、覚えている間に記事にして備忘録代わりにしました。
 
 
オワリ
 

ESXi6.5 にvSphere Client 6.0(C#)で接続できた(あれ...?)

こんにちは。

 

ESXi6.5 からは主にvSphere Host Client を使ってESXiホスト単体を操作することができ、vCenter で管理されている場合は vSphere Web Client (Flash/HTML5)で操作することが一般的かと思います。

 

ところが、ESXi6.5 にvSphere Client 6.0(C#)がインストールされたPCから接続することができてしまいました。驚いています。(以前からそうだったのか...忘れました)

 

VMware Product Interoperability Matrices

を参照すると、vSphere Client で絞ると6.5の表記は無い。一般にはサポート外というやつかとおもいます。

f:id:japan-vmware:20170601010856p:plain

 

■接続するPCの  "プログラムと機能"画面 

vSphere Client 5.5 , vSphere Client 6.0 のみ インストールされています。

f:id:japan-vmware:20170601005955p:plain

 

 

■vSphere Client 6.0でESXi6.5に接続する

私の手元の環境はESXi6.5 Build 5310538  でした。

結果ですが、ご覧の通り接続が可能でした。

仮想マシンの作成およびパワーオンもできました。

f:id:japan-vmware:20170601011900p:plain

 

海外の人のBlogなどでは仮想マシンのコンソール操作もできない、といったことを言っている人もいるのですが、私の手元の環境ではコンソールからWindowsにログインすることもできました。

f:id:japan-vmware:20170601013703p:plain

 

■調べると

Web上の資料を漁っていると、このような情報を見つけました。

VMware vSphere Client 6.5 Feature Support

vSphere Client でサポートしない操作や機能が載っています。

一方でサポートされる操作・機能も記載されています。

 

サポートされない操作や機能が盛りだくさんです。

サポートされない機能が盛りだくさんなので、

VMware Product Interoperability Matrices にはあえて6.5の表記が無いのかもしれません。

 

どちらにせよ、あまりvSphere Client はvSphere 6.5 では使わないようにして、

何かあったときのために、頭の片隅に使用可能なことを覚えておくといいような気がしました。

 

ぜんぜん自信がない記事ですが、書くことで何かいいことがあるといいのですが。

 

オワリ

ESXi6.0/ESXi6.5 - VMware Host Client のセッションタイムアウト値を無くす。

こんにちは。

 

海外で記事にしている人がいたので、忘れないように記事にしようと思いました。

 

VMware Host Client はブラウザベースのアプリケーションであるため、

セッションタイムアウト値が予め設定されています。

デフォルトでは900秒(15分)に設定されています。

 

15分が経過後にセッションタイムアウトされたときの画面がこちら。

 

設定は変更ができるので、メモとして残します。

 

VMware Host Client とはナニ?と思った人は以前の記事を是非見て下さい。

bambi.paddle-point.com

 

 

ブラウザから https://<IP Address>/ui/#/login にアクセスし、rootユーザーでログインします。

f:id:japan-vmware:20170529225905p:plain

 

[管理] - [システム]タブ - [詳細設定] - [UserVars.HostClientSessionTimeout] を探す。

デフォルトでは900秒(15分)に設定されています。

f:id:japan-vmware:20170529231157p:plain

 

デフォルトの900秒(15分)から 0秒 に設定変更します。

0秒にすることでセッションタイムアウトすることはなくなりますが、

設定を反映するには、VMware Host Client を開き直すか、ログオフが必要です。

f:id:japan-vmware:20170529231600p:plain

 

vSphere Client(C#)のときは開きっぱなしでもそのまま使えたので、

セッションのタイムアウトに違和感がある方は設定変更をご検討下さい。

 

ログアウト直前は事前にタブ上にタイムアウトするまでの時間が表示されます。

f:id:japan-vmware:20170529234634p:plain

 

タイムアウトしたときはログイン画面に戻ります。

f:id:japan-vmware:20170529234837p:plain

 

検証機などには設定しておくと便利かもしれません。

 

オワリ

 

ESXi6.5 - VMware Host Client でエラーが出てどうすることもできない(Chrome)

こんにちは。

 

ESXi6.0 Update 2 や ESXi 6.5 から VMware Host Client というHTML 5で実装された

ESXi単体を構成・管理できるものがあることはご存知の方も多いかと思います。

 

特にESXi6.5では、従来から存在するC# vSphere Client が利用できなくなり、

VMware Host Client のみで管理する必要があります。

(当然vCenter Server があればvCenterから管理できます)

 

先日、検証をしている中で、 ESXi6.5のホストをVMware Host Client で構成しようとしたところ、Chrome を使っているとエラーが表示されてどうすることもできない状態になりましたので、シェアしたいと思います。

IE 11 だときちんと表示されるみたいですが、残念な制約があるので、最後に記載します。

 

<ESXiホストのIP Address>/ui/

にアクセスし、VMware Host Client にログインするとこのような画面が表示されます。

f:id:japan-vmware:20170501193459p:plain

[再ロード]ボタンを押下するとログイン画面に戻され、[詳細]ボタンを押下すると

例外のエラーが表示されます。表示されるだけで何かできるわけではありません。

f:id:japan-vmware:20170501201418p:plain

 

つまり、VMware Host Client でESXi6.5 単体しか存在しない環境では、

ESXiの構成すらできないという状態になります(涙)

 

この事象は、VMware Host Client が古く(詳しいバージョンは調べてません)、

その間にアクセスする側のGoogle Chromeが新しくなってしまった場合に起きるようです。

 

私の手元の環境では絶賛再現中ですので、バージョン情報を記載します。


[root@localhost:~] vmware -v
VMware ESXi 6.5.0 build-5224529

[root@localhost:~] esxcli software vib list | grep ui
esx-ui 1.15.0-5069532 VMware VMwareCertified 2017-04-02

f:id:japan-vmware:20170501202152p:plain

 

■改善策

新しい esx-ui が含まれたパッチを適用するしかありません。

VMware Flings から新しいバージョンを入手して導入することもできますが、
単体で入れてしまうと、Not Supported な構成になってしまいます。


+ VMware Flings - ESXI EMBEDDED HOST CLIENT
https://labs.vmware.com/flings/esxi-embedded-host-client

本番運用している環境がサポート外の構成になってしまうのは避けたいため、

対処としては新しいバージョンが含まれるESXiのパッチを適用することになります。

 

■パッチを適用する

https://my.vmware.com/group/vmware/patch#search

VMwareのページからパッチをダウンロードします。

本日時点での一番最新のパッチは「ESXi650-201704001」でした。
f:id:japan-vmware:20170501213436p:plain

 

一応念の為、このパッチを解凍して中身を確認すると、Host Client  Ver 1.18 が入っていました。

  VMware_bootbank_esx-ui_1.18.0-5270848.vib

 

ダウンロードしたパッチのファイルをSSH接続したTeratermからSSH SCP でデータストアに転送します。

 

From:は接続しているWindowsのファイルの場所。
To:はESXiのデータストアの場所

f:id:japan-vmware:20170501214229p:plain

 

転送中

f:id:japan-vmware:20170501214409p:plain

 

転送完了

f:id:japan-vmware:20170501214848p:plain

 

ご存知の通り、事前に仮想マシンは全て停止、もしくはvMotion で待避をお願いします。

 

正規手順ということで、ESXiをメンテナンスモードにし、

きちんとメンテナンスモードになっているか状態を確認します。

 

[root@localhost:~] esxcli system maintenanceMode set --enable=true
[root@localhost:~] esxcli system maintenanceMode get
Enabled

f:id:japan-vmware:20170501215325p:plain

 

ファイルのプロファイルを確認します。

[root@localhost:~] esxcli software sources profile list --depot=/vmfs/volumes/LocalDisk900GB/ESXi650-201704001.zip
Name Vendor Acceptance Level Creation Time Modification Time
------------------------------- ------------ ---------------- ------------------- -------------------
ESXi-6.5.0-20170404001-standard VMware, Inc. PartnerSupported 2017-04-07T06:05:30 2017-04-07T06:05:30
ESXi-6.5.0-20170404001-no-tools VMware, Inc. PartnerSupported 2017-04-07T06:05:30 2017-04-07T06:05:30

f:id:japan-vmware:20170501215647p:plain

 

パッチを適用します。

 

[root@localhost:~]  esxcli software profile update -d /vmfs/volumes/LocalDisk900GB/ESXi650-201704001.zip -p ESXi-6.5.0-20170404001-standard

 

→30秒前後待ちます。

 

適用が成功するとこのような結果が返されます。

 

[root@localhost:~] esxcli software profile update -d /vmfs/volumes/LocalDisk900GB/ESXi650-201704001.zip -p ESXi-6.5.0-20170404001-standard
Update Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
・・・・略

f:id:japan-vmware:20170501220155p:plain

 

コマンド(reboot)を使ってESXiホストを再起動します。

f:id:japan-vmware:20170501220319p:plain

 

再起動後、さっそく
<ESXiホストのIP Address>/ui/

にアクセス&ログインしてみます。

 

!! 無事ログインして操作できました。

f:id:japan-vmware:20170501221231p:plain

 

きちんとバージョンがあがっていました。

 

[root@localhost:~] esxcli software vib list | grep esx-ui
esx-ui 1.18.0-5270848 VMware VMwareCertified 2017-05-01

f:id:japan-vmware:20170501221619p:plain

 
最後にメンテナンスモードを解除しておきます。

[root@localhost:~] esxcli system maintenanceMode set --enable=false
[root@localhost:~] esxcli system maintenanceMode get
Disabled

f:id:japan-vmware:20170501223631p:plain

 

■まとめ

接続するのが普通のWindows PC であれば、Chrome バージョンがどんどん更新されていくので、ESXiの VMware Host Client をChromeを使ってアクセスできなくなっているお客様は結構いるのではないでしょうか。

 

今回はesx-ui 1.15.0 から esx-ui 1.18.0 にバージョンアップしました。

 

■補足

IE はファイルのアップロードサイズが4GBというブラウザの制限があるため、
データストアに大きなiso ファイルを転送したりすることができません。
これがIEではなく、Chrome を使いたい一番の理由です。 

VMware vSphere 6.5 リリース ノート に記載もあります。

===============================

Internet Explorer を使用して、データストア ブラウザで 4GB を超えるファイルをアップロードしようとすると失敗する
Internet Explorer を使用してデータストア ブラウザで 4GB を超えるファイルをアップロードすると、次のエラーが表示されます。

Failed to transfer data to URL.

Internet Explorer は 4GB を超えるファイルをサポートしません。

回避策:データストア ブラウザでファイルをアップロードする場合は Chrome または Firefox を使用してください。

 ===============================

 

 

いろいろ踏んだり蹴ったりですが、今後ともVMware製品をよろしくお願いします。

 

オワリ

 

VMSA-2017-0006 パッチを適用する - パッチの適用手順

こんにちは。

 

VMware製品から2017/03/28 にクリティカルな脆弱性が公開されており、
日本語でも情報が出回っているので、少し記事にしたいと思います。
脆弱性の内容よりもパッチ適用の手順にフォーカスした内容です。

 

今回対象の脆弱性VMware社から既にSecurity Advisory が公開されています。

 

VMware Security Advisories - VMSA-2017-0006】

+ VMware ESXi, Workstation and Fusion updates address critical and moderate security issues
http://www.vmware.com/us/security/advisories/VMSA-2017-0006.html

CVE-2017-4902 ,CVE-2017-4903,CVE-2017-4904,CVE-2017-4905

 

日本語の情報サイトでも一部されていました。

http://www.security-next.com/080075

 

手元にESXi6.5の環境 がありましたので、パッチを適用しておこうと思います。

■手元環境
[root@localhost:~] vmware -v

VMware ESXi 6.5.0 build-5146846

 

■作業

アップデートを行う為のファイルをダウンロードします。
ダウンロード先は下記となりますのでこちらをご使用ください。

https://my.vmware.com/group/vmware/patch#search

ESXiの6.5から検索します。青いダウンロードボタンよりダウンロード可能です。

f:id:japan-vmware:20170403024928p:plain

 

ダウンロード後は、ESXiホストのデータストアにアップロードします。
データストアブラウザなどでアップロードしてください。

vSphere Client であれば対象のホストを選択し、[構成]タブより[ストレージ]を選択します。
 
空きのあるデータストアを選択し、右クリック、[データストアの参照]を選択し、
データストアブラウザ画面のメニューバーから上向きの矢印アイコンをクリックして、
アップロードするファイルの選択画面が出てきますので、ダウンロードしていたファイルを選択してください。アップロード完了後に×ボタンで終了してください。

 

Host Client でもvSphere Web Client でも同様のことができるので、好きなものを使ってデータストアにコピーしてください。

 

■ホストをメンテナンスモードにします。
右クリック、[メンテナンスモードへの切り替え]を選択します。
事前にESXi上で仮想マシンが稼働しないようにしておいてください。

(Host Client の例)

f:id:japan-vmware:20170403030720p:plain

SSH接続して事前確認

SSHではなくDCUI(コンソール)からでも構いませんが、操作性からTeratermなどでSSH接続して作業するほうが楽だと思います。

 

まずはパッチファイルのプロファイルを確認します。

[root@localhost:~] esxcli software sources profile list --depot=/vmfs/volumes/LocalDisk900GB/patch-module/ESXi650-201703002.zip
Name Vendor Acceptance Level
------------------------------- ------------ ----------------
ESXi-6.5.0-20170304101-no-tools VMware, Inc. PartnerSupported
ESXi-6.5.0-20170304101-standard VMware, Inc. PartnerSupported

f:id:japan-vmware:20170403031507p:plain

LocalDisk900GB はデータストア名です。
※現在のプロファイルは"esxcli software profile get"より確認できます。
※no-toolsはvmware-toolsを含まない形式です。 

 

■適用をする
[root@localhost:~] esxcli software profile update -d /vmfs/volumes/LocalDisk900GB/patch-module/ESXi650-201703002.zip -p ESXi-6.5.0-20170304101-standard

 

正常に適用されたら以下の結果が返ってきます。

===

[root@localhost:~] esxcli software profile update -d /vmfs/volumes/LocalDisk900GB/patch-module/ESXi650-201703002.zip -p ESXi-6.5.0-20170304101-standard
Update Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: VMware_bootbank_esx-base_6.5.0-0.15.5224529, VMware_bootbank_vsan_6.5.0-0.15.5224529, VMware_bootbank_vsanhealth_6.5.0-0.15.5224529
VIBs Removed: VMware_bootbank_esx-base_6.5.0-0.14.5146846, VMware_bootbank_vsan_6.5.0-0.14.5146846, VMware_bootbank_vsanhealth_6.5.0-0.14.5146846
VIBs Skipped: VMW_bootbank_ata-libata-92_3.00.9.2-16vmw.650.0.0.4564106, VMW_bootbank_ata-pata-amd_0.3.10-3vmw.650.0.0.4564106,

(略)

====

一応画像でも載せます。

f:id:japan-vmware:20170403032140p:plain

 

適用後はきちんと再起動をお願いします。
SSH接続のまま、Reboot コマンドで問題ありません。

 

再起動後、Build No が変わっていることを確認できれば完了です。

メンテナンスモードを解除して、利用を開始してください。

 

f:id:japan-vmware:20170403035647p:plain

細かく中身を見ていませんが、ESXi650-201703002 は容量から、差分のパッチのような気がしています。事前にそれまでのフルパッケージのパッチを適用しておくほうが安全です。

※ 

 

今回はこのへんで。

 

vSAN のコンポーネント分割はVMストレージポリシー以外にも分割されることがある

こんにちは。


今回はvmwareが推し推しのVSANに関する内容です。

皆様ご存知の通り、VSANは仮想マシンごとにストレージポリシーを割り当てて管理します。

vSphere Web Client でいうとホームの赤枠のところからポリシーを作成することができます。

f:id:japan-vmware:20170327021755p:plain

 

このVMストレージポリシーでは、どの程度のESXiホストの停止を許容するのか、

であったり、各ノードにどの程度(数)のコンポーネントに分割してデータを保持するのか、などを定義できます。(他にも項目はあります)

今回はVMストレージポリシーを以下の設定にします。

 

・Failures To Tolerate = 1 → ESXiホストの障害許容台数
・Disk Stripes Per Object = 3  → コンポーネントをどれくらい分割するか

f:id:japan-vmware:20170327022650p:plain

 

上記のVMストレージポリシー設定のとき、仮想マシンのデータはこのように配置されます。

f:id:japan-vmware:20170327235649p:plain

 

障害許容が1であるため、RAID 1 (ミラー)の中に、Stripe 3 つまりコンポーネントが3分割されて配置されている図です。

さて、ここまでは普通のvSANです。これからもただのvSANですが…

 

vSANの検証環境で触る際、巨大なvmdkファイルを持つ仮想マシンを配置することはあまりないかと思います。しかし、注意したいのは、おおきなvmdkファイル(例えば300GBとか)をvSANDatastore上に配置しようとすると、自動的にコンポーネント分割されることはご存知でしょうか。

 

VMwareからはこんなKB が出ています。

+ Using small magnetic disks for vSAN might result in VM failures

https://kb.vmware.com/kb/2080503

 

大きなファイルは、KBに記載されているパラメータ、VSAN.ClomMaxComponentSizeGB を超える容量になると、コンポーネント分割されるようになっています。

デフォルト値は255です。(ESXi6.0, ESXi6.5はそうでした)
私は検証環境の都合上、一番最小値の180にしています。

f:id:japan-vmware:20170328011234p:plain

 

では、すべてのvSANクラスタのESXiホスト3台にVSAN.ClomMaxComponentSizeGB=180 を設定し、200GBのvmdkファイルを所有する仮想マシンを作成し、vmdkファイルには 「Virtual SAN Default Storage Policy」を割り当てます。

f:id:japan-vmware:20170328012734p:plain

 

「Virtual SAN Default Storage Policy」はその名のとおり、デフォルトて作成されるポリシーであるがゆえに、以下の値に設定されています。


・Failures To Tolerate = 1 → ESXiホストの障害許容台数
・Disk Stripes Per Object = 1  → コンポーネントをどれくらい分割するか

 

では、200GBのvmdkファイルのときはどのように配置されているのか。

f:id:japan-vmware:20170328013446p:plain

 

ご想像のとおり、ESXiに設定したパラメータ VSAN.ClomMaxComponentSizeGB=180 を超えたため、1つのノード内で2つのコンポーネントに分割されました。
デフォルトとはいえ、VMストレージポリシーを設定していましたが、ESXiで設定していた容量を超えたため、パラメータ側を優先した格好になります。

 

ではあらためて、↓ この設定のVMストレージポリシーを200GBのvmdkファイルに適用します。

・Failures To Tolerate = 1 → ESXiホストの障害許容台数
・Disk Stripes Per Object = 3  → コンポーネントをどれくらい分割するか

f:id:japan-vmware:20170328015035p:plain

 

VMストレージポリシーがきちんと反映され、Stripe 3 なので、コンポーネントが3つに分かれています。

 

一度、VSAN.ClomMaxComponentSizeGB の設定値によって分割されても、

再度、内容が異なるVMストレージポリシーを設定すると反映されるということを知りたいがためにこんな記事を書きました。

 

ただし、確認はしていませんが、あまりに巨大なファイルをコンポーネント分割したときに、Stripe = 1 のようなVMストレージポリシーを適用しても、それは無視され、

VSAN.ClomMaxComponentSizeGBの値で分割されると思います。(推測)

 

オワリ