SCVMM2012+XenServerでのXenMotion(XenServerにおけるLiveMigration)の検証も、と突然思い立ち、色々と整理してXenServer用H/Wが2台確保できたので、SCVMM2012+XenServer×2で検証を進めたいと思います。

その前段として、XenServerでのXenMotion環境を作る為には、共有Diskが必要です。まずは、共有Diskの準備から始めたいと思います。

共有Diskといっても、Hyper-Vと異なりブロックデバイス(iSCSIやFiberChannel etc)の共有Diskではなく、UNIXではスタンダードなファイル共有の仕組みであるNFS(Network File System)でOKなので楽チンです。

手近のUNIXマシンは……Microsoft信者の家にはUNIX/Linuxなどあろうはずもありません。玄箱(Debian)が転がってるだけなので、それを使うにはパフォーマンスがちょいと不安。

そこでもう一台のサーバー(Windows Server 2008 R2 Ent)にNFS(Network File System)用サービスを入れて、NFSサーバーとして使う事にしました。

NFS(Network File System)用サービスの概要に関しては、解説サイトが山のようにあると思いますのでここでは割愛します。

Windows Server 2008とR2のNFSサービスを比較すると、R2からユーザー名マッピングのサーバー機能がなくなった模様(ヘルプ『NFSサービスの概要』にも書いてありました)。これを探して結構右往左往していたので、R2のNFSサービスを利用する際には注意してください。

NFSサービスの設定方法に関しても、解説サイトが山のようにあるので細かいところは割愛しますが、設定上、引っかかったところだけ記載します。

まず、NFS共有の設定。

NFS共有を設定する上で避けて通れないのが『NFS認証』と『アクセス許可』。この辺がちょっと嵌りました。

● NFS認証

最終的には、以下の設定で落ち着きました。以上(マテ)

この設定に落ち着く(上手くXenServer側からマウントできるようになる)まで、紆余曲折がありました。その原因がユーザー名マッピングのサーバー機能がなくなった事なのですが……。

実際、NFSマウントした状態のXenServerのコンソールが↓。

ご覧の通り、XenServerはroot/rootでファイルを書き込むので、rootユーザーとWindows側のユーザーをマッピングしないと、

1)マップされていないユーザーからもアクセスできてしまう

2)NTFSのアクセス権をEveryone FullControlなどという恐ろしい設定をしなければならない?

と嫌な感じもしたのですが、ネタばらしをすると、そんな事は杞憂でした(ぎゃふん)。詳細は後程。

まぁ、そんなわけでrootユーザーとAdministratorをユーザーマッピングする方法を色々と探していたのですが、

1)ユーザー名マッピングのサーバー機能がR2からなくなった

2)ADから引っ張ってくる事もできるが、スキーマの拡張が必要

3)スキーマ拡張がイヤなら、2008(not R2)のNFS用サービスでユーザー名マッピングのサーバー機能を利用してマッピング

4)UNIXのNISを使う

などというとてもとても手間のかかる方法しかなさそうなので、全て却下。検証環境だからいいやと妥協をしまして上記設定に落ち着いた次第です。

匿名アクセスですが、この設定をした場合にはXenServerからNFSマウントできなかったので、匿名アクセス無効で正解なのではなかろうかと思います。

●アクセス許可

アクセス許可には『NFSアクセス許可』と『NTFSアクセス許可』の二つがあります。

まず、『NFSアクセス許可』。

デフォルトだとALL MACHINE-読み取り専用の設定になっています。これだと全てのNFSクライアントからRead Onlyとはいえアクセスできてしまうので却下。

XenServer2台からアクセスできればいいだけなので、以下のような設定にしました。

UNIX/Linuxでいうところの/etc/exportsの設定ですね。

ホスト単位でアクセスを許可し、ALL MACHINEは『許可しない』としました。

あと、前述の通り、XenServerのNFSアクセスはrootユーザーで行われる為、『ルートアクセスを許可する(推奨しません)』にチェックを入れ、rootユーザーでのアクセスを許可してあげる必要があります。推奨しない、といわれてもねぇ……。

続いて『NTFSアクセス権』。これで数時間嵌りました。

rootユーザーでファイルアクセスを行うので、rootユーザーをマッピングしたWindowsユーザーアカウントに対してアクセス権を設定すればいいと思っていたのですが、前述の通りマッピングができない状態に……。

仕方ないので、Everyone FullControlの驚異のアクセス権を設定し、動作確認。

NFS経由でアクセスできる事を確認し、NFS経由で作成したフォルダ及びファイルのアクセス権を確認してみました。

あれ? Everyoneじゃなくてもいけそう??

↑NFS経由で作成したフォルダのアクセス権

↑NFS経由で作成したファイルのアクセス権

親フォルダはEveryoneしか権限を与えていないので、明らかにフォルダ/ファイルを作成したタイミングで権限を再割り当てしています。

WindowsユーザーアカウントはホストのLocal AdminとSYSTEMのみ。その他は……『S-1-5-88』?? なんでしょう、これ? Well Known SIDかとも思いましたが、ググってもヒットせず……。NFSサービス経由で書き込んだ際のSIDかもしれないので、とりあえず放置。

仮説として、NFSサービスがLocal Adminでファイルを作成した後にSIDを張り替えているのでは?

という事で、『NTFSアクセス権』をLocal Admin FullControlのみ設定し、再度NFSアクセステストを実施してみました。

結果としては、前述の通り問題なくNFS経由でアクセスできました。

 

そんなこんなで、ある程度実運用にも耐えられるかもしれない? アクセス権が設定できました。まぁ、XenServerからのNFS経由書込みは、どのユーザーでも書き込めてしまうかもしれませんが、それはそれで良しとしましょう……(実際NFSなんてそんなもんですし)。

次回はXenServer×2によるXenMotionが可能な構成の構築を行ってみたいと思います。当然、SCVMM2012からXenMotionが可能かも確認予定です。