• Windows を NFS サーバーとして利用した際のNFS Cookie について

    こんにちは。 Windows プラットフォーム サポートの松田です。

    今回は Windows の NFS サーバーで利用される NFS Cookie についてお話しします。

    NFS Cookie とは、NFS サーバーと NFS クライアント間の通信において、ディレクトリの個々のファイル エントリーに対して NFS サーバー側で割り振る値です。
    NFS version 3 では、以下の RFC に記載されているとおり 64 bit Cookie が主に利用されます。

    NFS Version 3 Protocol Specification
    http://www.ietf.org/rfc/rfc1813.txt

    READDIR
    The READDIR arguments now include a verifier to allow the server to validate the cookie. The cookie is now a 64 bit unsigned integer instead of the 4 byte array which was used in the NFS version 2 protocol. This will help to reduce interoperability problems.

    しかしながら、Windows で利用される NFS サーバーでは、64 bit Cookie に対応できないクライアント アプリケーションを考慮して、既定では NFS Version 3 であっても 32 bit Cookie が利用されます。
    (Windows Server 2012 からは既定で 64 bit Cookie が利用されます)

    一方、Windows の NTFS ファイル システム上では、それぞれのファイルは 64 bit 長の NTFS FileID という一意な値で管理されています。
    32 bit Cookie ではこの NTFS FileID を利用して 32 bit Cookie が生成されますので、稀に同じ値の Cookie が異なるファイル エントリーに対して作成されてしまい、NFS クライアントで無限ループや、意図しない動作などが発生する場合があります。

    その場合には、以下のサポート技術情報を参照し FileCookieV3Size の値を 4 に変更し、64 bit Cookie を使用するように構成して下さい。

    FIX: You receive an error message and a client computer may stop responding when you try to run the ls command to list files or subdirectories on a large directory in Windows Services for UNIX 2.3
    http://support.microsoft.com/kb/910609/en-us

    上記の資料に記載されている FileCookieV3Size レジストリは、Windows Server 2012 まで同様に有効です。

    また、一緒に記載されている DisableFilenameHashing については32 bit Cookie の生成時に既定で利用されるファイル名のハッシュ情報を含んだ算出方法を無効化するレジストリです。

    DisableFilenameHashing  のレジストリを変更することで、32 bit Cookie の内部算出方法が変更されますので、これにより 32 bit Cookie の重複を回避できる可能性があります。
    ただし、本レジストリは Windows Server 2003 R2 までは利用可能ですが、Windows Server 2008 については以下のサポート技術情報で公開されている修正プログラムを適用し、DisableFilenameHashing  を設定可能な状態に変更する必要があります。
    (Windows Server 2008 R2 以降では DisableFilenameHashing による 32 bit Cookie 生成方法の変更はできません)
    また、Cookie の生成に際して NTFS FileID のみが使用されるようになるため、同一 FileID を持つ、ハード リンクされたファイル同士が同一の Cookie を持つようになる点を考慮する必要もあります。

    Can't perform a file operation from a UNIX client to a Windows Server 2008-based NFS server
    http://support.microsoft.com/kb/2813363/en-us

    NFS Version 3 が利用される環境で、NFS クライアントが 64 bit Cookie に対応している場合には、64 bit Cookie を利用していただくのが推奨される構成となりますので、NFS 通信において無限ループが発生するような場合には64 bit Cookie の利用について是非ご検討ください。

  • クイック マイグレーションをすると仮想スイッチが「構成エラー」になる(Windows Server 2012)

    こんにちは。Windows プラットフォーム サポートの戸田です。


    Windows Server 2012 フェールオーバー クラスター + Hyper-V の環境で、仮想マシンのクイック マイグレーションを行った後に仮想スイッチが「構成エラー」と表示される件について説明します。

     

    この記事でご案内する現象は、仮想マシン リソースを停止した状態でクイック マイグレーション (仮想マシンのオーナー ノードの変更操作) を行った後、マイグレーション先のターゲット ノードで仮想マシンの設定画面を表示することで確認することができますが、他にイベント ログやエラー ダイアログなどは表示されません。また、この状態で仮想マシンを起動すると「構成エラー」だった表示は正しい仮想スイッチの設定に更新され、起動後の仮想マシン(ゲスト OS )は正常に動作します。

    また仮想マシンがオンライン状態で行われるマイグレーション処理ではこの表示は表面化することはなく、影響もありません。

     

     

    なお、Windows Server 2008 R2 までのフェールオーバー クラスター + Hyper-V 構成ではこの表示は発生しません。

    結論から申し上げますと、この表示は Windows Server 2012 に含まれる Hyper-V のデザイン変更によるものであり、この「構成エラー」は無視していただいて問題ありません。

     

    この動作について

    Windows Server 2012 ではクイック マイグレーションによってターゲット ノードに仮想マシンが移動した際のリソース (ネットワーク デバイスなど) の修正は仮想マシンのワーカー プロセス (vmwp.exe) の起動時に、動的に仮想マザーボードの Power On 処理内で実行するよう変更されました。そのため、仮想マシンの起動のタイミングで正しい値に更新が行われる動作となります。

    Windows Server 2008 R2 ではクイック マイグレーション時に仮想マシン管理サービス (vmms.exe) が仮想マシン構成リソースのオンライン処理の延長でターゲット ノード側の仮想スイッチ/ポート情報に適用させるよう構成ファイルの修正を行っていました。そのため、仮想マシンを起動する前のタイミングで既に構成情報は更新済みとなっています。

    Windows Server 2012 からは仮想マシンのワーカー プロセス (vmwp.exe) が起動時に変更を行うため、上記のようにオフライン状態で クイック マイグレーションを行いターゲット ノードに移動した場合、このタイミングではまだ仮想マシン プロセスは起動していないため、仮想スイッチ/ポート情報の変更が行われておらず構成情報上は「構成エラー」という形で見えてしまうようになります。この動作の違いは仮想マシン内のリソースの管理を仮想マシン管理サービス (vmms.exe) ではなく、仮想マシンのワーカー プロセス (vmwp.exe) が個別にすべての権限持って行うよう、Windows Server 2012 の仕様として変更されたことに起因しています。

    上記の通り、Windows Server 2012 ではクイック マイグレーション後に仮想マシンのワーカー プロセス (vmwp.exe) が起動するタイミングで初めて構成ファイルからターゲットホスト側の仮想スイッチを検索し、検出できれば仮想 NIC の割り当てが行われます。そして、その構成変更処理の延長で構成情報が正しい内容へ修正されます。そのため、仮想マシンの起動前のタイミングで表示される「構成エラー」は無視していただいて問題ありません。

     

     

  • "デバイスとプリンター" 画面の不思議に迫る

    こんにちは。

    Windows サポートの丸山です。

    本日は、Windows 7 から新しく追加された "デバイスとプリンター" 画面で発生する現象についてお話しします。

    弊社では、"デバイスとプリンター" 画面からプリンターの追加を行っても、追加したプリンターが表示されないことがある。といったお問い合わせをいただくことがあります。

    この動作は、Windows 7 からの "デバイスとプリンター" 画面に実装された、多機能デバイス サポートのためのデバイス コンテナーのグループ化機能によるものです。

    "デバイスとプリンター" 画面では、プリンターとスキャナー機能を併せ持った複合機など、複数の機能を持った多機能デバイスをより直感的に表示するために、ContainerID と呼ばれるデバイスのパラメーターを参照し、同じ物理デバイスであると認識されるデバイスをグループ化して表示します。

    また、このとき、プラグ アンド プレイ経由でのパラメーター取得が行われないローカル プリンターでは、同じプリンター ドライバー、同じポート (LPT1: など) を指定してプリンターのインストールを行った場合に、それらのプリンターはすべて同一の ContainerID が割り当てられる動作であることがわかっています。

    たとえば、"MS Publisher Color Printer" というプリンター ドライバーを使用して、"MS Publisher Color Printer 1" というプリンターと、"MS Publisher Color Printer 2" という 2 つのプリンターを追加する例を見てみましょう。

    プリンターを作成し、"デバイスとプリンター" 画面を開きますと、次のような画面になります。

    デバイス コンテナーがグループ化されているため、プリンターのアイコンはひとつしか表示されておりません。

    ここでは、グループ化されたアイコンを右クリックして、オプションを選択すると、すべてのプリンターを見つけることができます。

    また、グループ化されたアイコンの名前は、グループ化されているプリンターの中から、どれかひとつの名前が表示されています。

     

    - プリンターのグループ化が好ましくない場合には

    なんらかの理由があり、複数のプリンターがグループ化されて表示されてしまうことが好ましくない場合には、次の手順を参考に、デスクトップ上にカスタム フォルダーを作成することを検討してください。

    1. 管理者権限を持ったユーザーにて、レジストリ エディターを開きます。

    2. 以下のレジストリ キーを展開し、選択します。

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace

    3. "NameSpace" レジストリ キーを右クリックして '新しいキー' をクリックします。

    4. 次の通り、新しいレジストリ キーの名前を入力してください。

    {2227a280-3aea-1069-a2de-08002b30309d}
    ※角かっこはそのまま含めるようにしてください。

    5. 右側のウィンドウでレジストリ値 (既定) を右クリックし、"修正" をクリックします。

    6. 次の通り、新しい値を入力してください。

    プリンター
    ※値を設定後の画面はこのようになります。

    7. レジストリ エディターを終了します。

    8. デスクトップ上を右クリックし、[更新] をクリックします。

    以上の手順を実行しますと、デスクトップ上に 'プリンター' と呼ばれる新しいアイコンが表示されます。

    新しいアイコンをダブルクリックして開きますと、従来通り、すべてのプリンターが個別に表示され、印刷キューの管理などを実施することができます。

    ※レジストリに関する注意事項

    レジストリの直接編集により誤った設定を行った場合、システムが起動しなくなるなどの重大な問題を引き起こす可能性があります。
    レジストリを直接編集する場合は、検証環境で事前に手順を確認するか、システムのバックアップをあらかじめ作成しておくなど、十分な配慮をお願いします。

     

    - プリンターの ContainerID について

    弊社では、ローカルプリンターを作成する際に、以下の要因によってプリンターの ContainerID が作成されることを確認しております。

    • 同じプリンター ドライバーが使用されている
    • 同じポートが割り当てられている
    • HardwareID が同一である

    なお、ネットワーク共有プリンターへの接続を行い、表示されているプリンターには、それぞれ個別の ContainerID が割り当てられることを確認しております。

     

    - 参考情報

    下記資料はハードウェア開発者向けの資料ですが、Windows 7 からの新しいデバイス エクスペリエンスについて記載されています。ご興味があれば参照してみてください。

    Windows デバイス エクスペリエンス
    http://msdn.microsoft.com/ja-jp/library/windows/hardware/br259107.aspx

    こちらもハードウェア開発者向けの資料ですが、デバイス コンテナーのグループ化について詳しく記述されています。

    多機能デバイス サポートとデバイス コンテナーのグループ化
    http://msdn.microsoft.com/ja-jp/library/windows/hardware/gg463141.aspx

    また、このブログ記事は、以下のブログ記事、技術情報を参考に記述しています。

    Windows 7: Where are my printers?
    http://blogs.technet.com/b/askperf/archive/2010/03/02/windows-7-where-are-my-printers.aspx

    Printers installed using the same driver and port on Windows are grouped as one when viewed within Devices and Printers
    http://support.microsoft.com/kb/2015694

    まだまだ暑い日が続きます。
    おからだにはお気を付けてお過ごしください。

    Windows プラットフォーム サポート担当
    けまるや