これは、Vsphere アップグレード ガイドの第 12 章 (添付) から抜粋したものです。
「ESX/ESXi のアップグレード後、LUN マスキングをクレーム ルール形式に変換する必要があります。これを行うには、vSphere コマンドライン インターフェイスで esxcli corestorage claimrule convert コマンドを実行します。このコマンドは、esx.conf の /adv/Disk/MaskLUNs の詳細構成エントリを、プラグインとして MASK_PATH を使用したクレーム ルールに変換します。『vSphere コマンドライン インターフェイスのインストールおよびリファレンス ガイド』を参照してください。」
iSCSI SAN があります。では、これを本当に行う必要があるのでしょうか? 必要な場合、どのように行うのでしょうか? また、これを行わないとどうなるのでしょうか?
答え1
これは、ESX ホスト レベルで LUN マスキングを実装していない限り、実行する必要はありません。これは比較的珍しい手法です。LUN プレゼンテーションはアレイ レベルで処理する必要があり、私の経験ではほぼ常にそうなっています。なぜこれが iSCSI 環境で使用されるのかわかりませんが、これを必要とする奇妙なハードウェアがある可能性があります。心配な場合は、アップグレードする前に、ホストで LUN マスキングが構成されているかどうかを確認してください。
リスクは、SAN が LUN やボリュームのすべてまたは一部を制御されない方法で提示し、ホストが実際にやり取りするボリュームを選択することに依存する環境になる可能性があることです。たとえば、技術的には Windows ホストに属する NTFS ボリュームが ESX ホストにも表示されるシナリオでは、LUN マスキングを使用して、ESX ホストがそのボリュームを破損するのを防ぐことができます。これはかなり脆弱な設定であるため、通常は避けられます。
これを行う必要がある場合でも、VMA を使用する必要があるわけではありません。vSphere CLI は、Windows XP\2K3\2K8-64\Vista および RHEL 5.1、SLES 10\11、Ubuntu 9.04 にインストールでき、古い ESX バージョンではサービス コンソールで直接実行する必要のあるほとんどのコマンドにアクセスできます。VMA は、vSphere CLI などを含む、完全に自己完結型で事前構成された CentOS 仮想アプライアンスであるため便利です。JakeRobinson が指摘したように、ESX 4.1 の Busybox CLI は ESXCLI コマンドをサポートしているため使用できます。そのため、これを行う必要がある場合は、実際に他に何かをインストールする必要はありません。
答え2
答え3
私たちは 2000 台を超える 3.5 ホストをすべて FC 上で 4 に変換しましたが、その作業はまったく必要ありませんでした。