皆様、
表題の件ですが、現在仮想ディスクをRawデバイスマッピングに変換する際の手順及び影響を確認しております。
仮想ディスクを物理互換モードRDMに変換する手順としては、以下リンク先KBにも公開されており、問題のない手順のように見受けられます。
但し読み進める中で、以下の2点の疑問が生じました。
①ゲストOS側からでは仮想デバイスノードを全く同じ番号を割り当てることで、全く同じ状態に見えるのでしょうか。
VGの再設定等が不要であることを確認したいという意図です。
②上記で全く同じ状態に見える理由は、仮想ディスクの場合もRDMへのアクセスの場合もゲストOSから見るとVMFSにアクセスする形となるため。
参考文献は古いですが、以下をもとに考えております。
[ThinkIT] 第2回:仮想化環境の設計と物理サーバから仮想マシンへの移行方法 (3/4)
RDMは、VMFS上にマップファイルを作成し、それを参照して実データにアクセスする。UNIXなどのシンボリックリンクファイルに近いイメージである。つまり、仮想マシンから見るとVMFSにアクセスする形となるが、ストレージ側はRawディスクとして認識されている。
ご経験のある方がいらっしゃいましたらご教授ください。
よろしくお願いいたします。
ご確認頂いているKBのタイトルは仮想ディスクをRawデバイスマッピングに変換と
なっていますが、実際には"変換"ではなく"コピーの作成"と言うところでしょうか。
既存の仮想ディスクの中身がそのまま保持されたRDMのディスクが作成されます。
公式情報ではないですが、以下サイトの説明がわかりやすそうですね。
VMDKの仮想ディスクをRDM(Raw Device Mapping )に変換 | 仮想(VMware & Hyper-V)/クラウド・エンジニア技術ブログ
①のご質問については、上述のとおり仮想ディスクのコピー先となるLUNをESXiが
認識している必要があるので、そのLUN作成のためのストレージ側作業は必要です。
(すみません、VG が何を指しているのか明確に読み取れなかったので、的外れなことを言っているかもしれないです。。。)
②のご質問ついては、RDMにはマッピングファイルがあり、これはVMFSのデータストア上に存在します。
ただし、ゲストOSのディスクI/OはRDMとしてマッピングされた先のデバイスに行われるため
VMFSにアクセスするという表現は少し違うような気もします。。。
ご確認頂いているKBのタイトルは仮想ディスクをRawデバイスマッピングに変換と
なっていますが、実際には"変換"ではなく"コピーの作成"と言うところでしょうか。
既存の仮想ディスクの中身がそのまま保持されたRDMのディスクが作成されます。
公式情報ではないですが、以下サイトの説明がわかりやすそうですね。
VMDKの仮想ディスクをRDM(Raw Device Mapping )に変換 | 仮想(VMware & Hyper-V)/クラウド・エンジニア技術ブログ
①のご質問については、上述のとおり仮想ディスクのコピー先となるLUNをESXiが
認識している必要があるので、そのLUN作成のためのストレージ側作業は必要です。
(すみません、VG が何を指しているのか明確に読み取れなかったので、的外れなことを言っているかもしれないです。。。)
②のご質問ついては、RDMにはマッピングファイルがあり、これはVMFSのデータストア上に存在します。
ただし、ゲストOSのディスクI/OはRDMとしてマッピングされた先のデバイスに行われるため
VMFSにアクセスするという表現は少し違うような気もします。。。
こんにちは。
以前にゲストOSからRDMがどう見えるか試してみたことがあるので、参考になるか微妙ですがお伝えしておこうと思います。
また、RDM のディスクをどのように使用する想定なのか、
(RDMディスクを使用するアプリケーションが何なのか、クラスタソフトなどで共有するのか、など)
ゲストではどう扱っているのか (LVM利用か、Rawデバイスのままか、ファイルシステム作成するのか、など)
といったような情報があると、さらにヒントが得られるかもしれません。
negi_c様、
ご回答ありがとうございます。ご提示いただいたリンクは有益でした。
試してみた結果、データロス等もなくコピー&変換ができました。
LVMで作成していたPV, VG, LV等もタイムスタンプ・UUID変わることなくOSから認識できているようです。