仮想マシンがつながらない場合のトラブルシュート (Windows)

※ 2016 年 9 月 15 日 一部更新しました。<※ 2016 年 9 月 15 日追加> と記載しております。

みなさん、こんにちは。Azure サポートの平原です。

仮想マシンを使っていて、オンプレミスの環境と同様にOS自体が破損し挙動がおかしくなることは、全くないとは言い切れません。そのため、定期的なバックアップはお勧めいたしますが、本日は、万が一のための、仮想マシンがつながらない場合の対処方法（トラブルシュート方法）についてご紹介をします。

※本内容は 2016年4月時点の内容です。

■ 目次

1. どういった症状が出るかの確認
2. ホスト名の確認
3. 接続性を確認する方法
4. 診断構成をして OS の挙動を確認する方法
5. 停止・再起動の実施
6. 再デプロイの実施 (IaaS v2 のみ)
7. 他の仮想マシンに接続してチェック

■ どういった症状が出るかの確認

使っているサービスで挙動がおかしくなった場合には、まずは挙動を正確に把握することです。サービスがどのように動かないかを整理することが、原因の推測と適切な復旧をするのに役に立ちます。たとえば、Webアプリケーションを展開している場合には、複数の環境からアクセスをしてみてWebサイトが表示されるのか、はたまた、接続自体ができないのか (タイムアウトするのか)、などを整理します。確認の際には、様々なツールを使うことで確認をすることができます。

■ ホスト名の確認

ポータル上に表示されているホスト名が意図したホスト名になっているかをご確認ください。もし、ホスト名が WIN-********** のような名前になっている場合には、sysprep されたイメージから自動でつく名前になります。以下のようなことがないかご確認ください。

• 既存の仮想マシンで発生している場合には、直前に sysprep していないか確認ください。sysprep をしてしまうと、マシン情報やAzure固有の設定情報なども失われますので、正常に起動ができなくなります。
• sysprep したイメージ (一般化イメージ) を、特殊化イメージとして仮想マシンを作成していないか、確認ください。sysprep したイメージを、特殊化イメージとして起動すると、Azure 用に仮想マシンの初期化処理が実行されないため、正常に起動ができません。

上記に該当する場合には、VHD を残したまま一度仮想マシンを削除していただいた上で、該当 VHD をダウンロードして、ローカル上のHyper V上で起動して適切な処置をしてください。(sysprep が必要な場合にはローカル上で sysprep を再度実行する必要があります)

■ 接続性を確認する方法

挙動がおかしい場合、まず確認すべきは、そのサービスへの接続性です。ネットワーク通信では複数のレイヤーから構成されますが、それぞれのレイヤーで確認いただくのがよろしいかと思います。ここでは接続性を確認する方法についてご紹介します。

(1) DNS の名前解決の確認

もし展開しているサービスが Web アプリの場合には、きちんと名前解決がされているか確認することも役に立ちます。Windows サーバーの場合には、nslookup コマンドが使えますが、Linux サーバーの場合には dig コマンドが利用可能です。

Windows の場合：

nslookup xxxx.cloudapp.net

Linux の場合：

dig xxxx.cloudapp.net

(2) ping で疎通確認

もっともメジャーな方法として、ping (ICMP プロトコル) を使った疎通の確認があります。ただし注意点として、Azure のインターネットに接続されているロードバランサ―は ICMP を許可していないので、インターネット外部からは接続できません。そのため、この方法を使う場合には、内部の仮想ネットワークから試す必要があります。仮想ネットワーク内であれば、仮にVPN でオンプレミス環境とつないでいても VPN で ICMP を通しているのであれば、ping による疎通確認は可能です。また、Azure 内に展開されている仮想マシンでも ICMP プロトコルを使えるように事前に設定をしておく必要があります。

コマンド例：

ping xxxx.cloudapp.net

(3) psping で疎通確認

(2) の方法は、ping で疎通確認をする方法でしたが、IPv4 では ICMP プロトコルを使うため、インターネット外部からは確認が取れませんでした。(多くのサービスにてセキュリティ対策の一環として ICMP が使えない場合があります) マイクロソフトで提供するトラブルシュートツール Sysinternals のツールに psping というツールがあり、このツールを使うことで TCP レベルの接続確認をすることが可能です。sysinternals のツールは、こちら(https://technet.microsoft.com/ja-jp/sysinternals/)のサイトから種々のツールとともにダウンロード可能です。たとえば、TCP 80 ポートを試したい場合には、以下のようなコマンドで確認することが可能です。

コマンド例：

psping xxxx.cloudapp.net:80

もしツールが使えないということであれば、PowerShell が使える環境の場合には、以下の方法もあります。

$tcpclient = New-Object System.Net.Sockets.TcpClient
$servername = xxx.cloudapp.net
$port = 80
try{
   $tcpclient.Connect($servername, $port)
   Write-Output "Connected"
} catch {
   Write-Output "Error"
} finally {
   $tcpclient.Close()
}

(4) リモートデスクトップ接続 (RDP) の確認

リモートデスクトップでつながるかも、仮想マシンが問題なく動作しているか確認するのに有用な方法です。Windows OS の場合には、以下のコマンドを実施することで、リモートデスクトップクライアントを起動することができます。

1. [Windows] + [R] キーを押します。
2. [ファイル名を指定して実行] 画面にて mstsc と入力して実行します。
3. リモートデスクトップクライアント

リモートデスクトップに異常があるお話の場合には、以下の記事も是非ご参考ください。

• Azure Virtual Machines へのリモートデスクトップ接続ができない問題を切り分けるには

  https://blogs.technet.microsoft.com/askcorejp/2015/07/07/azure-virtual-machines/

(5) http / https のページ取得可否の確認

Web アプリケーションをホストしている場合には、アプリケーションレベルでの挙動の確認も、仮想マシンがきちんと動作しているか確認するのに有用な方法です。お使いの Web ブラウザを使って、利用しているサービスの確認をするとよいでしょう。また、curl コマンドを使うことで、テストの HTTP リクエストを対象サーバーに投げることも可能です。

curl xxx.cloudapp.net

※Windows の場合には、PowerShell から実行が可能です。

■ 診断構成をして OS の挙動を確認する方法

Azure の仮想マシンの診断構成をすることで、仮想マシンの現在のイメージを取得することが可能です。もし仮想マシンが正しく動作をしているのであれば、時刻などが表示された画面が表示されますが、きちんと起動していない場合などは、真っ黒な画面が表示されます。こちらの結果を確認することで、どういった事象が出ているかについて、確認いただくことが可能です。直近の仮想マシン作成では既定で有効化されていますが、手動での設定方法としては、以下の通りです。

1. 新しいポータルにて、対象の仮想マシンを開きます。すべての設定において、「起動の診断」を選択します。

2. 「設定」を選択します。

3. 「起動の診断」が有効になっていることを確認します。

以上の設定をしていただくことで、仮想マシンの起動状態のイメージを確認することが可能になります。

また、以下のような画面が出ている場合には、仮想マシンが破損している可能性があります。

■ 停止・再起動の実施

一時的な仮想マシンの障害の際には、再起動にて機能が修復される場合があります。そのため、もし挙動がおかしく、上記の確認にて仮想マシンのサービスにアクセスできない場合には、一旦仮想マシンの停止をし、再起動をすることをお勧めいたします。

1. ポータルにログインをして、該当の仮想マシンに接続します。
2. ポータルの [停止] ボタンを押します。
3. 停止が確認できましたら、[開始] を押します。
4. 完全に開始をしましたら、再度接続性の確認をしてみてください。

■ 再デプロイの実施 (IaaS v2 のみ)

IaaS v2 (クラシックモードではないリソースマネージャーモードで作成した仮想マシン) の場合には、「再デプロイ」という機能が追加されています。本機能では、該当の仮想マシンがホストしているノード (ブレードサーバーのこと) を変更することがあります。かなり稀ではありますが、ノードに異常があり仮想マシンの挙動がおかしいことがあります。それが疑われる場合には、本方法を利用することで強制的にノードの変更を行うことができます。(ただし、通常はノード以上がある場合には、監視上ノード異常が検知され次第、Azure上のサービスヒーリング機能＝自動復旧機能により、当該ノード上の仮想マシンは強制的に移動が行われます)。以下の方法にて、実施が可能です。

1. ポータルにログインをして、該当の仮想マシンに接続します。
2. 仮想マシンの [すべての設定] を選択します。
3. [再デプロイ] を選択して、再デプロイを実施します。

<※ 2016 年 9 月 15 日追加>

仮想マシン内部にて、ネットワーク インターフェースの設定変更が理由で VM に繋がらなくなった場合、以下の手法にてネットワーク インターフェースを差し替えることで解消する場合があります。

Azure VM (ARM) の NIC 差し替えについて

https://blogs.technet.microsoft.com/jpaztech/2016/09/14/azure-vm-arm-nic-change/

■ 他の仮想マシンに接続してチェック

上記を確認してみて、環境周りや一時的な障害ではなく、OS自体の破損が疑われる場合もあります。その場合は、OS自体の挙動自体がおかしくなっているため、そのままでは復旧ができません。そのような場合には、一度仮想マシンを削除していただいて、別の仮想マシンにディスクをアタッチ・マウントしてチェックする必要があります。他の仮想マシンに接続した後で、以下のコマンドを実施して修復を試してみてください。

(1) チェックディスクを走らせて状態をチェックする

チェックディスクを走らせることで、セクタレベルでの破損のチェックが可能になります。以下の例は、F: ドライブに破損が疑われるドライブをマウントした場合の処理です。

chkdsk F:

(2) システムファイルチェッカーを使ってチェックする

システムファイルチェッカー (SFC.exe) を使うことで、OS のシステムファイルの異常をチェックすることが可能です。以下の例は F: ドライブに破損が疑われるドライブをマウントした場合の処理です。

sfc.exe /scannow /OFFBOOTDIR=F:\ /OFFWINDIR=F:\Windows

以上の内容が、ご参考になれば幸いです。