らぼ株式会社ネットワールドのエンジニアがお届けする技術情報ブログです。各製品のエキスパートたちが旬なトピックをご紹介します。2016への寄稿も兼ねております。アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。Hagemann氏によるものです。EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。VMをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。当社のNutanix社製品についてはこちら。VMware社製品についてはこちら。このブログの記事はフリーズした仮想マシンの強制停止方法についての内容です。テクニカルサポートとして勤務していると「何かがおかしい」としか言いようのないようなケースに出くわすことが有ります。これはストレージの問題であったり、特定のESXiで動作中のプロセスが他の多くの理由からファイルをロックしているということだったりします。恒久的なデバイスの喪失)が起こっていないかなどのテクニックに続けて、どのように仮想マシンを強制停止するか様々な方法を体系立ててご紹介していきます。最初は仮想マシンがどのように動作しているかを見てみましょう。ESXi内部のプロセスこれらのプロセスはそれぞれが別々のコンテキスト(context)から来ているため、別々のグループに分類することが出来ます。左上では仮想マシンがユーザーワールドで動作しているのがわかります。Hostdとシェルです。シェルESXiがLinuxベースのものではないということを理解しておくことが重要です。これは最近ではあまり耳にしなくなりましたが、ほんの少しまでは多くの人々がESXiをLinuxベースだと勘違いして色々と試行錯誤したという話をしていました。catなど)が利用でき、SSHでリモートアクセスしたときの挙動が似ているからというだけだったりするのです。ESXiがLinuxベースではないのだったら、どうしてこのようなLinux/Unix由来のコマンドが使えるんだい?それはとても簡単です。VMwareが「Busybox」と呼ばれるソフトウェア実装を利用することにしたからです。これはVMwareによる軽量なシェル実装で、典型的なシェルコマンドの実行をおこないます。BusyBoxはユーザーワールドのプロセスとしてVMKernel上で動作します。基本的にはWindows上のcygwinに似たようなものです。これで何故コマンドがシェルの中で動作するのかがわかりました。Busyboxのおかげです。status/プロセスの状態)コマンドを利用すると、特定の仮想マシンのサブコンポーネントがどのような状態かよくわかります。CIF)があるか?フリーズした仮想マシンを強制停止するフリーズした仮想マシンの強制停止の方法は多くあります。以下では4つの例を挙げてどのように仮想マシンを強制停止するかをご紹介します。例を上げながら、強制停止する方法をどのように適切なデータで特定しながら行うのかご紹介していきます。どのツールを利用するのが良い、悪いはなく、私は単に何が可能なのか、そのヴァリエーションをご紹介したいと思います。強制終了のパートのあと、更に、VMFSとNFSのロック機構についてもいくらかご紹介致します。kill)esxclivim-cmdESXtop“PS”を“KILL”と組み合わせる仮想マシンの状態を知るために、以下の"ps"コマンドを利用します(この例では仮想マシン名はam1ifvh029です)。ご覧のとおり、この仮想マシンは8つのvCPUを持つことがわかります。これは8つのvmm0~7、そして同じくvmx-vcpu-0~7と8つの仮想スレッドがmksとsvgaのスレッド以外に存在することからわかります。最後の列はグループID(GID)を示しており、これがメインとなるプロセスです。645137プロセスを終了させるためにはkillコマンドを-9オプションとともに利用します。killコマンドの別のオプションについて詳しく知りたい場合にはこちらをご参照ください。基本的には-9はカーネルがプロセス自身に何も通知を行わずに終了を行うという意味になります。これは理論的にはプロセスが何をしているかによってはデータを喪失する可能性があり、終了方法ではもっともハードなものになります。-2"(CTRL+Cと同じ)を試した後に行うのが良いでしょう。645137"kill"コマンドはそれが出来てしまう場合には何も確認を返してこずにプロセスを終了させてしまいます。psコマンドでもう一度プロセスの動作を確認すると、プロセスIDがなくなっているという事になります。PROCESS”を使うESXi上ではesxcliコマンドでハイパーバイザーの低レベルなインフラストラクチャの管理を行うことが出来ます。この先にご紹介するvim-cmdコマンドとは異なり、これは完全にESXiのその下のインフラストラクチャにフォーカスしたコマンドです。このコマンドはただひとつのコマンド(esxcli)に見えますが、様々なネームスペースを利用した広範なサブコマンドをもっています。ありがたく、また以前のesxcfg-コマンドよりも優れていることには、これはツリー階層構造にまとめられていることです。シェルにコマンドを入力し、いつでも利用可能なすべてのオプションを参照することが出来ます。2012964でよく使う組み合わせのコマンドを見つけることが可能で、esxcliとvim-cmdとPowerCLIがどのように違っているのかを見ることが出来ます。プロセスを停止させる前にそのプロセスがどの状態になっているのかということを確認してください。Jin氏によって書かれた素晴らしいブログの記事もあります。ID"を利用しなくてはなりません。"645172"なにもオプションを指定しない場合、標準では"soft"にて実行されます。"hard"または"force"を試してみてください。見ての通り、最初の例で"ps"コマンドで見たメインのプロセスIDとワールドIDは必ず同じものになります。これはいつもvmm0のIDです。“VIM-CMD”を利用して仮想マシンを強制停止するもう一つの仮想マシンの状態を確認して、停止を行うコマンドはvim-cmdです。これは「hostd」上に実装されており、ESXiとhostdとが統合されているAPIとほとんど同じように利用することが出来ます。vim-cmdは多くの運用タスクにも利用することが可能です。Jin氏によるもう一つのesxcli同様に素晴らしい記事はこちら。/bin/hostdvim-cmdにはいくつかのサブコマンドが有ります。help見ての通り、7つのサブコマンド(とhelp)があります。それぞれが何のためにあるのかが分かりますし、ESXiの内部にどれだけの機能やオプションが取り込まれているのかを想像することも出来ます。svc(サービス)を取り除きたいのであれば、基本的にそれぞれのコマンドを利用します:hbr、internal、solo、vm、host、proxy、vimそしてhelpです。実際にはinternalsvcはほんとうの意味のESXiの内部APIではないということは覚えておいてください。今は仮想マシンについて何らかの作業をしようとしていますので、"vmsvc"コマンドを使うということになります。4さて、結果として、仮想マシンが動作しているというアウトプットが得られました。4ESXtopを利用して仮想マシンを強制停止する以下のコマンドを利用してesxtopユーティリティを起動します。esxtopを実行する(esxtopはCPU表示で起動します、"c"を押すことで別の表示からCPUリソース利用状況の画面へ戻ってくることが出来ます)"Shift+v"を押すことで、仮想マシンの表示へと限定することが出来ます。これによって時々多くのプロセスが表示されてしまい、仮想マシンについて全く見えないということを防ぎ、可読性が良くなります。"f"をおして、表示されるリストのフィールドを表示します。ID"の列を追加します。これはどの仮想マシンを強制停止するのか見極めるために必要です。ID(LWID)から目的の仮想マシンを特定します。すると強制停止するWorld(WID)を聞かれます。ステップ5のLWIDを入力し、エンターを押します。数秒の後、プロセスが消えてなくなります。仮想マシンが応答しているものの、表示はされており、アクセス不能状態になっている場合には仮想マシンが現在動作しているホストがロックを保持している事になります。この場合、上のすべての方法は動作しません。他のホストがロックをまだ保持したままになっているのです。過去に仮想マシンがどのホストで動作していたかということを知ることは常に重要な事です。以下のコマンドでどこに仮想マシンが登録されていたかということをvmware.logsから知ることが出来ます。ホストで動作していることがわかります。どのデータストアで仮想マシンが動作していた家を見つけるもう一つの方法は既にご紹介したesxcliコマンドです。クラスタ内のデータストアにアクセス可能なホストのうちの一つから以下の例を使って、どこに仮想マシンが登録されているのか見ていきます。vCenterがダウンしている場合には仮想マシンが最後にどこにいたのかを知るためには上の例を使ってください。/vmfs/volumes/<DatastoreUUID>/<vmname>/<vmname>.vmxプロセスが半死の状態で、有益な情報を得られない場合にはlsofコマンドがもう少しだけ助けてくれる場合があります。最初はチェックしたい仮想マシンのディレクトリへと移動し、誰がロックを保持しているのかを見ます。IDの最後の部分001b21857010を確認することです。これはロックを保持しているホストのNICの一つのMACアドレスに関連しています。ファイルのオーナーなのかを確認できます。IDがゼロとして表示された際に利用するものです。この場合、<vmname>.vmx.lckファイルのオフセットを利用します。<offset>データストアは仮想マシンが動作しているデータストアです、ですから、一段戻ってデータストアレベルで実行してください。3723264)です。list"を利用してそのオーナーを調べます。これが特定のホストの物理NICのものになります。して、仮想マシンが他のホストに登録されており、ロックされていることが確認できればロックを保持しているホストへと仮想マシンを再度移動させて、仮想マシンを起動させることが出来ます。DRSをマニュアルにしておくということを忘れないで下さい。しておかないと仮想マシンは他のホストで間違って起動されてしまいます。ここまでの全てができなかった場合、最終的な手段としてはロックを保持しているホストの再起動になります。NFSのロック機構の説明NFSの場合には誰がロックを保持しているのか問うことを確かめるにはちょっと事情が異なります。これはファイルベースのプロトコルですから、当たり前のことです。仮想マシンのディレクトリへと移動します。.lckファイルに対してのものになります。.lckファイルが表示されます。どれが.vmx.lckなのかを見つけなくてはいけません。".lck-3409000000000000"を例として取り上げましょう。.lck-f208000000000000hexdumpコマンドで各.lckファイルのホスト名を調べなくてはなりません。|....|00000054上の例では、このロックファイルがam1ifvh003で保持されています。これでどのホストがこの.lckファイルを持っているのことがわかりました。.lck-3409000000000000がどのファイルのためのロックなのかがわかりません。今度はエンディアンを以下の図にあるようにひっくり返さなければなりません。次のステップは16進数から10進数への変換です。今回のサンプルでは、エンディアンは必要のない0で多く埋め尽くされています。ファイルということになります。このコマンドを活用して、自動的に同じことをESXi上で行うことも出来ます。仮想マシンがフリーズしてしまうのには数多くの理由が考えられます。誰がロックファイルを保持しているのかを様々な方法で見つけ出すことができれば、仮想マシンをどのように強制終了させるのか、フリーズした仮想マシンの問題をどのように解決するのか、多くの場合の糸口を見つけることが出来ます。最初にご説明したようにストレージシステムやSCSI予約の問題、ストレージシステムのバグによる嘘のinode番号、などが原因ということも有ります。私の記事が気に入った、もっといい提案や推奨したい方法があるなど、いつでもお気軽にご連絡ください。Calenderということで、普段は絶対に訳さないようなテッキーな内容をお届け致しました。実は結構このあたり、お客様で発生したトラブルでPernixDataが悪さをしているという嫌疑をかけられ、その原因調査などで実際に使ったテクニックなんかも含まれていたりして。いずれにしても、仮想マシンのフリーズ、あまり出くわしたくない事象ですが、万が一出くわしてしまった場合、盲に再起動するのではなく原因を調べ、再発を防ぐために何らか情報が欲しいものです。今回の情報はおそらく他にはないレベルでこれを説明した内容でしょう。Barcelonaにいってきたので発表内容をまとめてみたお問い合わせはこちら紹介した製品・サービスについて、ご検討の方はまずはお気軽にご相談ください。Blog】PowerStoreのデータ削減保証プログラムを徹底的に深掘りする!皆様、こんにちは!ネットワールドのストレージ担当SEの多川です。使い始めるための情報まとめ皆様こんにちは。SEの小池と申します。ConVerter」CIFS監査ログ設定検証してみました!皆様こんにちは。ネットワールドのストレージ担当、三嶽です。ネットワールド西日本技術部九州SEの濱崎申嘉です。ネットワールドストレージ担当の小野です。Reserved.引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。