これは、vSphereアップグレードガイドch 12(添付)から抜粋したものです。
「ESX/ESXiのアップグレード後、LUNマスキングをクレームルール形式に変換する必要があります。これを行うには、vSphereコマンドラインインターフェイスでesxcli corestorageclaimruleconvertコマンドを実行します。このコマンドは/ adv/Disk/MaskLUNsの詳細構成を変換します。プラグインとしてMASK_PATHを使用してルールを要求するには、esx.confにエントリを入力します。 『vSphere Command-Line Interface Installation and Reference Guide』を参照してください。
ISCSISANがあります。それで、私たちは本当にこれをする必要がありますか?もしそうなら、どのように?そして、これを行わないとどうなりますか?
これは、ESXホストレベルでLUNマスキングを実装していない限り、実行する必要のあることではありません。これは比較的一般的ではない手法です。LUNプレゼンテーションはアレイレベルで処理する必要があり、私の経験ではほとんどの場合そうです。なぜiSCSI環境で使用されるのかわかりませんが、それを必要とする奇妙なハードウェアが存在する可能性があります。懸念がある場合は、アップグレードする前に、ホストでLUNマスキングが構成されているかどうかを確認してください。
リスクは、SANがLUN\Volumeのすべてまたは一部を制御されていない方法で提示し、ホストが実際に実行するボリュームを選択することに依存している環境がある可能性があることです。たとえば、技術的にWindowsホストに属するNTFSボリュームがESXホストにも表示されるシナリオがある場合は、LUNマスキングを使用して、ESXホストがそのボリュームを破損するのを防ぐことができます。これはかなり脆弱なセットアップです。そしてそれが一般的に避けられる理由です。
これを行う必要がある場合でも、VMAを使用する必要があるという意味ではありません。 vSphereCLIをWindowsXP\2K3\2K8-64\VistaおよびRHEL5.1、SLES 10\11、Ubuntu 9.04にインストールして、古いESXのサービスコンソールで直接実行する必要のあるほとんどのコマンドにアクセスできるようにすることができます。バージョン。 VMAは、vSphere CLIなどを含む、完全に自己完結型で事前構成されたCentOS仮想アプライアンスであるため便利です。 JakeRobinsonが指摘したように、ESX4.1のBusyboxCLIはESXCLIコマンドをサポートしているため使用できます。そのため、これを行う必要がある場合でも、実際には何もインストールする必要はありません。
2000を超える3.5ホストをすべてFCで4に変換しましたが、それを行う必要はまったくありませんでした。