All TKB Articles in Global

■VxRail Rest APIについて VxRail ManagerではAPIを提供しており、APIを利用してVxRailのDNSやNTPの設定変更が可能です。 VxRail ManagerのAPIに関するドキュメントはAPI User Guideというものが提供されていますが、 Dell Technologies Developer というサイトにも各製品のProduct向けのAPIガイドがあり、 VxRailもこのサイトでAPI情報を提供しているため、Developer サイトにて新しい情報が展開されております。   Dell EMC VxRail API User Guide https://support.emc.com/docu91468_VxRail-Appliance-4.5.x,-4.7.x,-and-7.0.x-API-Guide.pdf   Explore APIs https://developer.dell.com/apis ⇒ VxRail API   実際の利用法としては、下記のURLへアクセスすることでGUIベースでのAPI利用が可能となっております。 https:// <VxRail Manager IP>/rest/vxm/api-doc.html   APIのメニューでは下記のような画面が表示されます。 画面ははDNS情報を取得するGet DNSのAPI例（オレンジ枠）です。 画面上にはそのAPIに関する情報や実際に実行するRequest（赤枠）や、 Responseコードごとの項目の説明（黄色枠）が提供されています。 またResponse結果例（紫枠）やサンプルコード（緑枠）も提供されています。   なお英語版のみとなりますがYoutubeでも動画にて利用方法についてご案内しておりますのであわせてご参照ください。 Getting Started with the VxRail API   VxRail API Overview   API利用方法の参考手順としてDNSの変更手順をご紹介します。 ※設定変更系のAPIを利用する際は作業前にVxRail ManagerやVCSAのスナップショットをご取得しておくことを推奨いたします   ■DNS変更手順例 ※NTPの場合は"Get DNS" や "Set DNS" の項目を"Get NTP" と "Set NTP" のAPIに置き換えて下さい   １．VxRail REST APIのページへアクセスします。 https:// <VxRail Manager IP>/rest/vxm/api-doc.html   下記のようなVxRail REST APIのOverviewが表示されます。 VxRail Manager Serverにて正しいVxRail Manager IP が表示されていることを確認してください。     画面左側に目的ごとにAPIが区分けされております。「＞」マークを押下することで、利用可能なAPIが表示されます DNSやNTPに関するAPIはSystem informationを展開してください   ２．現在のDNSの設定を確認するため、System information > Get DNS of VxRail cluster を選択します   ３． Get DNSのAPIのメニューに遷移しますので、画面右側のAuth欄に、User(administrator@vsphere.local) / password を入力し、「Send Request」を押下することでAPIを実行できます。   APIの実行結果が"Response"として表示されます。 実行結果については、「Responses」にあるレスポンスコードごとに情報がございます。   ４．次にDNSの値を変更するため、System information > Set DNS of VxRail cluster を選択します   ５．Set DNSのAPIのメニューに遷移しますので、IPアドレスの変更をAPIを利用して実行します ・画面右側のAuth欄に、User(administrator@vsphere.local) / password を入力   ・Body欄に必要な情報を入力します。入力に関する情報は画面左側の「Body」欄に情報があります。 - components："VXM" 又は "ALL"　を入力してください 　※VXMはVxRail Managerの変更、ALLはVxRail Manager/VCSA/ESXi の変更 (デフォルトではALL)   - 設定するServerが一つの場合は、下記のようにServersの項目を編集します（最後の","も削除してください）   情報を入力後、「Send Request」を押下することでAPIを実行できます。 ※下記Bodyの実行例は、componentsを"VRM"、serversに２つのIPアドレスを指定しているため、 　VxRail Managerの設定を指定した２つのIPアドレスに変更する、といったものとなります   APIの実行結果が"Response"として表示されます。 実行結果については、「Responses」にあるレスポンスコードごとに情報がございます。 （"200 OK"と出ていれば変更が正常に完了しています）       上記でAPIを利用したVxRailのDNS設定変更が完了します     ■補足 ●新しいDNSサーバーでの名前解決ができるかの確認について VxRail Managerにmysticユーザーでログインし、 digコマンドを利用することで新しいDNSサーバーで名前解決ができるか確認することが可能です。 変更前に必ずVxRail ManagerやVCSA, ESXiの名前解決ができるか確認をお願いいたします。   # dig @<DNS IP> -x <確認対象のIPアドレス> +short  # dig @<DNS IP> <確認対象のFQDN> +short    問題ない場合には以下のようにそれぞれ正逆ともに結果が返ります。 mystic@vxm-XXX:~> dig @<DNS IP> -x <確認対象のIP(例 ESXiのIP)> +short <確認対象のFQDN(例 ESXiのFQDN)>   mystic@vxm-XXX:~> dig @<DNS IP> <確認対象のFQDN(例 ESXiのFQDN)> +short <確認対象のIP(例 ESXiのIP)>    

VxRail上のvSphere製品のライフサイクルにつきまして ～ サポート期限は大丈夫ですか？～ VxRail上のvSphereをはじめとしたVMware製品につきましては、 VMware社のサポートポリシーにしたがって対応を行わせて頂いております。 2022/10/15以降 vSphere(vCenter/ESXi)6.5,6.7 はジェネラルサポートが終了し、 テクニカルガイダンスのフェーズとなることに伴うサポートの違いについてご説明致します。 VMware製品におけるサポートフェーズについて  VMware vSphere製品では以下の段階でのサポートフェーズがございます。 ・ジェネラルサポートフェーズ 　メジャーリリースの一般発売日(GA)からジェネラルサポート終了(Enc of General Support)    となる日時までの間、メンテナンスアップデートとアップグレード、不具合とセキュリティの修正、    技術情報の提供等が提供されます。 ・テクニカルガイダンスフェーズ 　ジェネラルサポートが終了してテクニカルガイダンスフェーズとなったバージョンでは、 　メンテナンス アップデートおよびアップグレード、新たなセキュリティ パッチやバグ修正、 　ハードウェアのサポート(ドライバ等含む)、サーバ/クライアント/ゲスト OS のアップデート 　等の提供がされなくなり、ジェネラルサポート終了日までに発見されている既存の問題や事例,     ドキュメント等の公開されている情報からのご案内のみのフェーズとなります。 　テクニカルガイダンスとなった時点で確認されていなかった新たな事象に関しましては、     基本的に不具合修正等は提供されない他、調査の結果として要因特定不可となり、     対処策としてその時点でのジェネラルサポートフェーズであるバージョンへのアップグレードを     ご提案させていただくことも多く、ご期待に沿った回答が行えない場合が御座います     (回避策をご提示させて頂くための前提条件として、バージョン更新を実施頂く場合が御座います)。  　※VMware社のサポートポリシーでは重要度 1(Sev1)のサポートは同フェーズでは行われておりません。          VxRailの場合にはSev1の場合弊社で受付させていただき調査等は行わせていただきますが、          その中でVMware製品の問題の可能性がある場合にはVMware社のサポートポリシーに準拠しますので、          それまでの既知事象として発見・公開されていない問題についてはジェネラルサポートフェーズの 　　  バージョンへのアップグレードのご提案となる場合がございます。 　※VxRail製品の場合にはテクニカルガイダンスフェーズとなった際にもお電話での受付も可能でございます ・サポート終了(EOSL) 　テクニカルガイダンスフェーズが終了しますと、サポート終了となります。 　この場合、ライセンスをお持ちであった場合でもライセンスの使用と、    お客様ご自身によるVMware Knowledgeの検索等は提供されておりますが、 　サポートへのVMware製品のお問い合わせ調査は行えなくなります。 　※VxRailの場合にはサポート終了となったバージョンをご使用の場合には 　　ハードウェア部分のみ対応が可能です。そのためまずはハードウェアの問題か否かを 　　拝見させていただき、ソフトウェア要因との判断に至った場合については、        対応致しかねる場合が御座います。   以上のことから、テクニカルガイダンスのフェーズとなったバージョンについては お客様のご期待に添えかねるサポート体験となる場合が御座いますので、あらかじめご了承ください。 テクニカルガイダンスのフェーズとなったバージョンをご使用の場合には、 お早めにジェネラルサポートフェーズのバージョンへのアップグレードをいただくことをおすすめいたします。 参考： VMware Product Lifecycle Matrix  https://lifecycle.vmware.com/#/ VMware のライフサイクル ポリシー  https://www.vmware.com/jp/support/lifecycle-policies.html 仮想基盤を将来にわたって安全かつ快適に使い続けるために〜vSphere のライフサイクル対応をしっかり検討〜(1/3)  https://juku-jp.vmware.com/solutions/vsphere-lifecycle-policy/

VxRailでは、VxRail Manager GUIにてクラスタのシャットダウンボタンを提供しており、 簡単にクラスタシャットダウンを実施できます。 しかしながらVMware KB#60424 (https:/kb.vmware.com/s/article/60424)で紹介されている通り、 vSAN環境では、シャットダウン手順によってはデータの不整合を引き起こす恐れがあり、 KBに従ったStepによってシャットダウンを実施することも可能となっております。   vSAN 6.7 Update 3以降では、VMware KB#60424の手順の簡略化として VMware KB#70650 (https://kb.vmware.com/s/article/70650) が公開されております。 本記事は、VxRail 4.7.300以降のすべてのVersionで適用されます。 また常にKB側を最新情報として必ずご確認ください。 ※本記事を公開するにあたり 十分検証確認を行っておりますが、データ保全に関して当アカウントは責任を負いかねますのであらかじめご了承下さい。 まず、大まかな流れとしては、下記のようになります。 ■Node起動編 　1. Nodeの起動 　2. メンテナンスモードの解除   ■vSANトラフィックの復活・仮想マシン起動編 　1. vSANトラフィックの復活 　2. すべてのESXiにてvSANに関する設定値変更のコマンド実施 　3. VCSA/PSCの仮想マシンを起動 ※VxRail 7.0以降ではVCSAのみ存在します 　4. vCLS VMの作成（retreat modeの無効化） ※本項目はVxRail 7.0.100 以降で必要です ※VxRail 4.7およびVxRail 7.0.100未満では不要となります 　5. vSphere HA のEnable 　6. vSANの健全性確認 　7. VCSA/PSC以外のすべての仮想マシンを起動   各Stepについて記載していきます。 ■Node起動編 　1. Nodeの起動 ※Nodeの起動前に各Nodeが接続されているTORスイッチが起動していることを確認してください 電源ケーブルを抜いている場合は接続し、iDRAC/BMC経由、又は物理的に電源ボタンを押してNodeを起動してください また、ESXiが正常に起動していることをモニターや仮想コンソールから併せて確認してください 　2. メンテナンスモードの解除（全てESXiで実施してください） "esxcli vsan cluster get | grep "Maintenance Mode State""にて、メンテナンスモードかどうかの確認（ON の場合、メンテナンスモード状態） "esxcli system maintenanceMode set -e false"にて、メンテナンスモードの解除を実施 # esxcli vsan cluster get | grep "Maintenance Mode State" # esxcli system maintenanceMode set -e false   ■vSANトラフィックの復活・仮想マシン起動編 　1. vSANトラフィックの復活 vSAN切り離しのScriptを1台のESXiで実行します（一番最後のESXiで実行など必ず1台のみで実施してください） ※「Cluster reboot/poweron is completed successfully!」が出力されることを確認します # python /usr/lib/vmware/vsan/bin/reboot_helper.py recover   [root@:~] python /usr/lib/vmware/vsan/bin/reboot_helper.py recover Begin to recover the cluster... Time among hosts are synchronized. Scheduled vSAN cluster restore task. Waiting for the scheduled task...(22s left) Checking network status... Network checking done. Cluster reboot/poweron is completed successfully!   　2. すべてのESXiにてvSANに関する設定値変更のコマンド実施 # esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates 　3. VCSA/PSCの仮想マシンを起動 ※VxRail 7.0以降ではVCSAのみ存在します シャットダウン時にメモしたESXiホストのHost Clientにログインし、VCSA/PSCの仮想マシンを起動する なお、PSC -> VCSAの順に仮想マシンを起動させていください またVxRail ManagerをDNSとして利用しているInternal DNS構成の場合は、VxRail ManagerをVCSAより先に起動させる必要があり、その後Solve Online上にも記載がございますが、VCSA仮想マシンの再起動とVxRail Manager内部のサービス再起動（またはVxRail Manager VM自体の再起動）の必要性がございます。   ※なおHost Clientは下記でアクセスが可能です https:// <ESXi host ip address> 　4. vCLS VMの作成（retreat modeの無効化） ※本項目はVxRail 7.0.100 以降で必要です ※VxRail 4.7およびVxRail 7.0.100未満では不要となります   　　4-1. vSphere Client へログイン 　　4-2. vCenter Server > 構成 > 詳細設定 > 右上の設定の編集を押下   　　4-3. 検索欄にて、vclsといった文字列でパラメータを確認   　　4-4. パラメータのFalseをTrueに変更し、保存を押下    　　4-5. vCLSが起動していることを確認 ※vCLSが起動している状態の場合には下図のような表示となります   　5. vSphere HA のEnable  外部vCenterにてvSAN Clusterを管理し、Shutdown前にDRSの設定を変更していた場合は、DRSも元の設定に戻してください   vSAN Cluster > 構成 > vSphereの可用性 の編集を選択    vSphere HAをEnable （下記状態がEnable の状態）   　6. vSANの健全性確認 下記を参照して、クラスタの健全性を確認します VxRail: Health Check 方法（https://communities.vmware.com/docs/DOC-40038）  vSAN Cluster > 監視 > vSAN > Skyline健全性（または健全性）> 再テスト 　7. VCSA/PSC以外のすべての仮想マシンを起動  VxRail Managerなど、その他の仮想マシンの起動を実施します   上記手順にてVxRail クラスタ起動手順が完了します

VxRailでは、VxRail Manager GUIにてクラスタのシャットダウンボタンを提供しており、 簡単にクラスタシャットダウンを実施できます。 しかしながらVMware KB#60424 (https:/kb.vmware.com/s/article/60424)で紹介されている通り、 vSAN環境では、シャットダウン手順によってはデータの不整合を引き起こす恐れがあり、 KBに従ったStepによってシャットダウンを実施することも可能となっております。   vSAN 6.7 Update 3以降では、VMware KB#60424の手順の簡略化として VMware KB#70650 (https://kb.vmware.com/s/article/70650) が公開されております。 本記事は、VxRail 4.7.300以降のすべてのVersionで適用されます。 また常にKB側を最新情報として必ずご確認ください。 ※本記事を公開するにあたり 十分検証確認を行っておりますが、データ保全に関して当アカウントは責任を負いかねますのであらかじめご了承下さい。   まず、大まかな流れとしては、下記のようになります。 ■事前準備編 　1. vSANの健全性確認 　2. vSphere HA のDisable   ■仮想マシン停止編 　1. VCSA/PSC以外のすべての仮想マシンをシャットダウン 　2. vCLS VMの削除（retreat modeの有効化）               ※本項目はVxRail 7.0.100 以降で必要です               ※VxRail 4.7およびVxRail 7.0.100未満では不要となります 　3. VCSA/PSCのシャットダウン               ※VxRail 7.0以降ではVCSAのみ存在します   ■vSAN切り離し・シャットダウン編 　1. すべてのESXiにてvSANに関する設定値変更のコマンド実施 　2. vSAN切り離しのScriptを1台のESXiで実行 　3. ESXiをメンテナンスモードに移行 　4. Nodeをシャットダウン   各Stepについて記載していきます。 ■事前準備編 　1. vSANの健全性確認 下記を参照して、クラスタの健全性を確認します。 VxRail: Health Check 方法（https://communities.vmware.com/docs/DOC-40038） 特に「データ」-「VSANオブジェクトの健全性」の項目にて、「健全」以外の項目がすべて0であることを確認します。 　    2. vSphere HA のDisable  Clusterの設定として vSphere HAが有効化されている場合には、Disableに変更します。  vSAN Cluster > 構成 > vSphereの可用性 の編集を選択                 vSphere HAをDisable（下記状態がdisableの状態）         なお外部vCenterにてvSAN Clusterを管理している場合、ESXiホストをメンテナンスモードに移行時に不要な仮想マシンの移動を防ぐため、DRSは"Manual(手動)"への変更を推奨させていただきます。   ■仮想マシン停止編 　1．VCSA/PSC以外のすべての仮想マシンをシャットダウン vCenter Server ApplianceとPlatform Service Controllerを除くすべての仮想マシンをシャットダウンします。 ※VxRail ManagerをDNSとして利用しているInternal DNS構成の場合は、VxRail Managerを停止するとDNSによる名前解決ができなくなるため、VxRail Manager VMのシャットダウンは、VCSA/PSCのシャットダウンのステップで実施してください 　2．vCLS VMの削除（retreat modeの有効化） ※本項目はVxRail 7.0.100 以降で必要です ※VxRail 4.7およびVxRail 7.0.100未満では不要となります retreat modeの有効化については、VMware KB:80472などに手順の記載がございます。 vSphere Cluster Services (vCLS) in vSphere 7.0 Update 1 and newer versions (80472) https://kb.vmware.com/s/article/80472 クラスタの退避モードへの切り替え https://docs.vmware.com/jp/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-F98C3C93-875D-4570-852B-37A38878CE0F.html   下記はvSphere Clientを使用した変更方法を記載します。 ※KB情報やVMware Docsを常に最新情報としてご認識ください 　　2-1. vSphere Client へログイン 　　2-2. Shutdown するVxRail Cluster を選択し、ブラウザのURLにある「domain-c<数字>」のような形式のクラスタのドメインIDをメモします 　　　 　　　   　　2-3. vCenter Server > 構成 > 詳細設定 > 右上の設定の編集を押下   　　2-4. 検索欄にて、vclsといった文字列ですでにパラメータが存在するか確認        存在する場合には、パラメータのTrueをFalseに変更し、保存を押下     存在しない場合には、下図のように名前（config.vcls.clusters.domain-c<数字>.enabled）と値（False）を入力し、 追加ボタンを押下、vCenter Server の詳細設定の編集の保存を押下 ※数字の欄を2-2で確認した値に書き換えてください 　　2-5. vCLSが3台シャットダウンされ、削除されたことを確認 ※vCLSが起動している状態の場合には下図のような表示となります     　                 3. VCSA/PSCのシャットダウン ※VxRail 7.0以降ではVCSAのみ存在します 起動時に困らないように、PSCおよびVCSAが稼働しているESXiホストをメモするか特定のESXiホストへvMotionを実施します。 シャットダウンの手順は様々ありますが、下記は例としてVAMI（アプライアンス管理インターフェース）からのシャットダウン手順をご案内します。 VAMI（アプライアンス管理インターフェース）へアクセスするには、それぞれ、VCSA/PSCのIP address宛にhttpsで5480ポートを指定してアクセスできます。 https://VCSA-ip-address:5480/ https://PSC-ip-address:5480/   ■vSAN切り離し・シャットダウン編 　●事前作業 　各ESXiホストのsshを有効にする 　※以下サイトに、ESXiのsshを有効にする方法がございます 　　・VxRail: ESXi、vCenter、PSCのSSH有効化 　　　https://communities.vmware.com/docs/DOC-39994 　1. すべてのESXiにてvSANに関する設定値変更のコマンド実施 # esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates   　2. vSAN切り離しのScriptを1台のESXiで実行（一番最後のESXiで実行など必ず1台のみで実施してください） 　※Cluster preparation is done! と結果が出ましたら問題ございません。 # python /usr/lib/vmware/vsan/bin/reboot_helper.py prepare 　3. ESXiをメンテナンスモードに移行（全てESXiで実施してください） "esxcli vsan cluster get | grep "Maintenance Mode State""にて、メンテナンスモードかどうかの確認（ON の場合、メンテナンスモード状態） "esxcli system maintenanceMode set -e true -m noAction"にて、No Actionのオプションでメンテナンスモードへ移行実施 # esxcli vsan cluster get | grep "Maintenance Mode State" # esxcli system maintenanceMode set -e true -m noAction   　4. Nodeをシャットダウン（全てESXiで実施してください） vSphere Host Client または、DCUIよりESXiのシャットダウンなど手順は様々ありますが、CLIでの実施も可能です # esxcli system shutdown poweroff -r ClusterShutdown   DCUIの場合、仮想コンソール（または実機のコンソール）を開き、[Alt] + [F2]を押してESXiの画面に移動してから、[F12] を押しESXiのroot userでLoginを実施 なおpassword入力時は、"Login name"の部分で正しくキーボード入力されるか確認してから実施すると良いです 仮想コンソールのキーボード設定によって"@"などの位置が違う場合がございます "Shutdown/Restart"のMenuが表示されるので、[F2] Shut Downを選択してESXiのShutdownを実施してください   上記手順にてVxRail クラスタ停止手順が完了します ※シャットダウンを実施してもiDRACへの接続が可能なのは問題ありません

ゲストOSをMS-DOSで使用しています。 ホストOSのシリアルポートを使って、外部機器と通信をおこなっています。 起動時には通信のやり取りが正常に行えるのですが、通信の負荷があがるとゲストOSからの返信がなくなってしまいます。 通常は外部機器からの信号に対して、常に返信をします。 一度返信が途切れると、MS-DOSの再起動かVMworkの再起動で復帰します。 VMworkの serialport_number.pipe.charTimePercent = "time" 設定を調整しましたが、通信が途切れる現象は止まりません。 timeを５～20くらいにすると多少は安定するのですが、、 何か、他に設定する項目等ありますでしょうか？ 〇メインOS　Windows10 Pro 〇ゲストOS　MS-DOS6.22 〇構成　Windwos10 PC(VMwork[MS-DOS])<==RS-232==>外部機器 〇RS-232C 162000bps/8bitデータ/1ストップbit /偶数パリティ VMware Technology Network Global Japanese

  Symptoms   2021/01/12 以降にvSphere Web Client にアクセスした際に以下のようなマークが表示され、ページが表示できない     ※ Flash の実行がサポートされないブラウザの場合は Flash の実行ができず、上記のような表示にはなりません。     Cause   上記の事象は、Adobe Flash Player がサポート終了となったことによる影響です。 Adobe Flash Player は2020/12/31をもってサポートが終了しており、新規のダウンロード・インストールができません。 Adobe 社公開情報には以下の記載があります。               ◼Flash Player のサポートが終了するのはいつですか？ 2020 年12 月31 日をもってアドビによるFlash Player の配布と更新を終了します。 ◼2020 年末を過ぎても、アドビから旧バージョンのAdobe Flash Player をダウンロードできますか？ いいえ。アドビは自社サイトからFlash Player のダウンロードページを削除します。また、Flash ベースのコンテンツは、サポート終了日以降、Adobe Flash Player での実行がブロックされます。アドビは、常に最新のサポート対象ソフトウェアを使用し、更新することを推奨しています。アドビのサポート終了日後はFlash Player を使用しないでください。           引用:https://www.adobe.com/jp/products/flashplayer/end-of-life.html     2021/01/12 以降は、Adobe Flash Player の実行がブロックされることにより、vSphere Web Client (Flex Client ) が表示できなくなります。 なお、Adobe Flash Player やブラウザの自動更新設定をしていなくても、2021/01/12 を迎えると発生する可能性があります。 また、VMware 製品に限らず、Adobe Flash Player を利用するアプリケーションはすべて影響を受けます。 本Documentでは、VMware KB 78589  をベースとし、vSphere に焦点をおいて説明してます。   Solution   ウェブブラウザを使用するVMware 製品の機能の一部が利用できなくなる可能性がありますので、 VMware KB 78589 をご覧の上、影響を受ける製品の確認及び対処策の実施をする必要があります。 https://kb.vmware.com/s/article/78589?lang=ja   基本的には、上記KBに記載のある、推奨される最小バージョンにアップデートいただく必要があります。   なお、vSphere Web Client の中でプラグインとして稼働していたサードパーティ製品が存在している場合、HTML5 版のvSphere Client に対応しているか各プラグインのベンダー様へ確認が必要です。 影響を受ける製品について、推奨される最小バージョン（KB 78589  参照）以上へのアップデートが難しい場合、または何らかの事情ですぐにアップデートができない場合、Adobe Flash Player で提供されている“エンタープライズ向け機能”を設定することで一時的に利用可能になります。 エンタープライズ向け機能の設定方法については、KB 78589  に記載されているものとなりますが、VMware社によってサポートされた手順ではないため、お客様の責任にてご利用いただく必要がある点についてはご留意ください。   そのため、あくまでも 推奨される最小バージョンへのアップデートのみが唯一の公式な回避策であり、“エンタープライズ向け機能”の設定による回避策はアップデート完了までの一時的な WorkAround として利用する必要があります。   VMware社は、サポート期間内の VMware 製品については引き続き Flash ベースのユーザー インターフェイスをサポートする予定ですが、Flash ベースのユーザー インターフェイス が利用できないことによる不利益や、代替手段の確認についてはユーザの責任範囲となる可能性がございますので、可及的速やかに推奨される最小バージョンにアップデートいただくことを推奨します。   以下では、“エンタープライズ向け機能” の設定方法について、VMware KB 78589  を補足する形で説明します。 WorkAround にて設定している内容は以下です。 Adobe Flash Player のアンインストールを促す不要なプロンプトを無効化 Adobe Flash Player でコンテンツの読み込みを許可するURL を指定   ※重要１※ この WorkAround はブラウザが Adobe Flash をサポートしている必要があります。 Google Chrome の場合は、Version 87 以降、 Firefox の Version 85 以降で Flash の実行がサポートされませんので、この WorkAround はご利用いただけません。 Firefox End of Adobe Flash Support https://support.mozilla.org/en-US/kb/end-support-adobe-flash Chome 87 Release Note https://storage.googleapis.com/support-kms-prod/jwLVBIqFYztdeLT3nYiOMuqEb67g6b2mKviN ”Important: ​Adobe will no longer update and distribute Flash Player after ​December 31, 2020​. After this date,all versions of Chrome will stop supporting Flash content.”   ※重要２※ WorkAround を実行するためには、ご利用の端末にすでにAdobe Flash が Install 済みである必要があります。 Adobe Flash の EOL 以降、Adobe Flash を新規に Download＆ Install することができなくなっております。 EOL 前に Adobe Flash がインストール済みである必要があります。   ※重要３※ サポートされるブラウザや、Adobe Flash を準備できない場合は、こちらの WorkAround が利用できませんが、 Dell Technologies が提供する VNX Launcher を利用することで、Flash 版の GUI にアクセスできることが知られています。 本来の用途とは異なるため自己責任となりますが、どうしても必要な場合はご検討ください。 VNX Launcher の Install 方法 （Installer のダウンロードには Dell サポートサイトのアカウント登録が必要） https://www.dell.com/support/kbdoc/en-sg/000019852/vnx1-vnx2-how-to-install-vnx-launcher-that-has-embedded-java-and-firefox-user-correctable     設定方法は以下です。 Task 1 利用しているブラウザのmms.cfg ファイルを開きます。 mms.cfgファイルの場所は使用しているオペレーティングシステムとブラウザによって異なります。 ファイルの配置場所については、VMware KB 78589 、もしくはベンダーのドキュメントをご参照ください。   Internet Explorerの場合の注意点 VMware KB 78589  の記載がわかりにくいですが、 IE（32bit）の場合は、%windir%\System32\Macromed\Flash\mms.cfg IE（64bit）の場合は、%windir%\SysWOW64\Macromed\Flash\mms.cfg になります。 mms.cfg ファイルがない場合はテキストドキュメントとして新規作成してください。   Google Chrome および Edge Chromium の場合の注意点 ”System” フォルダ、および mms.cfg ファイルが存在しない場合は、手動で作成する必要があります。   参考詳細手順（Google Chromeの場合） Step 1 %localappdata%\Google\Chrome\User Data\Default\Pepper Data\Shockwave Flash\ のフォルダにアクセス Step 2 新規フォルダを作成する。 Step 3 作成したフォルダの名前を変更して、System にする Step 4 作成したSystem フォルダ内に、テキストファイルを作成し、mms.cfgと名付ける   Task 2 Task 1で作成したmms.cfg に以下の設定を書き込む             EOLUninstallDisable=1 EnabledAllowList=1 AllowListPreview=1 AllowListUrlPattern=https:// <vCenter Server FQDN> /              参考画像：FQDN 記載時 参考画像： FQDN および IP アドレスの両方を記載時   留意事項 FQDN で記載した場合、vSphere Web Client にアクセスする際も FQDN でアクセスする必要があります。 IP アドレス でアクセスする場合は、FQDN ではなく IP アドレスで記載する必要があります。 AllowListUrlPattern の行は複数書くことができますので、FQDN と IP アドレスの両方を記載しておくことを推奨します。 また、対象となるVCSAが複数ある場合も同様に AllowListUrlPattern を複数記載してください。 ※外部型PSC構成の場合でも PSC の FQDN/IP アドレスの記載は不要です。 なお、AllowListUrlPattern にはワイルドカード文字である * (アスタリスク) を利用可能です。 ワイルドカードの利用については以下の制限があります。 ・ IPアドレス表記の場合はワイルドカードを利用できない ・ワイルドカード文字の後には、二つ以上のラベルを含む必要がある。すなわちFQDNのうちトップレベルドメインとセカンドレベルドメインは最低限含まなければならない OKな例：AllowListUrlPattern=https://*.example.com/ NGな例：AllowListUrlPattern=https://*.com/       <<<<  * の後に.comしかないためNG    その他、mms.cfg への記載方法についてはAdobe 社の公式ドキュメントをご参照ください（P.28以降） https://www.adobe.com/content/dam/acom/en/devnet/flashplayer/articles/flash_player_admin_guide/pdf/latest/flash_player_32_0_admin_guide.pdf Task 3 ブラウザからページの更新（F5ボタン）、もしくはブラウザを再起動し、mms.cfg ファイルに追加した vCenter の vSphere Web Client に再度アクセスして、表示されることを確認します。 うまくいかない場合の対処 本 Work Around は、VMware KB に記載のある手順となりますが、KB に記載の通り、VMware 社は本手順をサポートしておりません。 期待通りの動作とならない場合は、Microsoftなどの OS ベンダーや、Adobe社にお問い合わせいただく必要があります。     Reference VMware KB （日本語） https://kb.vmware.com/s/article/78589?lang=ja Adobe_Flash_Player_Administrator_Guide__ （mms.cfg の記載方法） https://www.adobe.com/content/dam/acom/en/devnet/flashplayer/articles/flash_player_admin_guide/pdf/latest/flash_player_32_0_admin_guide.pdf\ Adobe Flash Playerサポート終了情報ページ https://www.adobe.com/jp/products/flashplayer/end-of-life.html          

     この文書はVxRail 4.5.x/4.7.x -> 7.xへのUpgradeに関連する変更点や留意事項についてまとめています。      Dell EMCの公式文書や実際の事例をもとに記載しておりますが、正式な内容については公式文書を正とし、本文書は参考資料としてお使いください。       公式文書と差異がある場合はこちらのドキュメントを劣後としてください。   ## VxRail: 4.5.x/4.7.x -> 7.0 へのUpgradeに事前と事後の留意点について ##     Upgrade前の留意点   VxRail 4.xと7.xの差異についてのサマリ もっとも大きな差異はvSphere のVersionが変わることです。 VxRail 4.0.xの場合はvSphere 6.0系です。 VxRail 4.5.xの場合はvSphere 6.5系です。 VxRail 4.7.xの場合はvSphere 6.7系です。 VxRail 7.x の場合はvSphere 7.x 系です。 vSphereと連携するSolutionの互換性について事前の確認が必要になります。   Solutionの互換性以外では、vSphere 7.0へのUpgradeに伴い以下のような代表的な変更が発生します。   Internal VCSA/PSCが一つの仮想マシンに統合される VxRailの構築時にInternal VCSAを選んだ場合、VCSAおよびPSCは独立した仮想マシンとしてDeployされておりますが、 VxRail 7.0へUpgradeを実施すると自動的に一つの仮想マシンへ統合が実施されます。 その際にはVCSA VMが新規にDeployが実施され,VxRailで使用しているSubnetと同一のテンポラリー IPをお一つ準備していただく必要がございます。 なお、VxRail 4.7までPSC VMが利用していたIPアドレスは、VxRail 7.0へのUpgrade後は空きとなります。 使用できる機能などに変化はありません。   vSANのVersionが7.xになる vSAN Native File Serviceなどの新機能が使用可能になります。 新機能の使用にはDisk Format のVersion Upgradeが必要です。 その他vSAN7.x系の新機能の詳細についてはVMware社のドキュメントをご参照ください vSAN/vSphere/VxRailのVersionは、それぞれ一対一で対応します。対応表はこちらのドキュメントをご参照ください。     GUIの仕様が変わる VxRail 7.0(vSphere 7.0)ではvSphere Client(HTML5版)のみ使用可能でFlash版に関しては廃止されておりま 詳細については下記のKBをご参照くださ vSphere 7 アップグレードのベスト プラクティス (78205) https://kb.vmware.com/s/article/78205?lang=ja​ vSphere 7.0 では、Flash ベースの vSphere Web Client は廃止され、使用できなくなりました。     詳細なUpgrade前後のVersionの確認方法について Upgrade前後のSolutionの互換性を確認するにあたり、まずは詳細なvSphere コンポーネントのVersionを知る必要があります。   Upgrade前（VxRail 4.5.x/4.7.x）のVersionについてはVxRail のVersionがわかれば確認できます。 もしくは、WebClientなどから各コンポーネントのVersionをご確認いただくこともできます。   VxRailのVersionがわかる場合はRelease Noteから詳細なvSphere コンポーネントのVersionを確認可能です。   ・VxRail 4.5.x / 4.7.xリリースノート（英語のみ） https://support.emc.com/docu86659_VxRail-Appliance-Software-4.5.x-Release-Notes.pdf https://support.emc.com/docu91467_VxRail_Appliance_Software_4.7.x_Release_Notes.pdf   VxRail4.5系 の場合はVxRail Manager GUIより現在のVersionを確認可能です。以下の図をご参考にしてください ※以下の例はVxRail 4.0系ですが、4.5系でも同様です。     VxRail 4.7系の場合はvSphere Client （HTML5）より確認可能です。以下の図を参考にしてください。   Upgrade後のVersion（ターゲットVersion：VxRail 7.x）のvSphere コンポーネントの詳細についてはVxRail 7.xのリリースノートをご参照いただけます。 VxRail7 Release Note https://support.emc.com/docu98130_VxRail-7.0.x-Release-Notes.pdf     Upgradeパスと制限事項について !!! 重要 !!! VxRail 4.5/4.7からのみUpgrade可能 vSphereの制限と同様に、VxRailもVersion 4.0.x 系（vSphere 6.0系）からVxRail 7への直接のUpgradeはできません。現在のVersionに応じて２～３段階のUpgradeが必要となります。 それに伴いUpgrade時間が多くかかりますので作業調整には考慮が必要です。（VxRailは1回のUpgradeで１Nodeあたり1～2時間程度必要）   VxRail 4.7.411からVxRail 7.0.000へのUpgradeはできない VxRail 4.7.411からVxRail 7  GA VersionへのUpgradeはサポートされておりません。 VxRail 4.7.411からVxRail 7にUpgradeする場合はVxRail 7 次期リリース（vSphere 7 P1 or U1） を待たなくてはいけませんので、VxRail 7 (vSphere/vSAN 7)へのUpgradeが必要になることが予想される環境では4.7.411へはUpgradeはせずに、4.7.410を採用する必要があります。 同じことがNode追加にも言えます。VxRail 4.7.410で初期化されたNodeはVxRail 7に追加できますが、4.7.411で初期化したNodeはVxRail 7に追加できません。 VxRail 7 Clusterに追加できるVxRailのVersionについてはVxRail Add Node Matrixをご参照ください。 ※VxRail 7にVxRail 4.7.xのNodeを追加した場合、追加時の追加したNodeが自動でVxRail 7にUpgradeされます。Versionが混在するわけではありません。   Quanta Modelは4.7.xで終了 Quanta ModelはVxRail 7へUpgradeできません。Quanta Modelを含むクラスターはVxRail 7へのUpgrade時に事前チェックエラーとなって、Upgradeに進むことができません。   GPUを利用している場合はVxRail 7 GA (7.0.000)へのUpgradeができない GPUを利用されている環境の場合、Driver側の対応状況などの問題でUpgradeを実施することができません。次期リリースを待つ必要があります。   その他の制限 VxRailの標準の以外のDriverやVIBなどをご利用されている場合、VxRail 7.0.000（vSphere 7 GA）との互換性がない場合があります。例； vmkapi Dependency error while Installing/upgrading to ESXi 7.0 (78389) https://kb.vmware.com/s/article/78389     VxRail標準以外のVIBやDriverなどを利用されている場合は、各ベンダーに対応状況についてご確認ください。   Upgrade方法に関する制限事項 VxRailではUpgrade方法として以下の二つをサポートしています。 作業端末からUpgradeファイルをUploadするLocal Upgrade VxRail ManagerがInternet経由でUpgradeファイルを取得するInternet Upgrade 2020年5月現在で、VxRail 4.5/4.7から7.xへのUpgradeについて、Internet Upgradeは利用できません。（ACEからのUpgradeも同様） VxRail 7へのUpgradeは注意事項も多いため、SolveOnlineの手順書や、ReleaseNoteを読まずにUpgradeに進んでしまうことを防ぐ措置となっています。   また、vSphere 7から導入されたvLCMについてもVxRailでは利用できません VxRail7でvLCMによるUpgradeを実施しようとすると、Blockされる仕組みになっております。   vSphere と連携するソフトウェアの互換性について お客様にてご使用中のvSphere と連携するVMware / 3rd Solutionがある場合、各Solutionのアップグレードが事前もしくは事後に必要になる可能性があります。 VxRail関連のバージョンにVMware Solutionが対応しているか否かは以下をご確認いただけます https://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php   更新の順序については以下のVMware KBをご参照ください。 Update sequence for vSphere 7.0 and its compatible VMware products (78221) https://kb.vmware.com/s/article/78221?lang=en_US     例： VDP はVxRail 7では利用できません。 NSX-v 6.4.7、もしくはそれ以前のVersionを利用されている場合は、VxRail 7へのUpgradeはできません。      ※NSX for vSphere をご利用の場合の留意事項についての詳細は以下のKBをご覧ください。           （参考）Dell EMC KB#524819 および Dell EMCKB#530299 3rd Party Solutionにつきましては各ベンダに互換性をご確認ください。   Recover Point for VMは、VxRail 7.0.000ではサポートされておりません。（2020年5月1日現在） Recover Point for VMをご使用の際には、VxRail 7.0.000へのUpgradeはできません また、05/01 現在のRecoverPoint for VMに関しては、vSphere Client(HTML5版)に関してサポートされておりません RecoverPoint for VMs: RP4VM Plugin doesn't work in HTML5(H5) web client https://support.emc.com/kb/510651 ↑その後サポートされています   NSXがある場合のMajor Upgradeの考慮事項 https://www.dell.com/support/kbdoc/en-us/000019144/dell-emc-vxrail-major-version-upgrade-for-vxrail-with-nsx Dell EMC VxRail: Major version upgrading VxRail with NSX-T in place | Dell US   vSphere7でサポート外となるコンポーネントについて VDS version 6や、仮想ハードウェアVersion 4（追記：その後のVMware KBの修正により対応になってます）などは、Upgrade後のvSphere7では対応しておりません。 これらのコンポーネントが存在する場合は、Upgrade失敗や、Upgrade後の動作不良につながる可能性がございます。 対応外となるコンポーネントついては事前に更新をお願いいたします。 Uprade Requirement https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vcenter.upgrade.doc/GUID-49E8A38B-A356-4665-8F95-38163FB3A220.html Distributed Virtual Switch at unsupported version https://kb.vmware.com/s/article/52826 compatible virtual machine hardware versions list https://kb.vmware.com/s/article/2007240     VxRailで利用するVMwareライセンスのUpgradeに関する留意点 VxRail 4.x (vSphere/vSAN 6.x) からVxRail 7（vSphere/vSAN 7.x）にUpgradeされることにより、vSphere/vSANライセンスもUpgradeする必要があります。 vSphere6.x/vSAN6.xで利用していたライセンスをそのままvSphere7.x/vSAN7.xで利用することはできません。 VxRail 7 (vSphere 7)にUpgradeした直後は再び60日間の評価ライセンスが有効になりますので、ライセンスを準備できていなかったとしても即座に問題が発生するわけではありませんのでご安心ください。 VxRail 7 へのUpgradeに関連して確認、および対応が必要となるライセンスは、vSphere、vSAN、vCenterの３つです。   VxRail環境のvSphere（ESXi）のライセンスについては、お客様にて管理されているものとなりますので、MyVMwareにお客様のアカウントでログインしていただき、ライセンスのUpgradeを実施したうえで再適用する必要がございます。   vSANライセンスについては、VxRailのEmbedded License（VxRail 4.5.x以前）と、OEMライセンス（VxRail 4.7.x以降）によって対応が異なります。 Embedded Licenseの場合は、VxRailのUpgradeの際に自動でライセンスが書き換わりますので事前準備や当日のライセンス関連の作業は不要となります。 VxRail 4.7以降で導入し、OEMライセンスを購入されているものに関しては、ライセンスはお客様管理となりますので、MyVMwareからvSANライセンスをUpgradeしていただき、VxRailに適用する必要があります。   vCenterライセンスに関しては、Internal VCSAを利用されている場合は、Embedded Licenseとなりますので事前準備や当日のライセンス関連作業は不要です。 External VC構成の場合は、Upgradeおよびライセンス管理はお客様にて実施いただく作業となります   まとめると以下となります。       4.5.x 以前に導入したVxRail Cluster 4.7.x以降で導入したVxRail Cluster vSphere 必要 必要 vSAN 不要 必要 Internal VCSA 不要 不要 External VC 必要 必要      表１． ライセンスアップグレード作業の要否   対応が必要な場合のライセンスUpgrade方法及び適用方法については、下記のドキュメント及びコミュニティをご参照ください。 Administration Guide 7.0 https://dl.dell.com/content/manual47937902-dell-vxrail-7-0-x-administration-guide.pdf License VxRail   How to Upgrade or Downgrade License Keys in Customer Connect with troubleshooting steps (81665) https://kb.vmware.com/s/article/81665?lang=ja   VxRail：VxRailに使用するVMware License keyの取得、適用方法 https://communities.vmware.com/t5/Japanese-Documents/-/ta-p/2775568 4. vSphere ライセンスキーの割り当てに関して     VxRailのライセンスにバンドルされるソフトウェアコンポーネントに関する留意点   VxRailに含まれるソフトウェアコンポーネントのすべてがUpgrade作業によってUpgradeされるわけではありません。   VxRailのUpgrade作業によってUpgradeされるコンポーネントは以下です。 ※VxRail Upgradeファイル以外の更新（個別のVIBやパッチを適用）を実施することはサポート外になりますのでご注意ください。 ・ESXi（追加のVIBも含む） ・VSAN ・VCSA/PSC（外部VCの場合は除外） ・Firmware （BIOS,iDRAC,HBAなど、Versionやモデルに依存します。） ・VxRail Manager VM   Upgradeされないものは以下です。 ※UpgradeはVersion管理（互換性など）はお客様管理になります。 ・VDP （お客様作業になります。参考手順：VxRail: vSphere Data Protection の Upgrade手順 （参考資料） Part 1​ , VxRail: vSphere Data Protection の Upgrade手順 （参考資料） Part 2  ) ・RP4VM  （別途サポート窓口にお問い合わせください） ・CloudArray （別途サポート窓口にお問い合わせください） ・Loginsight （お客様作業になります。 参考手順： vRealize Log Insight のUpgrade  （参考資料）  ） ・ESRS （お客様作業になります。 参考手順： VxRail: ESRSVE VMのUpdate 手順（参考資料）  ） ・既存VMのHardwareVersion（Intel CPUの脆弱性の対応で必要です） ・ESRSの内部イメージ（内部イメージは出荷時から変わりません） ・ESXiのファクトリーイメージ（出荷時から変わりません） ※ その他vSphereと連携するDell EMC製品（UnityVSA、IsilonSD Edge、AvamaerVEなど）についてはサポート窓口にお問い合わせください。 ※ その他vSphereと連携するSolution（NSX/VDI/vRangerなどその他3rdパーティ製品すべて） についてはすべてお客様作業範囲となります。   SSL証明書に関して VxRail ManagerのSSL証明書の置き換えなどを実施している場合、Pluginが正常に動作しない事象が報告されています。 下記のKB：530378をご参照ください。 VxRail : How to prevent vCenter plugin issue caused by VxRail Manager SSL certificate mismatch https://support.emc.com/kb/530378     Upgrade時に準備いただくもの 4.x -> 7xのUpgradeの際に以下をお客様にご準備いただきます。   ・一時IPアドレス（１つ） ※Internal VCSA/PSCを利用している場合のみ VxRailのUpgradeの際に一時的に利用されます。 VxRail 4.x -> 7.x のUpgradeの際にVCSAとPSCのVersionが6.x -> 7.xに変わります。 このUpgradeは従来のOS内部の更新という形ではなく、新規VMの構築＆データ移行という形で実行されます。 そのため旧VCSA/PSC（6.x）から新VCSA/PSC（7.x）へのデータ移行する際に、新VCSA/PSCへ仮のIPアドレスを割り当てる必要があり、その際に使われる一時的なIPアドレスが、一時IPアドレスです。 Upgrade完了後はそれまでのVCSA/PSCのIPアドレスが使用されますので、一時IPアドレスがUpgrade後も使用されることはありません。 一時IPアドレスはVCSA/PSC/VxRail Managerと同じサブネットのIPアドレスでご用意ください。 一時IPアドレスの確保が難しい場合はLogInsight VMやESRSVE VMなどUpgrade時に必要のないSystem VMをShutdownし、そのIPアドレスを利用することができます。   ※一時IP Addressは未使用でかつ同じサブネットでなくてはいけません。もし条件に満たしていないIPが使用されていた場合はUpgradeに失敗します。（KB#522181） ※VCSA/PSCのMigrationが完了したのち、新規VCSA/PSCのIPアドレスが一時IPから本来のIPアドレスにつけ変わります。IPアドレスの改ざんやなりすまし防止機能が働いている環境では設定を無効化、もしくは例外設定としてください。（NSX Spoof Guardなど） ※一時IPは一時的ですがVCSA/PSCと同じネットワーク要件を満たす必要があります。DNS/NTPサーバへのアクセスをIPアドレスでフィルターしている場合は、一時IPからのDNSおよびNTP接続も許可する必要があります。 ※前述の通りVxRail7へのUpgrade完了後に、Internal VCSA/PSCは統合されて、PSC VMはなくなります。結果としてPSC VMが利用していたIP Addressは欠番となります。   ・Zoom端末（Dell EMCにUpgradeを依頼する場合のみ） Dell EMCの保守契約に付随する無償のUpgradeサービスを利用する場合はZoom経由での作業となります。 端末は物理マシンでも仮想マシンでもどちらでも構いません。 ※VxRail上の仮想マシンでも構いませんが、vMotionなどの妨げになる可能性もあるため推奨しません。 利用されるZoomでは以下のスペックが推奨されます。(トラブルシューティングでの利用も想定) CPU： 2GHz以上が2コア以上 メモリ：8GB以上 Disk：空き容量が20GB以上 リソース優先度：標準以上 また、以下のアプリケーションが準備されていることが望ましいです。(トラブルシューティングでの利用も想定) SSHクライアント（TeratermやPuttyなど） WinSCPなどのSFTP/SCP クライアント WebClientを起動可能なFlash対応ブラウザ Java（JRE）     Upgrade前の事前チェックスクリプト Dell EMC KB#536801 にVxRailのUpgrade前に実施するPrecheckスクリプトが公開されてます。 ※Precheckスクリプトは過去の事例などを元に作成されており、Upgrade結果を保証するものではございませんのでご留意ください。 ※閲覧にはDell EMCオンラインサポートへのアカウント作成が必要です。   Upgrade前のvSAN データストア使用容量確認とリバランスとの必要性について VxRailのUpgrade前には、vSANのすべてのキャパシティディスクの容量使用率が70～75%以下であることが推奨です。 推奨される理由は以下です。 VMwareの推奨事項であるvSANの容量使用率に準拠するため。 単体Disk使用率が80%を越えた場合に発生する自動リバランスを避けるため   容量使用率について、VMwareの推奨を守ることはデータ可用性や安定稼働の観点で重要です。 それ以外にも、自動リバランスが発生するとVxRailのUpgradeが停止してしまう、という問題があります。 VxRailのUpgrade見積時間にはリバランス待ちは含まれないため、作業時間が想定よりも大きく上回る可能性があります。 Upgrade中にリバランスが発生しないようにvSANデータストアの使用容量を確認し、容量が多い場合は、少なくとも75％以下に減らすことを推奨します。 また、vSANデータストア全体としての使用容量が少ない場合でも単体Diskの使用容量が80%に近い場合は事前にリバランスが必要です。 リバランスについては下記の記事が参考になります。      VxRail: 「Virtual SAN ディスク バランス」の警告の詳細と対処      VxRail: CLIによるvSANリバランス   Secure Boot設定に関する留意事項 VxRail 7.0.000からSecure BootがEnableでもUpgradeが可能となっておりますが、すべての環境において可能ではございませんのでご注意ください。 状況が不明な場合はSecure BootをDisableにしたのちにUpgradeされることをお勧めします。 参考KB : https://support.emc.com/kb/529655   VxRail の各Nodeの型番とVersion Upgrade時のSecure Boot設定 VxRail 13G （E460/F、P470/F など） Disableが必須 VxRail 14G  with VxRail 4.7.410 （E560/F、P570/F など） Enableでもよい VxRail 14G  with 4.7.410未満 （E560/F、P570/F など） Disableが必須     System VMのSnapshotの事前取得 ここでのSystem VMとは、VCSA/PSC/VxRail Managerの３つを指します。 VxRail 7へのUpgrade時に自動でSnapshotが作成されますが、自動作成のSnapshotは自動で削除されてしまいますので、万が一に備えてお客様が事前にSnapshotを作成されることをお勧めします。 Snapshotがない場合は、Upgradeトラブル時に切り戻しできる可能性が減ります。     7.0.010へのUpgradeに関する既知問題（2020/09/12 Update） ・VCSAとPSCのroot passwordをそれぞれで違うものを使用していた場合、Upgrade前に同じパスワードに設定する必要があります 詳細に関しては、KB#545932​ をご参照ください ・vCenter portgroup nameをVxRail Deploy時から変更していた場合、VxRail 7.X台へのUpgrade時のネットワーク設定に失敗する場合がございますので、Upgrade前にVxRail Manager内のData Baseと同じvCenter portgroup nameに設定する必要があります 詳細に関しては、KB#545867 をご参照ください ・VxRail manager VMの仮想マシン名が「VxRail manager」から変更していた場合、7.0.010用のVxRail ManagerのDeployに失敗するため、Upgrade前に仮想マシン名を「VxRail manager」にする必要があります 詳細に関しては、KB#545620 をご参照ください   ESXi の詳細設定パラメータについて 既存の不具合と関連する詳細設定パラメータの設定がある場合は事前にVxVerifyで確認されます。 参考 https://www.dell.com/support/kbdoc/en-us/000201608 https://www.dell.com/support/kbdoc/en-us/000043154   ESXi 内部管理ユーザのパスワード形式について Dell EMCにUpgradeを依頼した場合、Upgrade前の事前チェックにて、環境確認用のスクリプトを実行します。 その際に、ESXi の内部管理ユーザのパスワード形式が古い場合にスクリプトが正しく実行できない場合があります。 VxRail 4.0.300 未満のVersionでVxRail を初期構築した場合は、事前チェック時にパスワードを新形式に更新していただく場合があります。   vDSアップグレードに伴うデフォルト設定の変更についての注意事項 vDS が 6.6 から 7.0になりますが、その際に マルチキャストフィルタリング の設定が強制的に IGMP/MLD スヌーピング に代わるため以下のvmware kb の事象が発生する可能性があります。 IGMP/MLD snooping when enabled makes Virtual IP in Microsoft NLB (Network Load Balancer) not reachable (75217) https://kb.vmware.com/s/article/75217 Upgrade中の留意点 Upgradeファイルのダウンロードに関する留意点 Upgradeファイル（Composite Upgrade Package）のダウンロード方法がこれまでと異なります。 これまでのVxRailのUpgrade用ファイルはすべてサポートサイトからダウンロード可能でした。 しかし、VxRail 7へのUpgradeについては、重要な制限・注意事項がいくつかあるため、不慮のUpgradeを予防する意味で直接のダウンロードはできなくなっています。 代わりに下図のようにREADMEファイルが公開されており、その中でSolveOnlineの手順書を確認したうえで、同書内に記載のURLからダウンロードが可能な旨が示唆されています。 したがって、まずはSolveOnlineから手順書を生成し、内容を確認する必要があります。     VxRail Manager VMのDiskサイズを手動で拡張する必要がある。 VxRailのUpgradeでは、UpgradeファイルがGUIを通じてVxRail VMにUploadされる仕組みになっております。 VxRail7のUpgradeファイルはサイズが大きいため、VxRailのVersionに依存し、手動でのDisk拡張作業が必要となります。 対象となるのは、VxRail Versionが4.5.401未満(4.5.401は含まない)、4.7.301未満および4.7.400です。（下表参照） 手順に関してはSolve Procedureをご参照ください。   既存のVxRail Version 拡張の要否 4.5.400 もしくはそれ以前の4.5系 必要 4.5.401 もしくはそれ以降の4.5系 不要 4.7.300 もしくはそれ以前の4.7系 必要 4.7.301 不要 4.7.400 必要 4.7.401 もしくはそれ以降の4.7系 不要 表2 Disk拡張作業要否   外部VC と外部PSCをご利用の場合の追加作業 VxRailの外部VC構成では、PSC統合型とPSC外部型の二つのパターンがあります。 それぞれの構成の違いについて不明な場合はこちらをご覧ください。 外部VC環境と外部PSCを利用している環境の場合、vSphere 7にUpgradeすることで、外部VCと外部PSCが統合されます。 そのため、VxRail側で管理されるPSCのIP/FQDNをVCSAに統合する処理が必要となります。 ※初めから統合型（Embedded PSC）の外部VCを利用している場合は対応不要です。 VxRail側のPSC IP/FQDNの更新作業は外部VC/PSCのUpgrade後、かつVxRail ClusterのUpgrade前に実施しておく必要があります。 つまり、 １．外部VCのUpgrade（お客様） ２．統合作業の実施（お客様） ３．VxRailのUpgrade（お客様 or Dell EMC） の順で実施が必要です。 統合作業の実施手順については、Dell EMC KB：543028にScriptがございますので、こちらの手順に従い実施いただく必要があります。   Dell EMC VxRail: Need to update VxRail Manager configuration after converging external vCenter and PSC using script https://support.emc.com/kb/543028     互換性のないFWによるエラーについて VxRail 4.7.300以降の新機能として、Upgrade時のFirmware互換性チェックが導入されました。 Upgradeを開始してファイルのUploadが完了した後で互換性チェックが実行されます。 過去の障害やお客様の作業によって、VxRailと互換性のないFirmwareが利用されていた場合は、Upgradeに進むことができません。 この状態になりましたら、Dell EMCサポートにご連絡ください。     Upgrade中の監視・進捗確認 Upgrade中はVxRailがHealth MonitoringがOffになりますが、vCenterのアラーム通知機能は動作します。したがってDell EMCへの自動通知機能は無効になりますが、ユーザへのアラーム通知機能は引き続き利用可能です。 Upgradeの進捗はVxRail GUIから確認可能ですが、REST APIからUpgradeを開始した場合、GUIからは進捗を確認できません。 NodeのUpgrade実施中にBIOS画面で停止してしまうことがまれにあります。その場合、VxRail ManagerはUpgrade失敗を検知できず最大2時間ほどそのままとなります。 NodeのUpgrade中はiDRACやBMCの仮想コンソールから進捗を確認しておくことが推奨です。   Upgrade進捗が文字化けする問題 VxRail 4.7.410 もしくは4.7.411からVxRail 7.0.000にUpgradeする際に、GUI上のUpgrade進捗が文字化けする既知の不具合があります。 表示上のみの問題でありUpgradeには影響がありません。 英語表示の場合は文字化けが発生しませんので、英語表示で確認されることを推奨します。     日本語名のVMがある場合にUpgradeが失敗する VxRailはすべてのNodeが自動で順々にUpgradeされていきます。（ローリングUpgrade） Upgrade中のNode（ESXi）に日本語名の仮想マシンがある場合にUpgradeが途中で失敗となります。 その際に下記のようなエラーメッセージを出力します。   Failure occurred while running an upgrade for bundle: ESXi. The error message: 'ascii' codec can't decode byte XXXX in position XXXX ordinal not in range(xxx).   この事象についてはDell EMC KB#529443 に記載されています。（パートナー権限が必要） この事象が発生した場合は、対象の仮想マシンをUpgrade済みのESXiに手動でvMotionしていただき、VxRail GUI(VxRail 4.5.x)もしくはvCenter Plugin (VxRail 4.7.x) からUpgradeを再試行（Retry）していただければUpgradeを再開できます。   Upgrade中のClomdRepairDelayの変更について VxRail 4.7.100未満から7.x 以降にUpgradeする際の注意事項です。 vSAN 6.7U1から、Object Repair Timerの値をvCenterから一元管理できるようになりました。 その関係で、ESXiをUpgradeした際にObject Repair Timer（ClomeRepairDelay）の値を変更していた場合、デフォルト値に強制的に戻されます。 しかし、vCenterをUpgradeした直後にvSphere Client (HTML5)から対象の項目を変更しておけば回避可能です。 つまり、VxRailのUpgradeの順序として、 VxRail Manager PSC VCSA ESXi (Firmware含む) の順番でUpgradeされますが、3のVCSA Upgradeが完了した後にvSphere Client （HTML5）からObject Repair Timerを変更しておけばデフォルト値に戻ることを回避できます。 Object Repair Timerの変更方法はこちらの記事をご参照ください。 https://cormachogan.com/2018/11/13/new-vsan-6-7u1-advanced-options/ なお、VxRailのUpgradeをDell EMCに依頼した場合でも上記の対処は実施してくれないため、Resyncが走ってしまうことがありますので、ご注意ください。   Upgrade失敗時の切り戻しについて VxRailはダウングレードをサポートしておりません。 しかし、ESXiがUpgradeされる前であれば、System VMを事前に採取したSnapshotに切り戻すことで正常状態に戻すことが可能な場合があります。 VxRail 4.7.x → 7.xのUpgradeの切り戻し作業において、スナップショットを取得したタイミングによっては、VCSAのサービスが起動しない場合があります。 詳細と対処法については以下のDell EMC KBをご参照ください。 Dell EMC VxRail: How to rollback to 6.x internal vCenter when upgrading VxRail from 4.x to VxRail 7.x failed and cannot retry. https://support.emc.com/kb/542406   vCener と PSC のアフィニティルールについての注意事項 VxRail アップグレードでは vCenter サーバやPSCのアップグレードがされる関係で、一時的に両VMに対してアフィニティルールが適用され、特定のESXi に固定されます。もし既存で既にお客様が設定したVCSA/PSCに対するアフィニティルールがある場合は競合によって設定が失敗することがあります。     Upgrade後の留意点 vSphere Clientの表示がおかしい VxRail 7へのUpgrade後に、vSphere Clientにて各インベントリの詳細情報が表示されない場合があります。 詳細と対処については以下のKBをご参照ください。 Dell EMC VxRail: vCenter GUI being abnormal after upgrading to 7.0.000 https://support.emc.com/kb/543019       「vSAN ビルドに関する推奨事項エンジンの健全性」について VCSAがインターネット経由でVMware社にアクセスできないことに起因して、上記のエラーが出ることがあります。 Proxyサーバを設定することでも対処可能ですが、VCSAのインターネットへのアクセスを希望しない場合はこの警告を静観していただくか、もしくはこの項目自体を無効にする必要があります。 この項目のチェックを無効にする手順は下記のコミュニティ投稿をご参考にしてください VxRail:vSAN健全性テストの警告抑止方法手順   古いVCSAおよびPSC VMの削除について Upgrade前に使用していた古いVCSAが「VMware vCenter Server Appliance（legacy）」としてインベントリに残ります。 Upgradeが失敗した場合はロールバックとして使用する可能性があるものですが、完了後は基本的に不要です。 お客様のご判断にても不要であれば、Upgrade完了後に削除をお願いいたします。 PSC VMについても同様です。     Intel CPU脆弱性の対応について VxRail 4.5.152以降にはIntel CPUのセキュリティ脆弱性についての修正が含まれております。 VMwareの環境では、Upgradeしただけでは修正が個々の仮想マシンに適用されません。 修正が必要な仮想マシンにたいして以下の対処を実施お願いいたします。   ### 補足 ### ※セキュリティ対策が不要な場合は実施不要です。 ※下記の説明文中SystemVMとは以下のVxRail によって自動デプロイされた以下のVMのことです。 VxRail Manager VCSA（外部VC構成の場合は無） PSC（外部VC構成の場合は無） LogInsight （オプション） ##########     ― すべてのお客様仮想マシンに対して以下の対処を実施ください  ※System VMを除く 1. GuestOSレベルでの修正を適用ください。修正についてはOSベンダにお問い合わせください 2. 仮想マシンハードウェアをVersion 9以上にしてください。      ※すでにVersion 9 以上のものに関しては対応不要です。 3. 対象のVMをShutdownし、完全にPower Off状態となったのち、PowerONしてください。※RebootではなくPowerCycleが必要です。     ― System VMに対して以下の作業を実施ください 1. 上記「すべてのお客様仮想マシンに対して」のStep2とStep3のみ（PowerCycle）を実行ください。Step1の実施は不要です。 ※以下の順序で実施してください ① VxRail Manager ② vRealize Log Insight [if deployed] ③ vCenter Server Platform Service Controller (PSC) [if Internal] ④ vCenter Server Appliance (VCSA) [if Internal]   ※PSC/VCSAをPower Offすると認証およびWebClientへのアクセスができなくなります。WebClientへのアクセスが失われた場合、これらのVMのPowerOn作業は各ESXiのHostClientにて実施する必要があります。そのため、PSC/VCSAについてはあらかじめどのNodeにて稼働しているのかをご確認いただくことをお勧めします。       ESRSVEのUpdateについて ESRSVE VMについてIntel CPUのセキュリティ脆弱性についての対処をご希望の場合は以下を実施する必要があります。 1. ESRSVE VMのSnapshotを取得 2. ESRSVEを最新VersionへのUpdate （※手順は添付。Downloadはお客様のネットワーク環境に依存して2時間以上かかることがあります） 3. ESRSVE VMの仮想ハードウェアVersionを最新にする 4. Dell EMCへ接続性チェックを依頼。※このメールスレッドにてご依頼ください 5. 正常性を確認後、Snapshotを削除。※VSANデータストア上にVMについては必ずしも削除は必要ではありません   ※上記はすべて以下のコミュニティ文書にて詳しく解説されていますのでご参照ください。      VxRail: ESRSVE VMのUpdate 手順（参考資料）   仮想分散スイッチのUpgrade VxRailのVersionが4.x -> 7.xになることでvSphereのVersionが6.x -> 7.xになるため、VxRailが管理している最初の仮想分散スイッチについても自動的にVDS version 7.xにUpgradeされますが、お客様にて作成された分散スイッチは対象外となります。必要に応じて手動で分散スイッチのUpgradeを実施してください。   ・仮想分散スイッチのUpgrade方法 Upgrade a vSphere Distributed Switch to a Later Version     Password有効期限の変更など、デフォルト値からの変更について 既存のVCSA/PSCに対してPasswordの有効期限の変更などを実施していた場合はUpgradeによって設定がデフォルトに戻ります。これはUpgradeの過程で新しいVCSA/PSC VMの作成→移行というプロセスを経ているためです。 ほとんどの場合はPassword有効期限に対する変更のみと思いますが、実施していた場合は再設定が必要になります。   CVE-2018-3646に関するアラートの対応 Upgrade後、もしくはUpgrade中にWebClient GUI上に、CVE-2018-3646に関するアラートが表示される場合があります。 こちらもIntel CPUの脆弱性に関するものであり、下記のコミュニティ文書を参考に対応方針（修正の適用 or 静観）を蹴っていただき、必要であれば対応を実施していただく形になります。   VxRail: 「このホストにはCVE-2018-3646で記述されている問題に対する脆弱性があります。 詳細およびVMwareの推奨については、https://kb.vmware.com/s/article/55636を参照してください」の警告、及びL1TF/Foreshadow問題への対応   SystemVMのバックアップ取得 Upgradeにより、過去に取得したSystem VM （VCSA/PSC/VxRail Manager）のバックアップとの互換性がなくなります。 Upgrade後は必ずSystem VMのバックアップを取得してください。 バックアップについては以下の方法を利用可能です。 (推奨)仮想マシンImage level バックアップ（vSphere Data Protection、Dell EMC  Avamar、もしくは3rd party ソリューションが必要） Clone OVFテンプレートのExport (推奨)Snapshot (※論理破損のみに対応。物理破損についてはリストア不可) ※論理破損・・・・filesystem corrupt など。vSphere HAによってVCSA/PSCが再起動された際などファイルシステムが破損することがあります。 ※物理破損・・・・ Disk障害やvSAN データオブジェクト喪失など (推奨)File-base backup 2019年7月末より、VCSA/PSCのファイルベースバックアップがサポートされました！ （参考）https://support.emc.com/docu95114_File-Based-Backup-and-Restore-of-VxRail-VCSA-and-PSC.pdf?language=en_US ※2019年9月8日現在でVxRail 4.7.x系での上記ファイルベースバックアップは未サポートですが将来的にサポートされる可能性がありますので取得しておいて損はありません VxRail Manager VMについてもファイルベースバックアップが可能です。詳細はSolveOnline（もしくはSolveDesktop）から手順をご参照ください。 https://solveonline.emc.com/solve/home/ ※SolveOnlineを使用するには事前にDell EMCサポートアカウントが必要です。 ※サポートアカウントをお持ちでない方は事前にご登録ください。登録方法が不明な方はDell EMCアカウント担当者にご連絡ください。 DELL EMC オンライン・サポートのアカウント作成 手順書までのパス 上部検索バーで"vxrail" を検索 検索結果の”VxRail Appliance” を選択 'How To' Procedures Is the system running Virtual Cloud Foundation on VxRail?   >>> No 'How To' Perform VxRail Manager File-Based Backup and Restore  Select the Installed VxRail Software Version  >>> Upgrade後のVxRailのVersionを選択 Usage information 　>>>> Serian Numberなどは記入不要でNextを押下 Generate ボタンから手順書を生成ダウンロード   Active Directoryへの再Join VCSA/PSCの再デプロイによるUpgradeとなりますのでActive DirectoryへJoinしていた場合は、Upgrade後に再Joinが必要になります。詳細については以下のドキュメントをご参照ください。 JOINING VXRAIL SUPPLIED VCSA AND PSC TO ACTIVE DIRECTORY ※Impact of VxRail Upgrades　の項目をご参照ください 再Join手順はKB#540807をご参考にしてください。 https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-vcenter-server-70-release-notes.html After upgrading or migrating a vCenter Server with an external Platform Services Controller, if the newly upgraded vCenter Server is not joined to an Active Directory domain, users authenticating using Active Directory will lose access to the vCenter Server instance. Workaround: Verify that the new vCenter Server instance has been joined to an Active Directory domain. See Knowledge Base article: https://kb.vmware.com/s/article/2118543   アップグレード後のESXi 構成情報の暗号化について ESXi 7.0U2 以降ではデフォルトでホストの構成情報が暗号化されます。アップグレード時には自動的に実施されます。 TPM2.0がない場合は難読化されるのみですが、TPM2.0が有効なホストでは暗号化され、TPM2.0障害やシステムボード障害時にリカバリキーを入力しないとホストが起動できなくなります。 該当環境においては、アップグレード後に必ずリカバリキーをバックアップしてください。 暗号化されたくない場合はTPM2.0をOffにしてください。 参考： ホスト構成情報の暗号化関連 セキュアな ESXi 構成の概要 (vmware.com) ESXi の構成情報の暗号化、TPM による追加の保護、TPM 障害からの復旧 | vSoliloquy (jangari-ntk.github.io) リカバリキーのバックアップ関連 セキュアな ESXi 構成リカバリ キーの内容の一覧表示 (vmware.com) https://kb.vmware.com/s/article/81661 TPM2.0有無の確認方法関連 「Dell EMC VxRail：ホストがvCenterに次のアラートを表示します。TPM 2.0デバイスが検出されたが、接続を確立できない(お客様による修正が可能) | Dell 日本 https://itorwar.blogspot.com/2022/12/vspheretpm.html   vSAN オブジェクトフォーマットの更新が必要となる場合がある vSAN 7.0U1 以降で vSAN のオブジェクトフォーマットの変換が必要となる場合があります。 VxRail のアップグレードでは実施されないため、必要な場合は事後に手動で実施する必要があります。 参考： https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-D0A298A4-8A90-47C0-91C9-103F97B8E930.html https://kb.vmware.com/s/article/80614?lang=ja   vCLSの採用 vSphere 7U1より、DRSの機能がvCenterからではなくvCLS VMにて提供されます。 DRSの機能を利用する場合は、vCLS VMが動作している必要があります。 vCLS VMは管理VMとして運用手順に影響する場合がありますので、詳細は下記のKBをご参照ください。https://kb.vmware.com/s/article/80472?lang=en_us  

vSphere HAが有効なクラスタ環境の場合、ESXiホストにHAに関する警告が表示される場合があります。 このような場合、発生した警告からVMwareナレッジを検索し、対処を行うことになります。 ただ、ESXiを右クリック「vSphere HA用に再構成」では解消されない場合があり、 そのような場合についてはクラスタ全体としてvSphere HAを再構成する方法が有効です。 以下にその方法を画像付きで紹介したいと思います。 vSphere Web Client vCenter Web Clientにログインします。 インベントリを「ホストおよびクラスタ」に切り替えます。 クラスタを選択し「管理」タブ「設定」からvSphere HAの「編集」ボタンを表示します。 編集をクリックすることでクラスタの「設定の編集」ウィザードが表示されます。 「Turn on vSphere HA」のチェックを外し、ウィザード下部の「OK」ボタンをクリックします。 クラスタの再設定タスクが完了するまで待機します。 再度クラスタの「設定の編集」画面から「Turn on vSphere HA」をチェックし、「OK」をクリックします。 vSphere HAの再設定タスクが実行されるので完了まで待機します。 上記がWeb ClientでのvSphere HAの再構成の手順となります。 vSphere Client(HTML5 Client) vCenter のHTML 5 Clientにログインします。 インベントリを「ホストおよびクラスタ」に切り替えます。 クラスタを選択し「設定」からvSphere HAの「編集」ボタンを表示します。 「編集」ボタンをクリックすることでクラスタの「設定の編集」ウィザードを表示します。 「vSphere HA」スライドクリックし（緑からグレー）、「OK」をクリックします。 クラスタの再設定タスクが完了するまで待機します。 再度クラスタの「設定の編集」画面から「vSphere HA」スライドをクリックし（グレーから緑）、「OK」をクリックします。 クラスタの再設定タスクが完了するまで待機します。 上記がvSphere Client(HTML5 Client)でのHA再構成の手順となります。 HAに関する警告が解消されるかご確認ください。

この文書では、vSphere環境(ESXi, vCenterなど)からLog InsightへSyslog転送したログのうち、 任意の条件で絞り込みを行い別のsyslogサーバへsyslog転送する方法について紹介します。 ※VersionによってGUIの画面に違いがある可能性がございます。 Log Insightにsyslogを転送するための設定手順は、以下のVMware Documentをご参照下さい。 vRealize Log Insightにログ イベントを転送するための ESXi ホストの構成 　1. https://<Log Insight IP or Log Insight hostname> にWebブラウザでアクセスし、admin userにてLoginを実施します。 　2. adminユーザーでのログイン後、画面右上の構成ドロップダウンメニューアイコンをクリックし、[Administration]を選択します。 　3. [Management]の中から、[Event Forwarding]を選択します。 　4. [+NEW DESTINATION]を選択し、下記の項目を入力します。 Name 新しく作成する転送先の任意の名前 Host syslogサーバのIP AddressもしくはFQDN Protocol Syslog Transport TCPもしくはUDP（syslogサーバ側の設定により選択してください） 　5. [+ADD FILTER]を選択し、抽出したいログの具体的な内容を入力します。 ここでは、例としてユーザのログインに関するイベントのみを抽出しています。 抽出するイベント内容については、ワイルドカード * を使用することができます。 　6. [Run in Intaractive Analystics]をクリックすると、実際に入力した抽出条件に合致するイベントをInteractive Analysisで確認することができます。 これによって、抽出条件として記載した内容が適切かどうかが確認できます。 　7. [TEST]をクリックし、Syslogサーバとの通信が問題ないことが確認できたら、[SAVE]を押します。 　8. 作成したsyslog転送設定のStatusがActiveになったら設定成功となります。 詳細な設定値等については、以下のVMware Documentをご参照下さい。 vRealize Log Insight イベント転送ターゲットの追加

本記事では、VxRailやお客様環境においてvSAN健全性テストにて無視が可能なアラートや項目に抑止（Skip）設定をする方法を記載します ※画像はクリックすることで拡大可能です ■概要 VxRail 4.5（vSAN6.6、vSphere 6.5）から、vSAN健全性テストの項目が増えインターネット接続を要求する機能に関するテストも追加されました vSANビルドに関する推奨事項エンジンの健全性は非インターネット接続環境では必ず警告になるので無視しても問題ありません なお、vSAN6.6からの新機能でvSAN健全性テストの項目を個別にスキップ(Silence)することができるようになりました 警告が表示されること自体を望まない場合は、該当の項目をスキップしてください また、VxRailでは下記に関連する項目も無視することが可能です ・Hardware compatibilityに関連する項目(HCLDB, VMware certified等)：HardwareやFirmwareなどがVxRail Version毎に管理されているため ・VUMに関連する項目：VxRail ManagerからUpgradeを管理しているため ・vSAN Build Recommendation（vSANビルドに関する推奨事項）に関連する項目      ‐ vSANビルドに関する推奨事項エンジンの健全性(vSAN Build Recommendation Engine Health)：非インターネット接続環境では必ず警告になるため      ‐ vSAN build recommendation：Upgradeのリリース等はVxRail側で管理しているため      ‐ vSAN release catalog up-to-date：Upgradeのリリース等はVxRail側で管理しているため ・vSAN Support Insight：VxRailおよびDELL EMC側では使用していないため ■vSAN健全性テスト項目の抑止方法 vSAN Build Recommendation Engine Health(vSAN ビルドに関する推奨事項エンジンの健全性)のテスト項目を例に記載します ・VxRail4.7(vSAN6.7, vSphere6.7)の場合 VxRail4.7ではGUI上から設定することが可能です 1. vSAN健全性テストの項目に移動し、抑止したいテスト項目のvSAN健全性テストのグループを選択 2. 抑止したいテスト項目をクリックし、テスト項目の詳細が表示されたことを確認し「Silence Alert」をクリック 　※選択されたアラートが抑止したいテスト項目であることを確認して実施してください 3. 警告がでるので「YES」を選択 4. vSAN健全性テストの「RETEST」を実施 5. テスト項目が抑止されたことを確認 　抑止されると、チェック部分がグレーのマークに変わり、「Restore Alert」というメニューが表示されるようになります ・VxRail4.5(vSAN6.6, vSphere6.5)の場合 VxRail4.5ではRVCを使用することで設定可能です 1. vCenterにSSHでrootログイン 　SSH有効化手順は下記のコミュニティを参考にしてください 　https://communities.vmware.com/docs/DOC-39994 2. Bashシェルでは無い場合、Bashシェルに遷移 Command> shell.set --enabled True Command> shell Shell access is granted to root root@vc [ ~ ]# 3. RVCにログイン root@vc [ ~ ]# rvc administrator@vsphere.local@localhost　< vCenter SSO ユーザー名@localhostを入力 Install the "ffi" gem for better tab completion. password:                                      < vCenter SSO パスワードを入力 0 / 1 localhost/ > 4. ls、cdコマンドでvSANクラスターリソースのパスを特定 5. 下記のコマンドで現在の健全性テストのSilent Statusを確認、及びスキップする対象のHelth Check IDを特定 　vsan.health.silent_health_check_statusのコマンドで確認します vsan.health.silent_health_check_status /localhost/データセンター名/computers/vSANクラスターリソース "Silent Status"の状態がNormalとなっている場合は、通常通りvSAN健全性テストの対象となっている状態です カレントディレクトリが既に"/localhost/データセンター名/computers/vSANクラスターリソース"まで到達している場合は、 下記のようにコマンドの引数を省略もできます vsan.health.silent_health_check_status 0 ~~ 中略 ~~ 6. 対象の項目のHelth Check IDを指定してSilent状態へ変更 　※vSAN ビルドに関する推奨事項エンジンの健全性の場合は、vumconfigを指定してください 　vsan.health.silent_health_check_configure -a のコマンドで変更可能です vsan.health.silent_health_check_configure -a [Health Check Id] /localhost/データセンター名/computers/vSANクラスターリソース 実行例 /localhost/VxRail-Datacenter/computers> vsan.health.silent_health_check_configure -a vumconfig 0 Successfully update silent health check list for VxRail-Virtual-SAN-Cluster-5805c8ee-xxxx-xxxx-xxxx-xxxxxxxxxxxx /localhost/VxRail-Datacenter/computers> 7. Step 5（vsan.health.silent_health_check_status）を実施してSilentに変わったことを確認 ■vSAN健全性テスト項目の抑止解除方法 ・VxRail4.7(vSAN6.7, vSphere6.7)の場合 1. 抑止されているテスト項目を選択し、「Restore Alert」をクリック 「Restore Alert」の項目が、「Silence Alert」に変わったことを確認しvSAN健全性テストを実施 ・VxRail4.5(vSAN6.6, vSphere6.5)の場合 1. Silentにしたテスト項目をNormalに戻したい場合は抑止方法と同じ要領でRVCを使用し、設定します vsan.health.silent_health_check_configure -r のコマンドで設定可能です vsan.health.silent_health_check_configure -r [Health Check Id] /localhost/データセンター名/computers/vSANクラスターリソース名 実行例 /localhost/VxRail-Datacenter/computers> vsan.health.silent_health_check_configure -r vumconfig 0 Successfully update silent health check list for VxRail-Virtual-SAN-Cluster-5805c8ee-d3cd-4af5-9988-bcbe0d7715e9 /localhost/VxRail-Datacenter/computers> ■vCenterのアラーム定義を無効化 RVCの使用が難しい場合は、vCenterのアラーム定義を無効にすることで、自動で発生するアラームを抑制することができます 尚、この方法を取った場合はvSAN健全性テスト上の警告は引き続き発生し続けます ※vSAN健全性テスト項目の抑止を実施している場合は対応不要です ・VxRail4.7(vSAN6.7, vSphere6.7)の場合 1. vSphere Client にLoginし、"Host and Clusters"を選択 2. 左側の最上部に位置するvCenterを選択し、Configure > More > Alarm Definitions を選びアラート一覧から抑止したいアラームを選択 3. 選択された状態で、「DISABLE」をクリック 　選択されたアラームの無効化が出来ます（Enableの項目がDisableになります） ・VxRail4.5(vSAN6.6, vSphere6.5)の場合 1. vSphere Web Client にLoginし、"Host and Clusters"を選択 2. 左側の最上部に位置するvCenterを選択しMonitor > Issues > Alarm Definitions を選びアラート一覧から抑止したいアラームを選択 　右側にあるEditを押す 3. 「Enable this alarm」のチェックを外すことで、アラームの無効化が出来ます ■参考情報 ・VxRail: How to silence vSAN Health Checks in VxRail 4.5(User Correctable) https://support.emc.com/kb/519562 ・Silencing a vSAN health check (2151813) https://kb.vmware.com/s/article/2151813 ・How to silence VMware vSAN Health Checks https://www.virten.net/2017/04/how-to-silence-vsan-health-checks/ ・vSAN Health Service - vSphere Update Manager - vSAN build recommendation engine health (2150914) https://kb.vmware.com/s/article/2150914 ・VxRail: vSAN Health Service - vSphere Update Manager - vSAN build recommendation engine health https://support.emc.com/kb/522941

本記事では、Dell EMCよりVMware License key購入された際にVxRailに適用する方法を記載いたします。 LicenseはVMware License(vSAN, ESXi)が対象となります。 ■Licenseの適用の流れ 1. ライセンス情報に関して 2. DELL Digital Lockerに関して 3. パートナーアクティベーションポータルに関して 4. vSphere ライセンスキーの割り当てに関して ■注意点   ■Licenseの適用の流れ DELL EMCよりVMwareのLicenseをご購入の際には、 DELL EMCのサイトよりPAC（パートナー アクティベーション コード）というものが提供され、 そのPACをVMware社のパートナーアクティベーションポータルにてアクティベーションの実施をすることで、実際に使用するvSpere License keyを取得することができます。 ※OEMライセンスといった形式となります   具体的には下記のような流れとなります ライセンスに関する情報（registration codeなど）をメールにて受領 DELL Digital Lockerにて ”registration code”を使用して、PAC（パートナー アクティベーション コード）を取得 パートナーアクティベーションポータルにて PAC（パートナー アクティベーション コード）をアクティベーションし、vSphere ライセンスキーを取得 取得したvSphere ライセンスキーをvSphere Web Client (又はWeb Client)よりライセンスの割り当てを実施   これらの作業に関しては、それぞれのサイトにてお客様のアカウントとの連携が必要となり、基本的にはお客様にて実施いただいている作業となります。 ※提供されたLicenseのVersionと種類及び適用するVxRailのVersionを必ずご確認ください   1. ライセンス情報に関して a. 発注処理などが完了すると、下記のようなDELL Digital Lockerのご案内のメールがお客様宛に届きます ※メールフォーマットが多少異なる場合がございます b. メール内の記載手順を参考いただき、Dell Digital Lockerへログインおよび登録等を実施します 　※購入方法などによって、registration codeといったLicenseの登録コードが記載されている場合もございます   ライセンスに関するメールが届かない場合は、Dell EMCの営業担当、又は導入パートナー様へご確認ください   2. DELL Digital Lockerに関して Dell EMCのサイトより、PAC（パートナー アクティベーション コード）を取得します a.下記のサイトより、DELL Digital Lockerへメールアドレス および パスワード を入力してLoginを実施します      http://www.dell.com/support/software   　※お客様が Dell My Account（Dell マイアカウント）をお持ちでない場合は、まずアカウントの作成が必要です 　※サインイン後、Dell Software License Agreement が出てくる場合は、「はい、同意します」を選択してください   b. 左側のナビゲーションから「製品（Digital Products 又は Products）」を選択 ※購入したLicenseが一覧にない場合には、「製品登録（Product Registration）」よりメールに記載のあるregistration code（登録コード）を入力して登録します ※製品登録にて所有者の登録を実施した場合には、弊社側のシステム登録の反映にお時間がかかる場合がございます 　その際には、時間を置いて再度確認をお願いします   c. PAC（パートナー アクティベーション コード）を取得するLicenseを選択 PAC（パートナー アクティベーション コード）を取得するLicenseを選択し 「キーの取得（Get key）」を選択して、表示される手順に従って進めることでPAC（パートナー アクティベーション コード）を取得できます   ※PACの生成後、60日以内にVMwareのパートナーアクティベーションポータルからActivateする必要がありますのでご注意ください。 　 DELL Digital Lockerやアカウントに関しては、下記のページを参考にしてください ■DELL Digital Locker よくあるお問い合わせ（FAQ） https://www.dell.com/support/software/jp/ja/jpbsd1/default/quickstartguide ■デルの「マイ アカウント」に関するよくあるお問い合わせ（FAQ） デルの「マイ アカウント」に関するよくあるお問い合わせ（FAQ） | Dell 日本 ■Dell Digital Lockerにアクセスする方法 Dell Digital Lockerにアクセスする方法 | Dell 日本   3. パートナーアクティベーションポータルに関して PAC（パートナー アクティベーション コード）から、製品に割り当てができるvSphere ライセンスキーを取得します   a. 下記のサイトより、MyVMwareのユーザー 及び パスワード を入力してLoginを実施します 　DELL Digital Lockerにてパートナーアクティベーションポータルが表示されますので、下記のURLと違う可能性もございます https://www.vmware.com/oem/code.do?Name=DELL-AC または https://www.vmware.com/oem/code.do?Name=DELLVXRAIL-AC   ※お客様が MyVMwareのアカウントをお持ちでない場合は、まずアカウントの作成が必要です   b. PACのアクティベーション ［パートナー アクティベーション コードのVMware登録］ページの［アクティベーション コード］ボックスに2. で取得したPACを入力します Menuを進めることで、vSphere ライセンスキーを取得できます   c. vSphere ライセンスキーの確認 VxRailに適用するvSphere ライセンスキーが全て取得できているか確認してください ※PACからライセンスキーへの変換には、約30分-24時間ほど要します。   　変換後、ライセンスキーの結合/分割/移動・ダウングレード/アップグレードなどの操作を行っていただけるまでに、最大24時間ほど要する場合があります。 　変換後、時間をおいて作業を行ってください。   d. ライセンスの結合、分割（必要な場合は対応） vSAN 用のLicenseなどがNode毎にライセンスキーが発行されている場合、統合処理（combine）が必要となります 下記VMware KBの結合手順にて実施をお願いします ※ESXiのライセンスにも必要な場合もございます How to Divide or Combine License Keys in Customer Connect with troubleshooting steps (81616) https://kb.vmware.com/s/article/81616 How to combine license keys:   また、余分に結合処理を実施してしまった場合は、下記のVMware KBの手順にて分割も可能です How to Divide or Combine License Keys in Customer Connect with troubleshooting steps (81616) https://kb.vmware.com/s/article/81616 How to Divide License Keys:   ※結合（または分割）したいライセンスがMyVMwareに登録されていない場合は、下記のVMware KBをご参考に登録の実施をしてください My VMware でライセンス キーを登録する (2011177) https://kb.vmware.com/s/article/2011177?lang=ja 　 ※提供されたLicenseのVersion及び適用するVxRailのVersionを必ずご確認ください 　vSphere 7 / vSAN 7 の Licenseは VxRail 7.X へしか適用できません 　適用するLicenseがvSphere 7で、VxRailのVersionが4.5, 4.7 の場合にはLicenseのダウングレードが必要となります 　How to Upgrade or Downgrade License Keys in Customer Connect with troubleshooting steps (81665) 　https://kb.vmware.com/s/article/81665   MyVMware(現名称：Customer Connect )での操作等に関しては、下記のページを参考にしてください。 Customer Connect に関する FAQ (2014350) https://kb.vmware.com/s/article/2014350?lang=ja   必要に応じて、My VMwareポータルサポートお問い合わせへご相談ください。 My VMwareポータルサポートお問い合わせ窓口 https://www.vmware.com/jp/contact_license.html​   【アカウント関連】 ■How to create a Customer Connect profile (2007005) https://kb.vmware.com/s/article/2007005 https://kb.vmware.com/s/article/2007005?lang=ja　（日本語版）   ■デジタルダウンロードストアを使用して VMware OEM 製品ライセンスを登録およびアクティブ化する方法 デジタルダウンロードストアを使用して VMware OEM 製品ライセンスを登録およびアクティブ化する方法。 | Dell US   【操作関連】 ■My VMware 操作ガイド(こちらのPDFが分かりやすい資料です) https://www.vmware.com/content/dam/digitalmarketing/vmware/ja/pdf/support/VMware_License_Support_Manual.pdf P48.  [OEM製品購入時] PACからライセンスキーへの変換   ■OEM (Original Equipment Manufacturer) パートナー アクティベーション コード (PAC) ポータル (2011587) https://kb.vmware.com/s/article/2011587?lang=ja ■How to register a VMware Partner Activation Code (PAC) How to register a VMware Partner Activation Code (PAC) - YouTube   4. vSphere ライセンスキーの割り当てに関して 取得したライセンスキーの製品への割り当てを実施します 【ライセンスの追加】 a. vSphere web Client（又はWeb Client）へadministrator権限でLoginします   b. 画面上部のMenuから"Administration"を選択し、Licenses のMenuを選択   c. Licensesにある"＋Add New Licenses" を選択し、3.で取得したvSphere ライセンスキーを入力しNEXT   d. Edit License names にて、Product欄に取得したLicenseの詳細が正しいか確認し、License Nameに任意の名前を入力しNEXT 　次のMenuでFinishを選択し、Licensesの画面にて追加したLicense情報が表示されているか確認   ※この時点では、vSAN ClusterやESXiへLicenseの適用は完了していませんのでご注意ください   【ライセンスの適用】 a. Assets にあるListからライセンスの適用を実施する対象を選択し、Assign Licenseを選択 VCENTER SERVER SYSTEMS：VCSAのライセンス HOSTS：ESXi関連のライセンス CLUSTERS：vSANのライセンス   下記の例の場合、VxRail-Virtual-SAN-ClusterというClusterにvSANライセンス（License 9）を適用していきます   b. Assign LicenseのMenuにて、EXISTING LICENSESにて新しく追加したLicenseを選択   c. 適用したLicenseの情報を確認（Liceseの種類、Expiration等）   【参考情報】 ■新規ライセンスを作成 https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vcenterhost.doc/GUID-41AAD7D2-2A25-458B-B2CF-7D08042A1803.html   【ライセンス概要等】 ■ESXi ホストのライセンス https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vcenterhost.doc/GUID-7AFCC64B-7D94-48A0-86CF-8E7EF55DF68F.html ■ESXiホストのライセンスの設定 https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vcenterhost.doc/GUID-1B128360-0060-40F2-A6F0-43CD2534B034.html​   ■Virtual SAN が有効なクラスタのライセンス https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vcenterhost.doc/GUID-31AADB51-799C-40C2-882C-8D71B31C4BB9.html ■vSAN クラスタのライセンス設定 https://docs.vmware.com/jp/VMware-vSphere/6.7/com.vmware.vsphere.vsan-planning.doc/GUID-A2A2EDDA-4C4D-438C-98DF-6511C5DF72B2.html   ■ Dell EMC VxRail: Troubleshooting guide for License issues https://support.emc.com/kb/535402   ■ Dell EMC VxRail: How to activate PAC for vSphere License https://support.emc.com/kb/531914​   ■ VxRail: PAC expired before deployment. https://support.emc.com/kb/537422   ■注意点 ・Licenseによる機能制限に関して VxRailは稼働してから60日間の使用可能なEvaluation Licenseという、すべての機能が使用できる状態のLicenseで初期導入時されます ご購入されたLicenseの種類によっては、導入直後に使用可能だった機能（DRS等）が使用できなくなる機能もございますのでご注意ください   ・ブラウザに関して Dell Digital LockerやMyVMwareで操作が正常に動作しない場合、ブラウザを変更すると成功する場合もございます https://kb.vmware.com/s/article/2006975?lang=ja

この記事ではライブダンプの採取方法について紹介します。 本ライブダンプの採取は、VMwareもしくはVxRailのサポートから指示がある場合のみご使用ください。障害の状況によっては動作しない場合もございます。 [ESXiのプロセスダンプの採取方法] １．live dump対象ESXiホストのコンソール(SSH可) へログインします。        /var/core　に前回の不要のコアダンプファイルは削除しておく。 ２．.以下のコマンドを実行し、プロセス名（vpxa、hostd等） の Cartel ID (2 列目の値) を記録します。        ps -C | grep 'プロセス名' 　※psコマンドの -C　オプションは、カルテルのみの表示となります。カルテルとは、既存ワールドのグループのことです。 ３．.記録した Cartel ID を利用し、以下のコマンドで live core を生成します。      # vsish -e set /userworld/cartel/< CartelID >/debug/livecore 1 ４．上記ステップで以下にファイルが作成されます。      /var/core/vpxa-zdump.*      /var/core/hostd-zdump. *　のファイルが作成されます。 <実行例> [root@vxrail-esxi02:~] ls /var/core/ hostd-zdump.000   vmkernel-zdump.1  vmkernel-zdump.2 [root@vxrail-esxi02:~] rm /var/core/* [root@vxrail-esxi02:~] ls /var/core [root@vxrail-esxi02:~] [root@vxrail-esxi02:~] ps -C | grep 'hostd ' [root@vxrail-esxi02:~] 2101421  2101421  hostd [root@vxrail-esxi02:~] vsish -e set /userworld/cartel/2101421/debug/livecore 1 [root@vxrail-esxi02:~] ls /var/core/ hostd-zdump.000 [ESXiのKernelダンプの採取方法] １．対象ESXiホストのコンソール(SSH可) へログインします。         /var/core　に前回の不要のコアダンプファイルは削除しておく。 ２．以下のコマンドを実行します。CPUは30～40%のぐらいでした。 　# localcli --plugin-dir /usr/lib/vmware/esxcli/int/ debug livedump perform ３．以下のコマンドを実行し、Active deviceのpathを確認します。 　# localcli system coredump partition list ４．以下のコマンドを実行し、kenel dumpをファイルに生成します。 　# esxcfg-dumppart -C -D <path> 　　　<<<<<< Active deviceを指定して採取      ※ /var/core/vmkernel-zdump.*　のファイルが作成されます。 ５．ログバンドル (vm-support)上述のlive dump および kenel dump の取得手順を実施頂きますと、 　各ファイルは ログバンドルに含まれて取得出来る形となります。 　 　以下のコマンドによりログバンドルを生成し、ご収集しサポートへの送付をお願い致します。 　# vm-support ＜ご参考＞ 　　VxRailは上記ダンプパーティションのサイズが十分出ない場合に以下のコアダンプファイルが用意されております。         # localcli system coredump file list Path                                                                                                                                                                                                                       Active  Configured  Size ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- /vmfs/volumes/5be969be-d54d563c-39bd-246e966fc298/vmkdump/4C4C4544-0034-4710-8031-B5C04F314C32-12495880192.dumpfile  true    true        12495880192 <実行例>      [root@vxrail-esxi02:~]  localcli --plugin-dir /usr/lib/vmware/esxcli/int/ debug livedump perform      [root@vxrail-esxi02:~]  localcli system coredump partition list Name                                                                                                                                                       Path                                                                                                                                                                                         Active  Configured ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- t10.ATA_____DELLBOSS_VD_____________________________092c8aeeebf9001000000000:7  /vmfs/devices/disks/t10.ATA_____DELLBOSS_VD_____________________________092c8aeeebf9001000000000:7  false   false t10.ATA_____DELLBOSS_VD_____________________________092c8aeeebf9001000000000:9  /vmfs/devices/disks/t10.ATA_____DELLBOSS_VD_____________________________092c8aeeebf9001000000000:9  true    true <<<< 2GB 　 [root@vxrail-esxi02:~]  esxcfg-dumppart -C -D '/vmfs/devices/disks/t10.ATA_____DELLBOSS_VD_____________________________092c8aeeebf9001000000000:9’ 　 Created file /scratch/core/vmkernel-zdump.1

※※ vSAN 6.7U3 以降の場合は VMware KB 70650をご確認ください ※※ VxRail 4.7.520/7.0.130 以降の場合は Dell Technologies の SolveOnlineの手順書を参照ください   VxRailでは、VxRail Manager GUIにてクラスタのシャットダウンボタンを提供しており、簡単にクラスタシャットダウンを実施できますが、 VMware KB#60424​(https:/kb.vmware.com/s/article/60424) で紹介されている通り、停電対応などでvSANクラスタの全停止を伴う作業を実施した場合、vSAN Clusterの次回起動時にアクセスできないDiskやNodeがあると、関連する一部のvSAN データストア上のデータ（vSAN Object）にアクセス不可となる可能性があります。 この事象を防ぐために、上記KBに従ったStepによってシャットダウンを実施することを推奨しております。 ※本記事を公開するにあたり 十分検証確認を行っておりますが、データ保全に関して当アカウントは責任を負いかねますのであらかじめご了承下さい   本記事は、VxRail 4.7.300未満のすべてのVersionで適用されます。 VxRail 4.7.300以降のVersionをご使用の場合は、VMware KB#70650 の手順を参照してクラスタのシャットダウン・起動を実施してください。   下記EMCのKBに従ったVxRailの起動手順を詳細にご説明します。 　VxRail: vSAN cluster shutdown and restart may lead to data unavailability after a single failure (Related VMware KB# 60424) 　https://support.emc.com/kb/528792   VMTN コミュニティでは起動と停止の手順を以下の通り公開しています。    ①  VMware KB#60424に基づいたVxRailにおけるクラスタシャットダウン手順      ②  VMware KB#60424に基づいたVxRailにおけるクラスタ起動手順  <--- 本記事です     まず、大まかな流れとしては、下記のようになります。 ■Node起動・ステータス確認編 　１．Nodeの起動 　２．vSAN Diskの正常ステータスの確認 　３．メンテナンスモードの解除   ■vSANトラフィックの復活・仮想マシン起動編 　４．crontabの編集 　５．vSANオブジェクトの健全性確認 　６．crontabの再編集 　７．VCSA/PSCの仮想マシンを起動する 　８．VCSA/PSC以外のすべての仮想マシンを起動する     ■Node起動・ステータス確認編 １．Nodeの起動 電源ケーブルを抜いている場合は接続し、iDRAC/BMC経由、又は物理的に電源ボタンを押してNodeを起動してください また、ESXiが正常に起動していることをモニターや仮想コンソールから併せて確認してください   起動が完了したら、下記コマンドをすべてのESXiホストで実行しシャットダウン時と同じステータスであることを確認します [root@esxi01:~] esxcli vsan cluster get | grep "Local Node State"    Local Node State: MASTER         なお、出力結果として”Local Node State: DISCOVER”と表示される場合があります。      その際、localcliコマンドで MASTERステータスであれば、問題ありません。     [root@esxi01:~] localcli vsan cluster get | grep "Local Node State"       Local Node State: MASTER     ２．vSAN Diskの正常ステータスの確認           下記コマンドをすべてのESXiホストで実行し、全てのDiskの"In CMMDS:" の値が "true" であることを確認します [root@esxi01:~] esxcli vsan storage list | grep "In CMMDS"    In CMMDS: true    In CMMDS: true    In CMMDS: true    In CMMDS: true    In CMMDS: true    In CMMDS: true   ３．下記コマンドをすべてのESXiホストで実行し、メンテナンスモードの解除を実施します [root@esxi01:~] esxcli system maintenanceMode set -e false   [root@esxi01:~] esxcli vsan cluster get | grep "Maintenance Mode State"    Maintenance Mode State: OFF       ■vSANトラフィックの復活・仮想マシン起動編 ４．すべてのESXiホストにて、crontabを編集していきます。 ※すべてのESXiホストで同時に実行する必要があるため、4-4で設定する時刻はNode数と作業の手際を考慮した時刻で設定してください   4-1. 各ESXiホストにsshでログインし、クラスタシャットダウン時に配置したスクリプトを確認します。 ・ls コマンドでファイルを転送したservice-datastore1のディレクトリにスクリプト「post_reboot.sh」があることを確認。   [root@esxi01:/vmfs/volumes/5d330ce3-a0099b84-7fbe-XXXXXXXXXXXX] ls -l total 1024 drwxr-xr-x    1 root     root         73728 Jul 22 09:00 idrac drwxr-xr-x    1 root     root         73728 Jul 20 15:37 images drwxr-xr-x    1 root     root         73728 Jul 20 12:55 order -rwxr-xr-x    1 root     root           498 Jul 24 12:43 post_reboot.sh -rwxr-xr-x    1 root     root           346 Jul 24 12:43 pre_reboot.sh drwxr-xr-x    1 root     root         69632 Jul 20 13:00 pservice drwxr-xr-x    1 root     root         73728 Jul 22 09:00 ptagent drwxr-xr-x    1 root     root         73728 Jul 20 13:02 reset drwxr-xr-x    1 root     root         73728 Jul 20 12:55 vibs d-w-r-xr-T    1 root     root         73728 Jul 20 13:36 vmkdump   ・post_reboot.shに、追記した「esxcli vsan network ip add -i <VMkNic Name> -T=<Traffic Type>」の一文があることを確認 　※追記したものがない場合は、再度編集して追記してください [root@esxi01:~] vi /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/post_reboot.sh   #!/bin/sh # Make sure to do this before running pre_reboot.sh on hosts. # # Using the output of the command 'esxcli van network list', find # the names of the vmknics and their associated traffic types. # # For each of those vmknics add one command to enable vsan traffic # using the following command. # # # esxcli vsan network ip add -i <VMkNic Name> -T=<Traffic Type> # # Ex 1: #       esxcli vsan network ip add -i vmk98 -T=vsan # Ex 2: #       esxcli vsan network ip add -i vmk99 -T=witness esxcli vsan network ip add -i vmk3 -T=vsan 4-2.  rootのcrontabのバックアップをとっておく [root@esxi01:~] cp /var/spool/cron/crontabs/root /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/root_crontab.BKP2   4-3. システムの現在時刻を確認する(VxRailではUTC <JST-9> のTimezoneとなります) [root@esxi01:~] date Sun Jul 28 03:38:56 UTC 2019   4-4. viコマンドでcrontabを編集し、下記のようなpost_reboot.shスクリプトを実行する1文を記載します ※クラスタシャットダウン時に記載した、pre_reboot.shスクリプトを実行する1文は削除してください [root@esxi01:~] vi /var/spool/cron/crontabs/root   #min hour day mon dow command 1    1    *   *   *   /sbin/tmpwatch.py 1    *    *   *   *   /sbin/auto-backup.sh 0    *    *   *   *   /usr/lib/vmware/vmksummary/log-heartbeat.py */5  *    *   *   *   /bin/hostd-probe.sh ++group=host/vim/vmvisor/hostd-probe/stats/sh 00   1    *   *   *   localcli storage core device purge */2 * * * * /usr/lib/vmware/vsan/bin/vsanObserver.sh ++group=host/vim/vmvisor/vsanobserver */5  *    *   *   *   /usr/lib/emc/secure_process.sh "timeout -t 90 /usr/bin/env python /bin/marvin-endpoint-post" 0 * * * * /bin/sh /opt/dell/DellPTAgent/scripts/clearTmpFile.sh */5 * * * * python /opt/dell/DellPTAgent/scripts/PTAgent_Monitor_35.pyc */15  *    *   *   *   /usr/lib/emc/collector.sh >> /var/log/emc/logs/mystic-collector.log 2>&1 */1  *    *   *   *   /usr/lib/emc/secure_process.sh "/usr/lib/emc/shutdown_ESX.py" 30 4 28 7 * /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/post_reboot.sh ※数字は左から分 時 日 月となりますので、上記例の場合、7/28 4:30(UTC<JST-9>)にpost_reboot.shを実行するように指定してあります。 ※pre_reboot.shはシャットダウン時に使用するスクリプトのため、起動時には設定しないでください   4-5. 下記コマンドを実行してcrondを再起動し、編集したcrontabの内容を適用させます。 [root@esxi01:~]  kill -HUP $(cat /var/run/crond.pid)   [root@esxi01:~]  /usr/lib/vmware/busybox/bin/busybox crond   ５．vSANオブジェクトの健全性確認を確認します。 5-1. 指定した時刻が過ぎてから、下記コマンドをすべてのESXiホストで実行し、cron jobの内容が問題なく実行されたことを確認します [root@esxi01:~] esxcli vsan network list Interface    VmkNic Name: vmk3    IP Protocol: IP    Interface UUID: 1334335d-8295-a311-5c11-e4434b18d3b4    Agent Group Multicast Address: 224.2.3.4    Agent Group IPv6 Multicast Address: ff19::2:3:4    Agent Group Multicast Port: 23451    Master Group Multicast Address: 224.1.2.3    Master Group IPv6 Multicast Address: ff19::1:2:3    Master Group Multicast Port: 12345    Host Unicast Channel Bound Port: 12321    Multicast TTL: 5   Traffic Type: vsan   5-2. 下記コマンドをすべてのESXiホストで実行し、何も出力されずにプロンプトが返ってくることを確認します [root@esxi01:~] cmmds-tool find -f python | grep -C5 CONFIG_STATUS | grep content | grep -v "state....7\|state....15" [root@esxi01:~] 問題があるデータが存在する場合、何らかの返り値が出力されます。     ６．すべてのESXiホストにて、crontabを編集していきます。 6-1. viコマンドでcrontabを編集し、下記のようにpost_reboot.shスクリプトを実行する1文を削除した状態にします （クラスタシャットダウン実施前の状態） [root@esxi01:~] vi /var/spool/cron/crontabs/root #min hour day mon dow command 1    1    *   *   *   /sbin/tmpwatch.py 1    *    *   *   *   /sbin/auto-backup.sh 0    *    *   *   *   /usr/lib/vmware/vmksummary/log-heartbeat.py */5  *    *   *   *   /bin/hostd-probe.sh ++group=host/vim/vmvisor/hostd-probe/stats/sh 00   1    *   *   *   localcli storage core device purge */2 * * * * /usr/lib/vmware/vsan/bin/vsanObserver.sh ++group=host/vim/vmvisor/vsanobserver */5  *    *   *   *   /usr/lib/emc/secure_process.sh "timeout -t 90 /usr/bin/env python /bin/marvin-endpoint-post" 0 * * * * /bin/sh /opt/dell/DellPTAgent/scripts/clearTmpFile.sh */5 * * * * python /opt/dell/DellPTAgent/scripts/PTAgent_Monitor_35.pyc */15  *    *   *   *   /usr/lib/emc/collector.sh >> /var/log/emc/logs/mystic-collector.log 2>&1 */1  *    *   *   *   /usr/lib/emc/secure_process.sh "/usr/lib/emc/shutdown_ESX.py"   6-2. 下記コマンドを実行してcrondを再起動し、編集したcrontabの内容を適用させます。 [root@esxi01:~]  kill -HUP $(cat /var/run/crond.pid)   [root@esxi01:~]  /usr/lib/vmware/busybox/bin/busybox crond     ７．PSC -> VCSAの順に仮想マシンを起動します。 7-1. クラスタシャットダウン時にメモした、PSCおよびVCSAが稼働しているESXiホストのHost Clientにアクセスし、 PSC -> VCSAの順に仮想マシンを起動します。   左側のMenuのVirtual Machinesを選択します vCenter Server Platform Services Controllerを選択し、Power ONを実施します その後PSCの起動を確認し、vCenter Server Applianceも同様にPower ONを実施します     7-2.  Health Checkの実施 VCSA及びPSCのPower Onが完了したら、vSANのHealth Checkを実施します。 vSphere Web ClientへLoginを実施し、 VxRail: Health Check 方法 のvSAN ヘルスチェック を実施しエラーがないことを確認します   外部vCenterにてvSAN Clusterを管理し、Shutdown前にvSphere HA及びDRSの設定を変更していた場合は、元の設定に戻してください。   ８．VCSA/PSC以外のすべての仮想マシンを起動します VxRail ManagerやESRSを含めた、その他の仮想マシンの起動を実施します vSANクラスタの計画停止を行う際、再起動時に故障により起動できないノードがあった場合に一部のデータにアクセスできなくなることがあります。

※※ vSAN 6.7U3 以降の場合は VMware KB 70650をご確認ください ※※ VxRail 4.7.520/7.0.130 以降の場合は Dell Technologies の SolveOnlineの手順書を参照ください   VxRailでは、VxRail Manager GUIにてクラスタのシャットダウンボタンを提供しており、簡単にクラスタシャットダウンを実施できますが、 VMware KB#60424​(https:/kb.vmware.com/s/article/60424)で紹介されている通り、VSAN環境では、通常のシャットダウン手順では、データの不整合を引き起こす恐れがあり、 KBに従ったStepによってシャットダウンを実施することを推奨しております。 ※本記事を公開するにあたり 十分検証確認を行っておりますが、データ保全に関して当アカウントは責任を負いかねますのであらかじめご了承下さい。   本記事は、VxRail 4.7.300未満のすべてのVersionで適用されます。 VxRail 4.7.300以降のVersionをご使用の場合は、VMware KB#70650の手順を参照してクラスタのシャットダウン・起動を実施してください。   下記EMCのKBに従ったVxRailのシャットダウン手順を詳細にご説明します。 　VxRail: vSAN cluster shutdown and restart may lead to data unavailability after a single failure (Related VMware KB# 60424) 　https://support.emc.com/kb/528792   VMTN コミュニティでは起動と停止の手順を以下の通り公開しています。    ①  VMware KB#60424に基づいたVxRailにおけるクラスタシャットダウン手順   <--- 本記事です    ②  VMware KB#60424に基づいたVxRailにおけるクラスタ起動手順   まず、大まかな流れとしては、下記のようになります。 ■事前準備編 　１．健全性の確認 　２．各ESXiホストのNTP時刻同期の確認 　３．スクリプトの配置 　４．スクリプトの編集   ■VSAN切り離し・シャットダウン編 　５．VCSA/PSC以外のすべての仮想マシンをシャットダウンする 　６．データ移行有無の確認 　７．VCSA/PSCのシャットダウン 　８．crontabの編集 　９．Nodeのシャットダウン   事前準備編に関しては、クラスタシャットダウンを実施する当日以前に実施することが可能です。   ■事前準備編 １．下記を参照して、クラスタの健全性を確認します。 VxRail: Health Check 方法 特に「データ」-「VSANオブジェクトの健全性」の項目にて、「健全」以外の項目がすべて0であることを確認します。 また、念の為、下記のログを取得しておくことを推奨します。 vCenter vSAN health status script 取得手順   ２．すべてのESXiホストがNTPで時刻同期されていることを確認します。 https://kb.vmware.com/s/article/57147   ３．VMware KB#60424​(https:/kb.vmware.com/s/article/60424) に添付されている２つのスクリプト「pre_reboot.sh」「post_reboot.sh」をPCのデスクトップなどにダウンロードし、 すべてのESXiホストのサービスデータストア（VSAN以外のデータストア）に配置します。 ※KB添付のscriptは予告なく名称並びに構文が修正されることがあります。都度KBをご確認頂き、最新のものをご使用下さい。   ダウンロードしたスクリプトをホストに配置する方法としては、下記のような手順があります。 どちらを利用いただいても問題ありません。   A. scp（WinSCPやFileZillaなどのファイル転送ソフトウェア)を用いる A-1. 各ESXiホストのsshを有効にする。 ESXi、vCenter、PSCのSSH有効化   A-2. ファイル転送ソフトでESXiホストに接続する。   A-3. /vmfs/volumes配下のxxxxxxxxxxxxx-01-01-service-datastore1という名前のフォルダに移動し、ここに２つのスクリプトをアップロードします。   B. 各ESXiホストのHost Clientにアクセスし、データストアブラウザを利用する。   ４．各ESXiホストにsshでログインし、配置した２つのスクリプトを編集します。 ESXi、vCenter、PSCのSSH有効化   4-1. 2つのスクリプトに実行権限を付与します。   ・ls コマンドでファイルを転送したservice-datastore1のディレクトリに２つのスクリプト「pre_reboot.sh」「post_reboot.sh」があることを確認。    ※cd でディレクトリ移動するとディレクトリ名が変わりますが、問題ございません [root@esxi01:~] cd /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/   [root@esxi01:/vmfs/volumes/5d330ce3-a0099b84-7fbe-XXXXXXXXXXXX] ls idrac           post_reboot.sh  ptagent         vmkdump images          pre_reboot.sh   reset order           pservice        vibs [root@esxi01:/vmfs/volumes/5d330ce3-a0099b84-7fbe-XXXXXXXXXXXX] ls -l total 1024 drwxr-xr-x    1 root     root         73728 Jul 22 09:00 idrac drwxr-xr-x    1 root     root         73728 Jul 20 15:37 images drwxr-xr-x    1 root     root         73728 Jul 20 12:55 order -rw-r--r--    1 root     root           498 Jul 24 12:43 post_reboot.sh -rw-r--r--    1 root     root           346 Jul 24 12:43 pre_reboot.sh drwxr-xr-x    1 root     root         69632 Jul 20 13:00 pservice drwxr-xr-x    1 root     root         73728 Jul 22 09:00 ptagent drwxr-xr-x    1 root     root         73728 Jul 20 13:02 reset drwxr-xr-x    1 root     root         73728 Jul 20 12:55 vibs d-w-r-xr-T    1 root     root         73728 Jul 20 13:36 vmkdump   ・chmodコマンドで実行権限を付与(chmod +x <ファイル名>) [root@esxi01:/vmfs/volumes/5d330ce3-a0099b84-7fbe-XXXXXXXXXXXX] chmod +x post_reboot.sh   [root@esxi01:/vmfs/volumes/5d330ce3-a0099b84-7fbe-XXXXXXXXXXXX] chmod +x pre_reboot.sh   ・実行権限が付与されていることを確認(-rwxr-xr-x のような出力結果になります) [root@esxi01:/vmfs/volumes/5d330ce3-a0099b84-7fbe-XXXXXXXXXXXX] ls -l total 1024 drwxr-xr-x    1 root     root         73728 Jul 22 09:00 idrac drwxr-xr-x    1 root     root         73728 Jul 20 15:37 images drwxr-xr-x    1 root     root         73728 Jul 20 12:55 order -rwxr-xr-x    1 root     root           498 Jul 24 12:43 post_reboot.sh -rwxr-xr-x    1 root     root           346 Jul 24 12:43 pre_reboot.sh drwxr-xr-x    1 root     root         69632 Jul 20 13:00 pservice drwxr-xr-x    1 root     root         73728 Jul 22 09:00 ptagent drwxr-xr-x    1 root     root         73728 Jul 20 13:02 reset drwxr-xr-x    1 root     root         73728 Jul 20 12:55 vibs d-w-r-xr-T    1 root     root         73728 Jul 20 13:36 vmkdump   4-2. VSANネットワークの情報をバックアップし、現在の設定値を確認します。                   [root@esxi01:~] esxcli vsan network list > /tmp/vsan_network_list_backup.txt   ・"VmkNic Name"のvmkを確認（下記の場合はvmk3となります） [root@esxi01:~] esxcli vsan network list Interface    VmkNic Name: vmk3    IP Protocol: IP    Interface UUID: 1334335d-8295-a311-5c11-e4434b18d3b4    Agent Group Multicast Address: 224.2.3.4    Agent Group IPv6 Multicast Address: ff19::2:3:4    Agent Group Multicast Port: 23451    Master Group Multicast Address: 224.1.2.3    Master Group IPv6 Multicast Address: ff19::1:2:3    Master Group Multicast Port: 12345    Host Unicast Channel Bound Port: 12321    Multicast TTL: 5   Traffic Type: vsan     4-3. 4-2で確認した内容を基に、２つのスクリプトファイルを編集します。 ・pre_reboot.shには「esxcli vsan network ip remove -i <VMkNic Name>」の一文を追加 　※上記出力例の場合は、<VMkNic Name> に vmk3を当てはめます [root@esxi01:~] vi /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/pre_reboot.sh   #!/bin/sh # Using the output of the command 'esxcli van network list', find # the names of the vmknics and their associated traffic types. # # For each of those vmknics add one command to disable vsan traffic # using the following command. # # esxcli vsan network ip remove -i <VMkNic Name> # # Ex: #       esxcli vsan network ip remove -i vmk98 esxcli vsan network ip remove -i vmk3     ・post_reboot.shには「esxcli vsan network ip add -i <VMkNic Name> -T=<Traffic Type>」の一文を追加 　※上記出力例の場合は、<VMkNic Name> に vmk3を当てはめ、<Traffic Type>はvsanをあてはめます [root@esxi01:~] vi /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/post_reboot.sh   #!/bin/sh # Make sure to do this before running pre_reboot.sh on hosts. # # Using the output of the command 'esxcli van network list', find # the names of the vmknics and their associated traffic types. # # For each of those vmknics add one command to enable vsan traffic # using the following command. # # # esxcli vsan network ip add -i <VMkNic Name> -T=<Traffic Type> # # Ex 1: #       esxcli vsan network ip add -i vmk98 -T=vsan # Ex 2: #       esxcli vsan network ip add -i vmk99 -T=witness esxcli vsan network ip add -i vmk3 -T=vsan       ■VSAN切り離し・シャットダウン編 【注意】 外部vCenterにてvSAN Clusterを管理している場合、ESXiホストをメンテナンスモードに移行時に不要な仮想マシンの移動を防ぐため、 Shutdownする予定のvSAN Clusterの設定で、vSphere HAは”OFF(オフ)”、DRSは"Manual(手動)"への変更を推奨させていただきます。   ５．vCenter Server ApplianceとPlatform Service Controllerを除くすべての仮想マシンをシャットダウンします。   ６．データの移行(resync)が動作していないことを確認します。 A. vCSAへsshでログインし、RVCで確認 EMC Community Network - DECN: VxRail: RVC(Ruby vSphere Console) ベーシック Connected to service     * List APIs: "help api list"     * List Plugins: "help pi list"     * Launch BASH: "shell"   Command> shell Shell access is granted to root root@tsevxrail-vcsa [ ~ ]# rvc Install the "ffi" gem for better tab completion. Host to connect to (user@host): administrator@vsphere.local@localhost password: 0 / 1 localhost/ > cd 1 /localhost> ls 0 VxRail-Datacenter (datacenter) /localhost> cd 0 /localhost/VxRail-Datacenter> ls 0 storage/ 1 computers [host]/ 2 networks [network]/ 3 datastores [datastore]/ 4 vms [vm]/ /localhost/VxRail-Datacenter> cd 1 /localhost/VxRail-Datacenter/computers> ls 0 VxRail-Virtual-SAN-Cluster-5805c8ee-d3cd-4af5-9988-XXXXXXXXXXXX (cluster): cpu 290 GHz, memory 905 GB /localhost/VxRail-Datacenter/computers> vsan.resync_dashboard 0 2019-07-28 00:43:25 +0000: Querying all VMs on vSAN ... 2019-07-28 00:43:25 +0000: Querying all objects in the system from tsevxrail-esxi02.cpsd.local ... 2019-07-28 00:43:25 +0000: Got all the info, computing table ... +-----------+-----------------+---------------+ | VM/Object | Syncing objects | Bytes to sync | +-----------+-----------------+---------------+ +-----------+-----------------+---------------+ | Total     | 0               | 0.00 GB       | +-----------+-----------------+---------------+     B. vSphere 6.5(VxRail4.5)以降の場合、ESXiホストにsshでログインして確認 [root@esxi01:~] esxcli vsan debug resync summary get    Total Number Of Resyncing Objects: 0    Total Bytes Left To Resync: 0    Total GB Left To Resync: 0.00       ７．データの移行が無いことを確認したら、PSC -> VCSAの順にシャットダウンします。 起動時に困らないように、PSCおよびVCSAが稼働しているESXiホストをメモします。   シャットダウンの手順は様々ありますが、下記は例としてVAMI（アプライアンス管理インターフェース）からのシャットダウン手順をご案内します。 VAMI（アプライアンス管理インターフェース）へアクセスするには、それぞれ、VCSA/PSCのIP address宛にhttpsで5480ポートを指定してアクセスできます。 https://VCSA-ip-address:5480/ https://PSC-ip-address:5480/   ８．すべてのESXiホストにて、crontabを編集していきます。 ※すべてのESXiホストで同時に実行する必要があるため、8-3で設定する時刻はNode数と作業の手際を考慮した時刻で設定してください   8-1. rootのcrontabのバックアップをとっておく [root@esxi01:~] cp /var/spool/cron/crontabs/root /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/root_crontab.BKP   8-2. システムの現在時刻を確認する(VxRailではUTC <JST-9> のTimezoneとなります) [root@esxi01:~] date Sun Jul 28 03:38:56 UTC 2019   8-3. viコマンドでcrontabを編集し、下記のようなpre_reboot.shスクリプトを実行する1文を記載します [root@esxi01:~] vi /var/spool/cron/crontabs/root   #min hour day mon dow command 1    1    *   *   *   /sbin/tmpwatch.py 1    *    *   *   *   /sbin/auto-backup.sh 0    *    *   *   *   /usr/lib/vmware/vmksummary/log-heartbeat.py */5  *    *   *   *   /bin/hostd-probe.sh ++group=host/vim/vmvisor/hostd-probe/stats/sh 00   1    *   *   *   localcli storage core device purge */2 * * * * /usr/lib/vmware/vsan/bin/vsanObserver.sh ++group=host/vim/vmvisor/vsanobserver */5  *    *   *   *   /usr/lib/emc/secure_process.sh "timeout -t 90 /usr/bin/env python /bin/marvin-endpoint-post" 0 * * * * /bin/sh /opt/dell/DellPTAgent/scripts/clearTmpFile.sh */5 * * * * python /opt/dell/DellPTAgent/scripts/PTAgent_Monitor_35.pyc */15  *    *   *   *   /usr/lib/emc/collector.sh >> /var/log/emc/logs/mystic-collector.log 2>&1 */1  *    *   *   *   /usr/lib/emc/secure_process.sh "/usr/lib/emc/shutdown_ESX.py" 30 4 28 7 * /vmfs/volumes/DE700xxxxxxx16-01-01-service-datastore1/pre_reboot.sh ※数字は左から分 時 日 月となりますので、上記例の場合、7/28 4:30(UTC<JST-9>)にpre_reboot.shを実行するように指定してあります。 ※post_reboot.shは起動時に使用するスクリプトのため、シャットダウン時には設定しないでください ※すべてのHostで同様の内容にしてください   8-4. 下記コマンドを実行してcrondを再起動し、編集したcrontabの内容を適用させます。 [root@esxi01:~]  kill -HUP $(cat /var/run/crond.pid)   [root@esxi01:~]  /usr/lib/vmware/busybox/bin/busybox crond   8-5. 指定した時刻が過ぎてから、下記コマンドをすべてのESXiホストで実行し、cron jobの内容が問題なく実行されたことを確認します [root@esxi01:~] esxcli vsan cluster get | grep "Local Node State"    Local Node State: MASTER ※スクリプト実行前などでは、BACKUPやAGENTといったStateのNodeが存在します。すべてのESXiホストでMASTERステータスであれば、 　問題なくcron jobでコマンドが実行されたことを確認できます   なお、出力結果として”Local Node State: DISCOVER”と表示される場合があります。 その際、localcliコマンドで MASTERステータスであれば、問題なくcron jobが実行された と判断して構いません。 [root@esxi01:~] localcli vsan cluster get | grep "Local Node State"    Local Node State: MASTER   ９．各ESXiホストをメンテナンスモード(esxcli system maintenanceMode set -e true -m noAction)に入れた後、Nodeのシャットダウンを実施します。 ※シャットダウンはHost clientまたはDCUI経由にて実施し、iDRACの電源管理などから実施しないようにしてください      その他参考:VxRail:nodeの停止/起動(メンテナンスモードの終了) 手順   9-1. esxcliコマンドを使用して、ESXiをメンテナンスモードに移行 "esxcli system maintenanceMode get"にて、メンテナンスモードかどうかの確認（Enableの場合、メンテナンスモード状態） "esxcli system maintenanceMode set -e true -m noAction"にて、No Actionのオプションでメンテナンスモードへ移行実施 [root@esxi01:~] esxcli system maintenanceMode get Disabled [root@esxi01:~] esxcli system maintenanceMode set -e true -m noAction   [root@esxi01:~] esxcli system maintenanceMode get Enabled   9-2. vSphere Host Client または、DCUIよりESXiのShutdownを実施 下記はDCUIでの操作を例にします   ESXi shellの画面にいる場合、[Alt] + [F2]を押してESXiの画面に移動してから、[F12] を押しESXiのroot userでLoginを実施 ※password入力時は、"Login name"の部分で正しくキーボード入力されるか確認してから実施すると良いです 　仮想コンソールのキーボード設定によって"@"などの位置が違う場合がございます   "Shutdown/Restart"のMenuが表示されるので、[F2] Shut Downを選択してESXiのShutdownを実施してください   VxRail のvSAN Clusterの全てのESXiにて実施してください。

この記事では、vm-supportの作成方法をご紹介致します。 ※正式な手順はVMware KBをご参照ください   !!!!! 注意 !!!!! vSphere 6.7U1 （VxRail 4.7.1xx） で vSAN iSCSI Target を利用されている場合、本手順を実行することでPSODとなる既知の不具合が報告されております。 上記に該当する場合は以下のVMware KB/Dell EMC KBをご参照いただき、ログ取得前に対象ホストをメンテナンスモードにしてください。 なお、両KBは予告なく変更されることがございます。内容に差異がある場合はDell EMC KBを劣後としていただくようお願いします。 VMware KB Collecting support bundle might cause host failure with vSAN 6.7U1 when using WSFC via vSAN iSCSI Target Service (67881) https://kb.vmware.com/s/article/67881​ Dell EMC KB Dell EMC VxRail: Host hit unexpected reboot when collecting support bundle with vSAN iSCSI Target owner host   vc-supportログとセットでvm-supportログを生成するも、vm-supportが正常に同梱されない時や生成されない時など、 指定のESXiホストのvm-supportログだけを取得する際に利用できます。   vSphere Web Clientを利用されている方は下記をご参照ください vm-suuportログ取得手順（vSphere Web Client利用）   vSphere Web Clientを利用して、単体ESXiホストからのvm-supportログ生成手順      1. vSphere Clientにログイン        2. Home > Host and Clusters > 対象ESXiを右クリック > Export System Logs..を選択                  3. Export System LogsのMenuにて、"EXPORT LOGS" のボタンを選択           ※ブラウザにて新しいtabが開きますので、Pop-up windowは許可するようにしてください           　 また、新しいtabはログの生成が完了するまで閉じないでください           ※特にサポートからの依頼がなければ、デフォルトで選択されている項目のみでvm-supportを作成いただいて問題ございません。                  4. ログの生成が完了すると、ダウンロードが開始されるのでログを保存（ご使用のブラウザにて挙動が違いますのでご注意ください）                a. Chromeの場合は、自動でダウンロードが開始されます                                      b. Firefoxの場合は下記のようなPop-upが表示されます                       ※ダウンロードされたファイルの中に、vm-supportが保存されております   ### VMware KB 正式な手順は下記KBの該当項目をご参照ください Collecting diagnostic information for VMware products (1008524)     ・VMware ESXi/ESX

vSphere のライセンスにバンドルされるvSphere Data Protection VM（VDP）のUpgrade 方法です。 Part 2ではUpgrade VDPボタンを押下して、実際のUpgradeフェーズのご紹介します。 !!!!! 注意 !!!!! vSphere Data Protection（VDP）のUpgradeはVxRailのサポートに含まれません。 VxRailのUpgradeの際にvSphere Data Protection（VDP）はUpgradeされませんので、お客様にて事前にUpgradeを実施いただく必要があります。 本資料は参考資料としていただき、正式な手順についてはVMware社の提供する資料をご参照ください。 本資料で紹介されない細かい手順や、トラブルシューティングなどについてもVMware社提供のKBやドキュメントを御参照ください ### vSphere Data Protection のUpgrade参考手順 ### Upgradeの実行 前図赤枠内のUpgrade VDPボタンを押下してUpgradeを実行してください。 途中で１～２度ほどVDPとの接続が切れますが正常動作です。 切断されましたら再度ログインしてください。自動的にUpgradeの進捗画面へ遷移します。 実行中の画面については下記のGIFをご参考にしてください。 GIFが動かない場合は画像をクリックしてください 始まったら基本的に放置で問題ありません。 2回目の切断（Reboot）ののち再度接続してUpgradeタブにいくと、下図のようになにも表示されませんがまだUpgradeは続いています。 しばらくすると下図のように100％の画面が表示されます。 Upgradeが成功するとVDPは自動的にShutdownされます。 Upgrade事後作業 VDPの正常動作を確認 Upgradeが完了したらVDPを起動し、バックアップやVCとの接続性などを確認してください。 Upgrade後にvCenterから接続できなくなったら、一度web clientをLog out/inしてみてください。 それでもだめな場合はPSCとVCSAを再起動してみてください。 動作に問題がある場合はサポートへ連絡し、必要に応じてUpgrade前にSnapshotに戻してください ShutDown～Snapshotの削除 VDPの正常稼働を確認できたら、WebClientからShutdownを実行してください。（VDP のSnapshotの取得の手順を参照） WebClientからVDPを右クリックして「Snapshotの管理」を起動し、Upgrade前に取得したSnapShotを削除してください。 Hard Disk2以降の仮想ディスクのDisk Modeを「Independent - Persistent」にもどしてください。（VDP のSnapshotの取得の手順を参照） ISOファイルのアンマウント Shutdown状態のまま、Edit Settingより、以下の図を参考にISOファイルをアンマウントしてください。 ※Client Deviceを選択して、ConnectedのCheckが外れていることを確認する VDPのPowerOn 最後にVDPをPower ONしてください サービスの正常動作を https://<IP_address_VDP_appliance>:8543/vdp-configure/ より確認してください。 Administration Guide（vSphere Data ProtectionのUpgrade概要（所要時間やマニュアル等）を参照）の“Running an Integrity Check” のセクションを参考に、手動にてIntegrity Checkを実行ください Integrity Checkの実行 管理者ガイドの手順に従い、Integrity Checkを実施してください。 WebClientから簡単に実行できます。 Integrity Checkの進捗はWebClientのRecent Task Paneから確認できます。 （Option手順）仮想ハードウェアVersionのUpgrade ### 補足情報 ### Intel CPUの脆弱性のFixを適用するためには仮想ハードウェアVersionが9以上である必要があります。 すでに対象Versionよりも高い場合、もしくはIntel CPU脆弱性の対応が不要な場合は本手順の実施の必須ではありません。 ############## 一度VDPをShutdownしてください。 WebClientよりVDPを右クリックして、「Compatibility（日本語だと互換性）」を展開して、Upgrade VM Compatibilityを選択してください Yesを選択してください Intel CPUの脆弱性のFixを適用するためには仮想ハードウェアVersionが9以上である必要があります。 すでに対象Versionよりも高ければ実施の必要はありません。 仮想ハードウェアのUpgradeが完了したらVDPをPower Onしてください Upgrade中に問題が発生したら。。。 公式の管理者ガイドの手順をよく読み、紹介されている手順を実施してください。 またそれでも解決されない場合は、検索エンジンよりVMware KBやVDPのRelease Noteを参照すると解決策が提示されていることがあります。 問題が解消されない場合はサポート窓口までご連絡ください Upgrade後にバックアップに失敗したら vSAN環境では以下に該当する可能性があります。 Dell EMC KB#494454 Dell EMC KB#494236

vSphere のライセンスにバンドルされるvSphere Data Protection VM（VDP）のUpgrade 方法です。 Part 1ではUpgrade前までのフェーズをご紹介します。 !!!!! 注意 !!!!! vSphere Data Protection（VDP）のUpgradeはVxRailのサポートに含まれません。 VxRailのUpgradeの際にvSphere Data Protection（VDP）はUpgradeされませんので、お客様にて事前にUpgradeを実施いただく必要があります。 本資料は参考資料としていただき、正式な手順についてはVMware社の提供する資料をご参照ください。 本資料で紹介されない細かい手順や、トラブルシューティングなどについてもVMware社提供のKBやドキュメントを御参照ください ### vSphere Data Protection のUpgrade参考手順 ### vSphere Data ProtectionのUpgrade概要（所要時間やマニュアル等） #### 1 ．VDPアップグレードの方法（マニュアル等） VDP 6.0の管理者ガイドに記載のあるUpgrade手順にて実施可能です。 なお、vDP6.1管理ガイドには アップグレードに関する情報が無いため6.0でのガイドをご紹介しています。 各手順の詳細はvDP6.0管理ガイドを必ずご確認下さい。 ・Administration Guide/管理者ガイド VDP 6.0 https://docs.vmware.com/en/VMware-vSphere/6.0/vmware-data-protection-administration-guide-60.pdf ・vSphere Data Protection Release Note    ※Release NoteにはUpgradeに関する不具合や推奨が記載されているので必ず事前にお目通しください        検索エンジンで検索すると簡単にヒットします またVMwareのものではありませんが、以下のサイトもご参考になるかと思います。 http://d.hatena.ne.jp/b3g/20170320 https://www.vladan.fr/how-to-upgrade-vdp/ #### 2 ．VDPアップグレード時の影響範囲 Upgrade中はバックアップやリストアなどのオペレーションができなくなります。 #### 3 ．VDPアップグレード作業の想定時間 Upgrade自体に1-4時間ほどかかります。 前後の作業がスムーズに進んだ場合でもプラスして1時間は必要となりますので、 2時間~5時間程度（トラブル無の場合）必要となります。 弊社ラボ内で実施した際は、小さいサイズのVDPでしたが、UpgradeファイルのUploadとデータ整合性チェックに時間がかかったため、4時間必要でした。 事前にUpload～整合性チェックまでは実施されておくほうがよろしいかと思います。 現在のVersionの確認 vSphere Web Clientにログインして現在ご使用のVDPのVersionをご確認ください。 ※ドロップダウンから対象のVDPを選択してConnectをClick Configure タブからVersionを確認 互換性の確認 以下のVMware社のサイトより、VxRailのESXi/VCのVersionと互換性のあるVDPのVersionを確認し、UpgradeのターゲットのVersionを決めてください。 http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?#interop&68=&1=&2=&hideEmpty=false&hideUnsupported=false ※ターゲットVersionの選定について 互換性に問題がない場合でも6.1.4以降を推奨します。 Intel CPUの脆弱性に対応するためには6.1.8以降でないといけません Upgrade Pathの確認 以下のVMware社のサイトを確認し、現在のVDPのVersionとターゲットVersionのUpgrade Pathをご確認ください。 VMware Product Interoperability Matrices Upgradeファイルのダウンロード VMware社のサイトよりターゲットVersionのVDPのUpgrade用ファイル（.iso）をダウンロードしてください。 ダウンロードページは検索エンジンから検索すると簡単に見つかります。 ダウンロードにはMy VMwareのアカウントが必要です。 VDP のSnapshotの取得 以下の手順でVDPのスナップショットをご取得ください １．VDPのShutdown WebClientからVDPを右クリックしてShutdown GuestOSを選択してシャットダウンしてください ２．Disk Modeの変更 右クリックのEdit Settingを選択し、Hard Disk2のDisk ModeをIndependent - Persistent からDependentに変更してください。 同じ操作をHard Disk3以降のすべてのDiskに対して実施してください ※Hard Disk3以降の仮想ディスクはManage Other Disksボタンから管理できます。 ３．Snapshot の作成～PowerON Hard Disk2以降のすべての仮想ディスクのDisk ModeをDependentにしたら、vSphere Data Protection VMの Snapshotを取得したのち、PowerON してください Upgradeファイルのアップロード vSANデータストアにフォルダを作成してvSphere Data ProtectionのUpgradeファイルをアップロードします。 下記のGIF動画を参考にUploadしてください ※GIFが再生されない場合は画像をクリックしてください !!!! 補足情報 !!!! WebClientからのUploadにはClientPluginのInstallが必要になります。 環境によってはClientPluginが正常に動作せずUploadが行えない場合があります。 その場合は、WebClientからUploadフォルダを作成したのち、WinSCPなどのソフトウェアを使用して、ESXiに接続し、作成したフォルダにファイルを転送してください VDPにISOファイルをマウント Power On済みのVDPに先ほどUploadしたISOファイルをマウントしてください。 vSphere WebClientの右クリックからEdit Settingを選び、下図を参考にISOファイルをマウントしてください。 ※必ずConnectedのチェックボックスにCheckを入れてください。そうしないとマウントされません VDPのサービスヘルスチェック～ISOファイルのマウントを確認 https://<IP_address_VDP_appliance>:8543/vdp-configure/ にアクセスして、Configurationタブですべてのサービスが正常に稼働していることを確認してください。 サービスの正常動作を確認したら、次はUpgradeタブへ移動してください。 ISOマウントが正しくマウントされ、自動の解凍処理が完了すると実施可能なUpgradeとして表示されます。 ISOのマウント～解凍～Upgradeの表示までは20分以上かかることがあります。 無事にファイルの解凍とチェックが完了し、Upgrade可能な状態になると以下のように表示されます。 Part 2ではUpgrade VDPボタンを押下して、実際のUpgradeフェーズのご紹介をさせていただきます。

VxRailで使用されいているPowerEdgeにおいて、"簡易放電"といった作業を実施する場合がございます。 この記事では、"簡易放電"の作業手順について記載します。 簡易放電の実行を検討するケース 以下事象に見舞われた際、簡易放電を実行する事で改善できる場合があります。    - iDRAC* GUIの調子が悪い(loginできない、画面loadに時間がかかる、一部ハードウェア情報が取得出来ない 等)    - しばらく起動していなかったNodeを立ち上げるも、正常に起動完了しない    - しばらく稼働し続けているNodeでFirmwareの更新を実施すると、失敗する    - 上記事象に伴い、 VxRail: iDRACリセット手順 の作業を実施しても改善が見られない     * iDRAC(integrated Dell Remote Access Controller)とは  :         VxRail Dell PowerEdge Modelにおけるハードウェア監視(BMC)の役割を担う機能の名称です。 簡易放電の手順 簡易放電は下記の4 Stepで実施します 対象ノードをメンテナンスモードにした上でシステムをシャットダウンします システム本体から電源ケーブル抜きます 電源ボタンを10秒以上長押しします 数分ほどあけて電源ケーブルを再度接続しシステムを起動します 必要に応じて以下動画をご参考下さい。     仮想簡易放電の手順(14G Modelのみ) 14G Modelでは、仮想簡易放電という機能が利用できます。 簡易放電 は実機を触る必要がありましたが、 本機能はiDRAC GUI経由で実施可能です。 ESXiホストの再起動が伴いますので、事前に問題ない状態(メンテナンスモード)に移行し実行して下さい。   参考：VxRail:nodeの停止/起動(メンテナンスモードの終了) 手順 なお、仮想簡易放電でも状況の改善が見られない場合は簡易放電の実行をご検討下さい。 1.  ブラウザに[https:// DRACのIPアドレス] を入力し、iDRACにアクセスします(defaultはroot/calvin) 2.[設定]タブ > [BIOS設定]タブを選択 3.[Miscellaneous Settings] > [Powercycle Request]欄で"Full Power Cycle"を選択し、    [適用] をクリックした後に[適用して再起動]を実行してください。 4.サーバーの再起動が開始します。そのままお待ちください。 5.しばらくすると、自動でLifecycle Controllerの画面に遷移して 仮想簡易放電のタスクが実行されます。    タスクが実行されると、2~3分ほど iDRAC GUIや仮想コンソールの接続が失われます。   6. iDRAC GUIへのアクセスが復調しましたら、仮想コンソールなどからESXiが正常に起動完了する事をご確認下さい。 ※Generation(世代)について※ Dell PowerEdge サーバー ベースで提供されるVxRail Modelでは、 特定のModel範囲を意味する「世代」という単語によってマシンを判別する事があります。 VxRail では以下世代区分となります。 14G(iDRAC9) E560/F V570/F P570/F S570 G560 13G(iDRAC8) E460/F V470/F P470/F S470