Nutanix Community Edition(CE)に関する話題はこちらへどうぞ。
Page 2 / 3
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
14 February 2022
ご無沙汰しております。島崎です。
当該の症状は、macOS 10.15 Catalina以降で証明書のセキュリティ要件が変更(厳格化)されたことにより発生しているものです。
オススメとしてはそのままFirefoxをお使い頂くか、あるいはChromeで、ウィンドウがアクティブな状態で thisisunsafe (This is unsafe=これは危険です)とキーをタイプする(※アドレスバーや検索バーに入力するわけではありません)ことによって、Prismに画面遷移させるという方法です。
Nutanixのナレッジベースとしては下記の記事が該当しますが、”Chrome thisisunsafe macOS” あたりのキーワードで検索して出てくる日本語記事のほうが読みやすいかもしれません。
Accessing Prism from a browser on macOS 10.15 "Catalina" blocked by ERR_CERT_REVOKED error
https://portal.nutanix.com/kb/8569
smzksts 様 御世話になります ＆ ご無沙汰しております。先日、数年ぶりにCEをダウンロードしてみました。形式がimg から iso に変わっていたので些か戸惑いましたが無事にCE：202009をインストール出来てvm作成まで完了しています。私の環境は M1 mac macOS Monterey 12.1 Safari 15.2 を使っているのですがPrism へのアクセスが出来ません。同様にEdge Chrome, でも同じ様なエラーメッセージでアクセスが拒否されます。唯一接続可能なのが Firefox 97.0 でこれは”警告を無視して先に進む”で接続が可能となっています。何か回避策があれば教えて頂きたく投稿させて頂きました。参考の為、EDGEでのエラーを下記、貼っておきます。お手数をおかけ致しますがよろしくお願い致します。
接続がプライベートではありません
攻撃者が、192.168.1.66 から個人情報 (パスワード、メッセージ、クレジットカードなど) を盗み取ろうとしている可能性があります。
NET::ERR_CERT_INVALID
Subject: *.nutanix.local
Issuer: *.nutanix.local
Expires on: 2032/02/07
Current date: 2022/02/12
PEM encoded chain:
お世話になっております。
ご回答ありがとうございました。
UEFIブートは本番機で試してみることにします。
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
6 December 2021
CE 202.09.16ですと仮想マシンのUEFIブートにいくつか問題があるようでして、
acli vm.nic_create <VM_NAME> model=e1000 network=<VM_NETWORK_NAME>
という感じでNICをVirtIOではなくe1000に妥協することで一応NIC付きでの起動まで行けるのですが、Windows Server 2019や2016では、その後OSのインストーラーで、ドライバーを読み込ませた後のステップにBSODになってしまいました。
私の方では有効な手立てを持ち合わせておらず、本バージョンではLegacy Bootでお使いいただくことをオススメしております…。
お世話になります。
NutanixCE（2020.09.16）で仮想マシンのUEFIブートは可能でしょうか。
NutanixCE（2020.09.16）で仮想マシン(Win2019)をUEFIブートで起動させるとUEFI画面で固まってしまいます。
NICを外した状態だと通常起動されるのですが、NICを付けると起動できなくなります。
環境としては、Nutnaix-VirtIO-1.1.5iso、セキュアブートなし、ディスクはideでやっております。
お世話になります。
SSHクライアントの縦横の表示文字数(ウィンドウサイズ)を目一杯広げてからインストーラーを再実行してみてはいかがでしょうか？
ご推察・ご指摘の通りでした…。
SSH経由操作だけでスクリーンサイズ不足のエラーを回避できるものと思い込んでおり、
恥ずかしながら、エラーメッセージの文意通りの事を試しておりませんでした。
その後無事仮想マシン構築までたどり着けました。
実は今回、このためだけに環境を一式揃えたもので、
お陰様で10万円超の出費が無駄にならずに済みそうです。
本当にありがとうございました。
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
24 November 2021
> 成功時の確認ですが、一般的なUSBメモリにて2020.09.16版のiso利用という事で良いでしょうか？
こちらについては、一般的なUSBメモリで通常の2020.09.16版のISOを利用しています。NICドライバだけはオンボードのRealtekをインストーラーが自動認識できないので、自分でビルドしたものを使いました。
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
24 November 2021
Terminal screen is not large enough to run the installation script. Please resize the terminal and rerun the script.
というメッセージが最後に出ているので、SSHクライアントの縦横の表示文字数(ウィンドウサイズ)を目一杯広げてからインストーラーを再実行してみてはいかがでしょうか？
成功した環境ですとSSHクライアントはWindowsでTeraTermを使用し、縦横の表示文字数を増やして(ウィンドウサイズを大きくして)からインストーラーを再実行することで成功しています。
逆に、SSHクライアント経由でもウィンドウサイズを変えていなかったり、広げ方が不十分だったりすると、ローカルコンソールと同様に↑のメッセージが出て失敗します。TeraTermもデフォルトの80x24文字だと小さ過ぎてエラーになりました。BIOS設定は特に変更していなかったと記憶しています。
ご回答いただきありがとうございます。
改めてTeraerm利用しSSH経由で実施してみましたが、状況変わらずで、画面表示は以下の通りでした。
2021-11-23-06:45:58-UTC ./ce_installer: line 298: [: too many arguments
2021-11-23-06:45:58-UTC Loading drivers
2021-11-23-06:45:59-UTC Removing the built-in i40e driver and reloading the new i40e driver
2021-11-23-06:45:59-UTC Getting DHCP address for phoenix
2021-11-23-06:45:59-UTC dhclient(3699) is already running - exiting.
2021-11-23-06:45:59-UTC
2021-11-23-06:45:59-UTC This version of ISC DHCP is based on the release available
2021-11-23-06:45:59-UTC on ftp.isc.org. Features have been added and other changes
2021-11-23-06:45:59-UTC have been made to the base software release in order to make
2021-11-23-06:45:59-UTC it work better with this distribution.
2021-11-23-06:45:59-UTC
2021-11-23-06:45:59-UTC Please report for this software via the CentOS Bugs Database:
2021-11-23-06:45:59-UTC http://bugs.centos.org/
2021-11-23-06:45:59-UTC
2021-11-23-06:45:59-UTC exiting.
2021-11-23-06:46:01-UTC Running /ce_installer
2021-11-23-06:46:01-UTC INFO Installing /usr/lib/python2.7/site-packages/foundation_layout-99.0+r.1284.8348b43-py2.7.egg
2021-11-23-06:46:01-UTC INFO /root/components doesnt exist
INFO Model detected: CommunityEdition
INFO vpd_info {'vpd_method': None}
INFO Generating cluster_id
INFO node_serial = f4c4400e-d133-4eda-a9d0-139c3a6c1082, node_uuid = 53bca156-ef55-4e00-b196-e050faa32fd3, block_id = , cluster_id = 2739627187682289439, model = USE_LAYOUT, model_string = CommunityEdition, node_position =
INFO Getting NOS version from the CVM
INFO Phoenix ISO is already mounted
INFO Getting AOS version from /mnt/iso/images/svm/nutanix_installer_package.tar.p00, This may take a few minutes if phoenix is running from BMC
Terminal screen is not large enough to run the installation script. Please resize the terminal and rerun the script.
[screen is terminating]
[root@phoenix ~]#
個人的にはINFO /root/components doesnt existの表示が気になっているところです。
成功時の確認ですが、一般的なUSBメモリにて2020.09.16版のiso利用という事で良いでしょうか？
BIOS（UEFI）の設定も特に変更不要でしょうか？
質問ばかりで申し訳ありませんが、よろしくお願いいたします。
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
21 November 2021
junk01さん、すみません返信遅くなりました。
M75sでインストール成功しているのは私の自宅環境ですね。
このマシンだとブートデバイス優先度の変更では成功しなかったため、SSH経由でインストールしました。
また、ディスク構成は下記のとおりです。記載いただいている環境と大きな違いはないように思います…。
AHV→NVMe SSD(120GB)
CVM→SATA-SSD(2TB)
Data→SATA-SSD(2TB)
Screen is terminatingとなってしまう場合、Teraterm等のログ機能を使って、Terminatingの表示になる直前にどのようなエラーが表示されていたのかを確認すると解決のヒントになるかもしれません。
UEFI起動順を設定してもエラーになり、SSH経由でリトライしても[screen is terminating]となり
インストールに進めない事象となります。
上記続報、自己レスです。
ストレージの接続や構成をいろいろと変更して試していたところ、起動用USBを含め、物理ストレージが４台以上となると上記の事象となる様です。
４台すべてUSB経由⇒NG
USBBoot+３台SATA接続⇒NG
SATABoot+2台SATA+1台nvme⇒NG
SATABoot+2台SATA⇒TUI起動するが、NextPageを選択で同様のスクリーンサイズ不足エラー発生。
（そもそもBoot imageを保持するディスクに対しH/C/Dを選択せざるを得ない構成）
SATAorUSB Boot+1台SATA+1台nvme⇒同上
今回利用しているLenovo M75s Gen2はSpeaker Deckのスライドp18にも言及があり、
インストールの実績があるものと思いますが成功された方はどのようなストレージ構成だったのでしょうか？
BIOS（UEFI）の設定変更やインストールスクリプトの変更などが必要なのでしょうか。
ご存じの方がいらっしゃいましたらぜひ情報提供をお願いします。
お世話になります。junk11と申します。
徹底解説のスライドを参照しCEの5.18インストールを試みているのですが20pの記載に従い
UEFI起動順を設定してもエラーになり、SSH経由でリトライしても[screen is terminating]となり
インストールに進めない事象となります。
https://speakerdeck.com/smzksts/nutanix-ce-5-dot-18-deep-dive?slide=20
H/W構成の概要は以下の通りです。
Lenovo ThinkCentre M75s Small Gen2
Ryzen7 PRO 4750G 32GB
samsung 970 EVO Plus 2TB(Hot Tier:nvme0n1)
Seagate ST8000DM004 ８TB(Cold Tier:sdb)
intel SSDSA2M080G2GC 120GB(HV起動用:sda)
KIOXIA USB3.2 Gen1 32GB(iso起動用:sdc)
[root@phoenix ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 1.8T 0 disk
sdb 8:16 0 7.3T 0 disk
sr0 11:0 1 1024M 0 rom
loop0 7:0 0 194M 0 loop
sdc 8:32 1 28.9G 0 disk
└─sdc1 8:33 1 28.9G 0 part /mnt/iso
sda 8:0 0 111.8G 0 disk
└─sda1 8:1 0 111.8G 0 part
事前の情報収集にてできるだけ実績のある（ありそうな）ものを
チョイスしたつもりですが、行き詰り、困り果てております。
何のどこから確認したものか、ヒントだけでもいただければ幸いです。
以上、よろしくお願いいたします。
こんにちは。
https://speakerdeck.com/smzksts/nutanix-ce-5-dot-18-deep-dive?slide=56
上記の56スライド目以降を拝見して、Nutanix CE 5.18にESXiをインストールするときに必要なLocal VMFS有効化を行おうとしましたが、インストール後リブート前に/dev/sdd5 をマウント時にdoes not exitと返されてしまい、/dev/sda5 の起動用のjsonファイルの該当箇所は元から
"user_vmfs?_datastore":"true"
となっているのですが、そのままrebootをかけるとFaild-Installになってしまいますが、
ssd5のパスは環境によってかわりますでしょうか。(ls /dev で確認したところssd1のみ確認できましたが/Nutanix以下のディレクトリはなし)
■試したESXiバージョン
7.0U2a-17867351
7.0-15843807
6.7-14320388
何卒宜しくお願い致します。
自己解決済み
7.0U2a-17867351
7.0-15843807
→VMFS参照不可
6.7-14320388
→VMFS参照可，CVMの起動に失敗していたので，スライド６２以降の手順でpyスクリプトの修正・再実行・Clusterの手動作成にて無事Prsim起動いたしました。
こんにちは。
https://speakerdeck.com/smzksts/nutanix-ce-5-dot-18-deep-dive?slide=56
上記の56スライド目以降を拝見して、Nutanix CE 5.18にESXiをインストールするときに必要なLocal VMFS有効化を行おうとしましたが、インストール後リブート前に/dev/sdd5 をマウント時にdoes not exitと返されてしまい、/dev/sda5 の起動用のjsonファイルの該当箇所は元から
"user_vmfs?_datastore":"true"
となっているのですが、そのままrebootをかけるとFaild-Installになってしまいますが、
ssd5のパスは環境によってかわりますでしょうか。(ls /dev で確認したところssd1のみ確認できましたが/Nutanix以下のディレクトリはなし)
■試したESXiバージョン
7.0U2a-17867351
7.0-15843807
6.7-14320388
何卒宜しくお願い致します。
Nutanix Filesについてご教示ください。
CE(202009)にてサポートされたと聞き試行したところ、毎回タスクが下記メッセージにてエラー停止します。
「Cannot complete request in state InvalidVmState: Cannot complete request in state Paused」
確かにVMタブを見ていると、いったんFile Server VMがパワーオンし、その後ポーズ状態に遷移し削除されています。何か思い当たる解決策がありましたら、ご教示ください。
smzksts 様
上記の状態ですが、例えば途中で中断したアップグレードを再開させるコマンドなどは無いでしょうか？
途中で再起動するようなことをしてしまっているのでうまく完了するとは限らないのですが、試してみる価値は無いでしょうか。
その後、クラスタのステータスなどを調べて、4台中3台のCVMでscavengerサービスが起動していないことがわかりました。
起動しているのはアップデートが正常完了？したホストの1台だけです。
また、ncliやacliを実行するとconnection refusedとなり、zookeeper.outにも同様に
ZOO_ERROR@handle_socket_error_msg@2185: Socket [xx.xx.xx.xx:9876] zk retcode=-4, errno=111(Connection refused): server refused to accept the client
が延々と記録されている状況です。
ここがクリアになれば先に進める気がするのですが、何か情報は無いでしょうか？
いつもお世話になっております。
以下リンク先の内容に沿って、アップグレードを実行してみました。
https://blog.ntnx.jp/entry/2020/09/30/235747
4台ホストのクラスタ中、1台だけは普通にアップグレードが完了（タスク一覧で100%になりました）したように見えましたが、残り3台が73%のまま数日待っても変化無しという状態です。
あまりに状況に変化が無いままでしたので、一旦クラスタを停止して、ホストの再起動を行ったところ、クラスタが起動しなくなってしまいました。
cluster start
→WARNING genesis_utils.py:1199 Failed to reach a node where Genesis is up. Retrying... (Hit Ctrl-C to abort) ※24行くらい繰り返し
Waiting on xx.xx.xx.xx (Up, ZeusLeader) to start: IkatProxy IkatControlPlane SSLTerminator SecureFileSync Medusa DynamicRingChanger Pithos Mantle Stargate InsightsDB InsightsDataTransfer Ergon Cerebro Chronos Curator Athena Prism CIM AlertManager Arithmos Catalog Acropolis Uhura Snmp SysStatCollector NutanixGuestTools MinervaCVM ClusterConfig Mercury Aequitas APLOSEngine APLOS Lazan Delphi Flow Anduril XTrim ClusterHealth
Waiting on xx.xx.xx.xx(Up) to start: IkatProxy IkatControlPlane SSLTerminator SecureFileSync Medusa DynamicRingChanger Pithos Mantle Stargate InsightsDB InsightsDataTransfer Ergon Cerebro Chronos Curator Athena Prism CIM AlertManager Arithmos Catalog Acropolis Uhura Snmp SysStatCollector NutanixGuestTools MinervaCVM ClusterConfig Mercury Aequitas APLOSEngine APLOS Lazan Delphi Flow Anduril XTrim ClusterHealth
Waiting on xx.xx.xx.xx (Up) to start: IkatProxy IkatControlPlane SSLTerminator SecureFileSync Medusa DynamicRingChanger Pithos Mantle Stargate InsightsDB InsightsDataTransfer Ergon Cerebro Chronos Curator Athena Prism CIM AlertManager Arithmos Catalog Acropolis Uhura Snmp SysStatCollector NutanixGuestTools MinervaCVM ClusterConfig Mercury Aequitas APLOSEngine APLOS Lazan Delphi Flow Anduril XTrim ClusterHealth
Waiting on xx.xx.xx.xx (Down) to start:
~中略~
The state of the cluster: Unknown
Lockdown mode: Disabled
CVM: xx.xx.xx.xx Down →4台分
と表示されています。
genesisが起動していないのかなと思い、
genesis start
すると、already runningとなるので起動はしているように見えます。
CVMから「ping 192.168.5.1」は4台すべて通っています。
何かクラスタを復旧する方法は無いでしょうか？
smzksts 様
お世話になっております。
また大分時間が開いてしまいましたが、破損ホストの削除不可、一部仮想マシンの操作不能（グレー表示）の件で結果報告いたします。
Acropolisのマスター再起動は、既に試していたようです。
残してあった操作のメモ見たら、同じKBを参照して対応していました。
残念ながらAcropolis再起動では解決しなかったようです。
仮のクラスタは問題なくリモートDRで仮想マシンの移動ができて動作確認もできましたので、すべてのホストを新規クラスタで作り直しました。
現在は、仮クラスタの仮想マシンを戻し、すべて正常に動作するようになりました。
ありがとうございました！
※いろんなテストをしていたので、かえってこれでスッキリきれいな環境になってうれしい面もあります。
今回の一件で、NutanixCEでいろいろテストしていく上で結構リモートDRは良いなぁと感じました。
最悪クラスタを破壊するようなことがあっても、あっさり戻せるのは安心感があります。
※10GLANということもあるかもしれませんが、あまりに速くて逆に心配になったくらいです。
NGTを入れていない仮想マシンも多かったので、今回は仮想マシンをシャットダウンしてからスナップショットを取るようにして移行しましたが、NGTを入れておけば活動中でも大丈夫そうです。
このあたりはもう少しテストしてみようと思います。
さて、再構築したときに気付いたのですが、いつの間にか新しいバージョンがリリースされていたのですね。
こまめにPrismでアップデートの確認していてもNCCとFoundation以外は出てきていなかったので、そのまま2019.11.22版で再構築したのですが、コミュニティ見ると2020.09.16版になっていて驚きました。
Prismのアップデートでは検出されませんでしたが、「バイナリのアップロード」でアップデートしても問題は無いでしょうか？
なんとなく順序としては、
- AOSのアップデート
- AHVのアップデート
- PrismCentralのアップデート
こんな感じなのかなと思っていますが、合ってますでしょうか。
smzksts 様
だいぶ間が開いてしまい恐縮ですが、一部仮想マシンが削除できない＆ホストも削除できないの件で、少し前進しました。
Acropolisのマスター再起動はまだ試していませんが、別のクラスタをシングルノードで構築してリモートDRでクラスタ跨いでスナップショットを取る、というのをやってみました。
結果としては、灰色になって起動も削除もできなかった仮想マシンを含め（少々驚きました）、スナップショットの取得に成功、別のクラスタ上で正常に起動することも確認できました。
灰色になった仮想マシンの復旧方法としても使えそうです。
とりあえず必要そうな仮想マシンを新しいクラスタに一旦退避して、何が起きても大丈夫な状態でAcropolisのマスター再起動も試してみようと思います。
業務の合間で試しているのでなかなか進みませんが、また報告させていただきます。
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
26 January 2021
Twitter等では紹介していたのですが、CE関連の資料を作ったのでコチラにも載せておきます！
Nutanix CE 5.18のインストールに関する詳細解説資料です。
インストール周りで躓きがちなポイントとその回避方法をたくさん載せてますので、
上手くいかないときにまずはご一読くださいませ。
smzksts 様
他のホストは正常に動作していますので、グレー以外の仮想マシンの変更や新規作成には問題ありません。
ホスト（クラスタ）の再構築は最終手段としてある程度覚悟はしていました。
スペックはかなり落ちるものの、一時的な受け皿とするための機材は何とかなりそうですので、最悪そうしないといけないね、と内輪では話をしていた感じです。
仰るとおり、かなりいろいろなテストをしたりホストの差し替えを頻繁に行ったりで無茶している環境ではありますので、このあたりですっきりと整理しても良いかなと思っています。
まだご提示いただいたKBの内容は読み切れていませんが、なんとなく一致しそうな気がしています。
Acropolisサービスのマスター再起動はまた後日試してみて、解決しなければ一時的に別のクラスタ作ってAsyncDRで逃がしてクラスタを１から再構成することを計画しようと思います。
CE版にも関わらず、いろいろアドバイスいただけてむしろ感謝しております。
また少し間が空くと思いますが、結果などは報告させていただきますのでよろしくお願いします。
Userlevel 4
+9
- Nutanix Employee
- 88 replies
-
9 January 2021
PCの削除もノードの削除もレスポンスが無いというのは気になりますね…。
他のVMの作成/削除には支障ない状態でしょうか？
ご認識のとおり、acli vm.delete にはforceオプションはありません。本来、デフォルトでforceな形で処理されるものです。
MARKED_FOR_REMOVAL_BUT_NOT_DETACHABLEをキーワードとして検索して、他に関連しそうな公開KBとしては下記のもの程度でした。
AHV | Node removal stuck after successfully entering maintenance mode
https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e0000009D6CCAU
もしもこちらの状況に合致するようであれば、回避策として、Acropolisサービスのマスターを再起動する、という方法も考えられます。
- 任意のCVMのCLIにログインし
links http://127.0.0.1:2030
というコマンドを実行すると、テキストベースのウェブブラウザが実行されます。 - Acropolisサービスの詳細が表示されますので「Acropolis Master」という項目を確認します。「this node」または他のCVMのIPアドレスが表示されます。
- Acropolis Masterの項目に表示されたCVMにアクセスし。下記のコマンドでacropolisサービスを再起動します。
genesis stop acropolis; cluster start - もしも手順3でも変化がない場合には、メンテナンスモードの無効化と有効化を手動で行います。
acli host.exit_maintenance_mode <host IP or uuid>
acli host.enter_maintenance_mode <host IP or uuid>
他にもKBを探してみたのですが、あいにくInternal向け(非公開)なものに限られておりました…不安定な状態で様々な対応を試行するのもリスキーな気もしています(商用版ならサポート部門が解析した上でより的確な対応策をご案内するのですが、なにぶんCEのため…)。
もしも大事なGuest VMがある＆CEをインストール可能な機材が他にもありましたらAsync DRでデータの退避した上で再インストールを行うなどの対応も視野に入れておいて頂くのがよろしいかもしれません。
smzksts 様
大変お世話になっております。
Prism Centralを削除しなくても新規で接続するのは問題ないとのことで、また一つ前に進めそうです。
※すぐに使えないといけない予定も無いので、あとからじっくりやってみようと思います。
acli vm.delete は実行してみましたが、PCの仮想マシンは削除できませんでした。
試しに他の仮想マシンでもやってみましたが、以下のような結果でした。
・「仮想マシン」ー「テーブル」でグレーになっている仮想マシンはタスクが０％のまま進まない
・赤（停止中）で正常なホストにいる仮想マシンは何の問題もなく削除できる
・緑（起動中）の仮想マシンでは試していません
ホスト削除のncli host rm-start force=true も実行してみましたが、こちらも
Host removal successfully initiated
と応答はあるものの、前回同様にタスクが出てくる気配がない状態です。
何度かトライしているので裏で処理が進んでないタスクが残っているのではと思い、
https://next.nutanix.com/how-it-works-22/clear-out-stuck-tasks-31879?postid=39355#post39355
ここの情報を参考にして
ecli task.list include_completed=false
で表示されたタスクはすべて
~/bin/ergon_update_task --task_uuid=xxxxxxxxxxxxxxxxx --task_status=aborted
で中断してみましたが、ホストの削除もVMの削除も効果が無い状況です。
少しNutanixバイブル（日本語版）も見て確認してみたんですが、ncli vm.delete には force=trueのような強制するオプションは無いのですよね？
あと試してみたことは、削除できない仮想マシンのディスクを acli vm.disk_delete で削除してからならできないかな？とも思ったのですが、これ自体も0%のままで進みませんでした。
きっと障害が発生したときに、あとからホスト削除→再構築して再度追加ではなく、ブートディスク（USBメモリ）の復旧をすればこんなことにはならなかったと深く反省している次第です。
※何度もやっている手順でもあったので、作業者に指示しやすかった面もあったのですが・・・。
とりあえず、3台構成でもテストや評価は進められる部分も多いので、気長に対応していこうと思います。
Page 2 / 3
Reply
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.