8. FAQ

8.1. どうすれば自分の環境から起動中の仮想マシンにsshで接続できますか?

作成したマシンにグローバルIPアドレスを割り当て(DNAT設定)、さらに割り当てたアドレスに対して通信の許可設定(ACL設定)をする必要があります。
詳細は、こちら をご確認ください。

なお、本設定はセキュリティに関わる重要な設定です。利用者の責任において各設定を行ってください。

8.2. デスクトップと仮想マシン間でファイルのやり取りを行うためにはどうすればいいですか?

ご自身の環境から仮想マシンへSSHできることをご確認いただいた後、SCPコマンドなどでファイル転送を行ってください。
Windowsの場合、WinSCPなども利用可能です。

8.3. 高速内部ストレージ、大容量ストレージの利用可能な容量はどこで確認できますか?

高速内部ストレージ、大容量ストレージの利用可能な容量を確認する をご確認ください。

8.4. dfで高速内部ストレージ、大容量ストレージの使用量/上限値を確認しましたが、正しく表示されていません。

高速内部ストレージ、大容量ストレージは、ファイルシステムとしてlustreを採用しています。
よって、dfでは個人の利用可能なディスク容量は確認できません。

確認方法については、高速内部ストレージ、大容量ストレージの利用可能な容量を確認する をご確認ください。

8.5. 仮想マシンをcloneした際に、clone元とclone先に同じIPアドレスが割り当たってしまうのはなぜでしょうか?

一般的に、machine-idが変わらないと、同じIPアドレスが割り当たります。

cloneした際に、machine-idもコピーされるので、その結果、同じIPアドレスが割り当てられてしまうことがあります。
cloneする場合は、以下の手順で実施する必要があります。

cloneの手順

  1. clone元の /etc/machine-id を空にする

  2. clone元をシャットダウン

  3. clone実行

なお、本操作を自動で行う機能については、実装方式を検討しています。機能が実装されるまでは、手動での対応をお願いいたします。

8.6. 仮想マシンに静的IPアドレスを設定したいのですが、どのようなアドレスを指定すればよいでしょうか?

仮想マシンに設定されているセグメントに対して提供されているIPアドレス範囲のうち、
ホストアドレスが1~100の範囲のIPアドレスを指定してください。
  • 仮想マシンに設定されているセグメントは、上部メニュー[仮想マシン]をクリックしてメイン画面に表示される仮想マシンの一覧から
    任意の仮想マシンを選択し、右のサマリ情報内サービスネットワーク>セグメントより確認できます。
  • セグメントに割り振られるIPアドレスの範囲は、上部メニュー[ネットワーク]をクリックしてメイン画面に表示されるセグメントの一覧から
    上記で確認したセグメントを選択し、右に表示されるIPアドレス範囲から確認します。
例) IPアドレス範囲に「10.12.123.0/21」と記載されていた場合、
  IPアドレスは「10.12.123.1」~「10.12.123.100」で指定します。

8.7. 仮想マシンに設定した公開鍵を修正したい場合はどうすればいいですか?

仮想マシンのデプロイ時に設定する公開鍵は後から修正することができません。
公開鍵の修正が必要な場合には、再度仮想マシンのデプロイから実施してください。

8.8. DNAT、ACLで何を設定したらよいのか分かりません。

ご利用のネットワークによって設定すべき値が変わります。
ここでは一例を説明しますが、ご自身のネットワーク環境の詳細については、ご自身のネットワークの管理者にご確認ください。
仮想マシンをデプロイした場合、デフォルトで「mdxローカルIPアドレス」が割り当てられます。
外部(インターネット)から、仮想マシンにアクセスする際、DNAT設定によって「mdxローカルIPアドレス」を「mdx側のグローバルIPアドレス」に
紐づける必要があります。
「mdxローカルIPアドレス」は、仮想マシンのコントロール画面の右側で確認できます。
デフォルトでは、サービスネットワーク1のIPv4もしくは、IPv6がその値になります。
「mdx側のグローバルIPアドレス」は、プロジェクト申請時の申請値に基づき、予めプロジェクトに割り当てられます。
DNAT設定画面で、以下の値を設定する必要があります。
転送元グローバルIPv4アドレス:「mdx側のグローバルIPアドレス」
セグメント:デフォルトでは変更する必要ありません。
転送先プライベートIPアドレス:「mdxローカルIPアドレス」
DNAT設定によって、グローバルIPアドレスで、仮想マシンにアクセスできるようになりました。
しかし、ACL設定をしない限りは、このグローバルIPアドレスにはアクセスできません。
安全のため、初期状態ではDNATで設定したグローバルIPアドレスには一切の通信を受け付けない設定がなされています。
そこで、ACLを正しく設定し、通信を許可する設定をする必要があります。この設定を誤ると、仮想マシンへの攻撃、侵入などの
セキュリティ被害を受けることになります。必要最低限の通信を許可するように心がけてください。
作成した仮想マシンに、例えばsshしたい場合は、ACL設定画面で以下の値を設定する必要があります。
プロトコル:TCP
Srcアドレス:ご利用のネットワークのIPアドレス、「利用者側のグローバルIPアドレス」を入力してください。
これが分からない場合、ご自身のネットワークの管理者にご確認ください。
SrcPrefix長:サブネットマスクのことを表しています。255.255.255.0の場合は、24になります。
Srcアドレス同様、これが分からない場合、ご自身のネットワークの管理者にご確認ください。
Srcポート:anyをご指定ください。
Dstアドレス:ここには、「mdxローカルIPアドレス」を設定します。「mdx側のグローバルIPアドレス」ではないのでご注意ください。
DstPrefix長:仮想マシンが1台ならば32になります。複数台ある場合は、DstアドレスとDstPrefix長でネットワークを指定するか、
それぞれACLを書くなどしてください。
Dstポート:sshはデフォルトでは22番ポートを使用します。意図的に変えていない限りは22番をご指定ください。
繰り返しになりますが、ACL設定はセキュリティに関わる重要な設定項目です。各利用者のセキュリティ管理は利用者の自己責任となります。
設定の影響を理解した上で十分ご注意の上設定いただくようお願いします。

8.9. 短期間に大量の資源量が必要な場合はどう対処すればよいでしょうか。

短期間(1週間など)、大量の資源量(16GPUなど)が必要な場合は、予め mdx-helpメールアドレス(mdx-help@mdx.jp) に、以下の情報を送ってください。
・プロジェクト名、
・利用期間(2022/01/01 - 2022/01/07)、
・必要な資源量(例:16GPU)、
・使用理由(例:深層学習の学習に大量のGPUが必要なため)
この情報を元に、資源情報の状況を加味して、承認するかどうか判断致します。上記のメールと共に、ポータル上から資源量の変更をお願いします。
プロジェクト利用期間は変更できませんので、上記、短期間で承認された期間が過ぎたら、ご自身で資源量のを元の申請値にお戻しください。

8.10. IPアドレスが長く待っても割り当たりません。割り当たっていたものが突然無くなってしまいました。

一般的に原因として大きく2つ考えられます。
1. システム障害で、何らかの理由でIPアドレスが払い出せなくなっている可能性
この場合は、特定の仮想マシンだけではなく全体で問題が発生している場合が多いです。
ほかの仮想マシンでも同様のIPアドレスが払い出されない・表示されていない事象が発生しているかご確認ください。
2. OSの問題で、IPアドレスが見えなくなっているの可能性
OSのネットワーク設定が不適切だったり、OSがハングアップしてしまっていたりすると、VMware Toolsが
正しく情報を取得できない状態となり、ポータル上でIPアドレスが確認できなくなります。
この場合、OSを再起動していただくか、ネットワークインタフェースの再起動をコンソールより行ってください。
もし、OSの問題でなかった場合は、お手数ですがお問い合わせください。お問い合わせの際、
OSの状態(アクセスできない、再起動直後か等)を付記いただくと、スムーズに調査が始められます。

8.11. 仮想マシンが不安定になりました。障害でしょうか。

一般的に仮想マシンが不安定になった場合、OSの問題である可能性が高いです。
以下のログをご確認ください。また、エラー等のログが確認できた場合は、復旧作業を行うなどの必要な対応を行ってください。
・/var/log/kern.log
・/var/log/syslog
・/var/log/kern.log
・/var/log/messages
・/var/log/dmesg
それでも解決しない場合、お手数ですがお問い合わせください。
なお、利用者が立ち上げた仮想マシンの動作環境 (OS の状態等) については mdx 管理者から確認できない事象も多くあり、
解決できない、解決までに時間を要する場合がありますので、予めご承知おき頂きますようお願いいたします。

8.12. 仮想マシンは起動したのですが、Lustre領域(/fast、/large)のマウントに失敗する場合は、どう対処すればよいでしょうか。

「uname -r」にてご確認いただき、指定のバージョン (「5.4.0-91-generic」) 以外の場合、
ofed 及び lustre のカーネルモジュールの再作成することで、この問題は解決できます。

以下の手順でカーネルモジュールの再作成を行い、lustre 領域が mount されるかご確認下さい。

  1. build された ofed モジュールをアンインストールする

    $ sudo dkms uninstall -m mlnx-ofed-kernel -v 5.1 -k $(uname -r)
    
  2. ofed モジュールのソースを削除

    $ sudo dkms remove -m mlnx-ofed-kernel -v 5.1 -k $(uname -r)
    
  3. ofed モジュールのソースをコンパイル

    $ sudo dkms build -m mlnx-ofed-kernel -v 5.1 -k $(uname -r)
    
  4. build されたofed モジュールをインストール

    $ sudo dkms install -m mlnx-ofed-kernel -v 5.1 -k $(uname -r)
    
  5. build された lustre_client モジュールをアンインストール

    $ sudo dkms uninstall -m lustre-client-modules -v 2.12.6-ddn13 -k $(uname -r)
    
  6. lustre_client モジュールのソースを削除

    $ sudo dkms remove -m lustre-client-modules -v 2.12.6-ddn13 -k $(uname -r)
    
  7. lustre_client モジュールのソースをコンパイル

    $ sudo dkms build -m lustre-client-modules -v 2.12.6-ddn13 -k $(uname -r)
    
  8. build されたlustre_client モジュールをインストール

    $ sudo dkms install -m lustre-client-modules -v 2.12.6-ddn13 -k $(uname -r)
    
  9. 仮想マシンの再起動

    $ sudo reboot
     ※1回の再起動で、立ち上がらない等ありました場合には、少し時間を空け数回再起動を行い状況を確認願います。
    

8.13. bucket全体をまとめて公開する方法を教えてください。

bucket 配下の公開/非公開をまとめて行う場合の手順は以下となります。

  1. 各bucket用のポリシーを作成する。

    ※bucketごとにポリシー用のファイルの準備をお願いします。

    ---記載例(ファイル名:bucket_list.json)---
    {
        "Version": "2008-10-17",  ←※変えないでください
        "Statement": [
          {
                "Sid": "bucket_list", ←※記載内容は任意
                "Effect": "Allow",
                "Principal": {
                       "DDN": ["*"]  ←※変えないでください
                },
                "Action": [
                        "s3:ListBucket",
                        "s3:GetObject"
                ],
                "Resource": "bucket_list" ←※公開するbucket名を指定
          }
        ]
    }
    ---ここまで---
    
  2. 作成したポリシーを対象のbuketに適用する。

    $ s3cmd --no-check-certificate setpolicy bucket_list.json s3://bucket_list
    
  3. オブジェクトが公開されていることを確認する。

    "https://s3ds.mdx.jp/bucket_list/<オブジェクト名>"

以上で公開設定完了。

※なお、非公開設定をする場合には、ポリシーのファイル内の「"Effect": "Allow"」を
 「"Effect": "Deny"」に変更し、再度2項目に上げたポリシーの適用を実施する。

8.14. 仮想マシンへsshログイン後、一定の時間が経過すると切断されてしまう。対応方法を教えてください。

mdxのファイヤーウォールでは、無通信のまま30分以上が経つと切断する設定となっています。

サーバあるいはクライアント側で無通信状態による接続断を防ぐための以下を参考に対応をお願いします。

  • Windows の場合、SSH クライアント (Putty、TeraTerm 等) で keep-alive 設定を行う。

  • サーバ側の sshd_config や ssh_config の設定 (ClientAliveInterval、ClientAliveCountMax)を行う。

8.15. ストレージネットワーク(PVRDMA)を利用した環境も ストレージネットワーク(SR-IOV)の環境と同様なRDMA によるノード間通信環境が構築可能ですか?

PVRDMA を利用した環境も RDMA と同等のノード間通信環境が構築可能です。
ただし、PVRDMA で構成した場合と、SR-IOV で構成した場合では以下の通りの機能の差があります。
  • PVRDMA (準仮想化RDMA):

    ノード間の RDMA 通信は可能。ただし、ストレージ (Lustre) は TCP 接続となります。

  • SR-IOV:

    ノード間、ストレージ (Lustre) も含め RDMA による通信となります。

PVRDMA ご利用の際にはストレージ (Lustre 領域) への通信種別に違いがあること、
PVRDMA は準仮想化 RDMA であることから、実際の RDMA 通信に比べ性能が劣るケースもございます。
その点をご留意頂き、PVRDMA 環境のご利用をご検討ください。

8.16. ISOイメージからOSをインストールする際にストレージを見つけられないエラーが発生しました

本システムでは、ポータルで仮想マシンを作成する場合に、
ハードディスク用のSCSIコントローラとして「VMware Paravirtual SCSI (PVSCSI) adapter」が使用されます。
OSが本アダプタに対応していない場合、インストール先を検出できません。
VMware Paravirtual SCSI (PVSCSI) adapterに対応したOSを利用することをご検討ください。

8.17. GPUパックを利用する仮想マシンの新規作成を行ったが、エラーとなり仮想マシンの作成に失敗する。

GPUパックを利用する仮想マシンの新規作成(デプロイ)時において、「No available ESXi found.」と出力され、 デプロイに失敗する。

仮想マシンは ESXi ホスト上で動作しますが、この ESXi ホストは (GPU の場合、物理ノードとしても) 8 GPU パックを使用する仮想マシンが最大となります。 また、運用仕様上、ESXi ホストは複数の利用者様の仮想マシンを同一 ESXi ホスト上で動作する場合があり、 GPUパック数を指定する数によっては、他の利用者様とリソースを分け合う運用となります。 そのため、GPUの空き資源の状況により、指定のGPUパック数を満たす環境が無く仮想マシンの作成失敗する 場合があります。

仮想マシンの作成に失敗した場合には、指定するGPU パック数について見直しを行い(元の指定数より減らす)、 改めて仮想マシンの新規作成(デプロイ)を実施にて確認をお願いします。

なお、一度に最大で利用可能な GPUパック数は、利用状況により変化するためご留意願います。

8.18. 仮想マシンのGPUパック数の変更(増加)を行ったが、エラーとなり増やすことができなかった

仮想マシンのGPUパック数の変更(増加)を行った際、操作履歴のメッセージにて
「Faild to execute action. Please contact your administrator.」と出力され、GPUパック数の増加が失敗する。
仮想マシンが動作している(割当たっている) ESXiホスト上に、他の利用者様が使用している仮想マシンが共存している場合があり、
他の利用者様仮想マシンが残りのGPUリソースを使用している場合、要求したGPUリソースを追加で割り当てることができない可能性があります。
仮想マシンの移動操作を行うことで、新たに割当たったESXiホストにてGPUを割り当て(増加)可能になる場合があるため、
以下の操作をお願いいたします。
なお、多数の利用者様がGPU資源を使用しており、全システムで提供できるGPU資源がひっ迫している状況であるため、
一つのESXiホストで複数個のGPUを利用した仮想マシンを作成(利用)する場合、GPU資源の確保ができない場合がありますことをご承知おきください。
仮想マシンの移動手順は以下です。
※仮想マシンの移動操作は、ユーザポータルより実施願います。
  1. ユーザポータル - 仮想マシン - コントロール の画面で対象の仮想マシンを選択します。

  2. 操作アイコンの「ACTION」で表示される一覧より、電源 - シャットダウン を実行します。

  3. 仮想マシン停止後、同じようにACTIONから、メンテナンス - GPU/SR-IOVのデタッチを実行します。

  4. デタッチ後、同じようにACTIONから、メンテナンス - 仮想マシンの移動 を実行します。

  5. 仮想マシンの移動処理完了後、再度、GPUパック数の変更を実施します。

  6. 仮想マシンを起動頂き利用可能となったことをご確認願います。

8.19. 仮想マシン上にて特定のGPUを使用すると「CUDA error: uncorrectable ECC error encountered」というメッセージが出力する。

仮想マシン上にて特定のGPUを使用した際「CUDA error: uncorrectable ECC error encountered」
というメッセージが出力した場合、以下の対処をお願いいたします。
  1. エラーカウントの確認のため、以下のコマンドを実行します。
    いずれかのGPUにて下記★印に示す値が"0"より大きい値になっているか確認します。
    # nvidia-smi -q -d ECC
    
    ※以下、出力結果抜粋
    
    GPU 00000000:05:00.0
        Ecc Mode
            Current                           : Enabled
            Pending                           : Enabled
        ECC Errors
            Volatile
                SRAM Correctable              : 0
                SRAM Uncorrectable            : 0
                DRAM Correctable              : 9    ★
                DRAM Uncorrectable            : 11   ★
            Aggregate
                SRAM Correctable              : 0
                SRAM Uncorrectable            : 0
                DRAM Correctable              : 9
                DRAM Uncorrectable            : 11
    
  2. 上記で"0"より大きい値を確認した場合、対象のGPUにて"Uncorrectable Error"のカウント数を
    以下のコマンドにて確認します。
    # nvidia-smi -q -i <GPU番号>
    ※<GPU番号>は、1.でGPU単位で出力した順に番号が指定でき、出力順に、0、1、2・・・となります。
     以下は、GPUの1番(出力単位で2番目のGPU)を指定した場合の出力内容抜粋になります。
    
    ※以下、出力結果抜粋
    
     # nvidia-smi -q -i 1
     ・・<snip>・・
        Remapped Rows
            Correctable Error                 : 0
            Uncorrectable Error               : 2    ★
            Pending                           : No
            Remapping Failure Occurred        : No
    
  3. 実行結果から、"Remapped Rows"項目の"Uncorrectable Error"の値が"8"より小さい場合は、
    以下のコマンドにてGPUデバイスの再起動をお願いいたします。
    # nvidia-smi -r
    
  4. GPUデバイス再起動後に、再度以下のコマンドで、★印のエラーカウントの値が"0"となっているか、ご確認ください。

    # nvidia-smi -q -d ECC -i 1
    
    ※以下、出力結果抜粋
    
    GPU 00000000:05:00.0
        Ecc Mode
            Current                           : Enabled
            Pending                           : Enabled
        ECC Errors
            Volatile
                SRAM Correctable              : 0
                SRAM Uncorrectable            : 0
                DRAM Correctable              : 0    ★
                DRAM Uncorrectable            : 0    ★
            Aggregate
                SRAM Correctable              : 0
                SRAM Uncorrectable            : 0
                DRAM Correctable              : 9
                DRAM Uncorrectable            : 11
    
なお、2.の実行結果で"8"以上の数字の場合には、お手数ですが、
再度以下2点の実行結果をmdx問い合わせ窓口までご連絡のほど、よろしくお願いいたします。
  • 「nvidia-smi -q -i <GPU番号>」の実行結果

  • 「nvidia-smi -q -i <GPU番号> | grep -e "Serial Number" -e "GPU UUID"」の実行結果