cloud-init を使用した VM プロビジョニングのトラブルシューティング

適用対象: ✔️ Linux VM ✔️ フレキシブルなスケール セット

一般化されたカスタム イメージを作成し、プロビジョニングに cloud-init を使用すると、VM が正しくビルドされない可能性があります。 その場合は、イメージのトラブルシューティングを行って問題を見つけます。

プロビジョニングに関する問題の例:

• コンピューティング リソース プロバイダー API はエラーを返し、cloud-init は結果のエラーを報告します。
• VM が "作成中" で 40 分間スタックし、VM の作成が失敗としてマークされる。
• カスタム データ または ユーザー データ は処理されません。
• エフェメラル ディスクのマウントに失敗する (SCSI リソース ディスクに付属する VM SKU の場合)。
• ユーザーが作成されないか、ユーザー アクセスの問題があります。
• ネットワークが正しく設定されていません。
• スワップ ファイルまたはパーティションのエラーが発生している。

この記事では、cloud-init のトラブルシューティングを行う方法について説明します。 詳細については、cloud-init の詳細に関するページを参照してください。

cloud-init によって報告され、エラーとしてログに記録されたエラーのトラブルシューティング

Cloud-init は、プロビジョニング中に Azure にエラーを報告するときに構造化エラーを出力します。 これらのエラー メッセージには、エラーの調査に役立つ理由とサポート データ (タイムスタンプ、VM 識別子、ドキュメント URL など) が含まれます。

ブート診断の有効化とチェックに関するヘルプについては、「 ブート診断」を参照してください。

これらの問題のいずれかがプロビジョニングの後続の試行で解決しない場合は、イメージの構成が間違っている可能性があります。 cloud-init の問題があると考える理由がある場合は、 cloud-init GitHub イシュー トラッカーに報告してください。

cloud-init によって報告されないその他のエラーのトラブルシューティング

障害に応じて、次の手順を検討してください。

手順 1: customData を使用せずにデプロイをテストする

Cloud-init は、VM の作成時に渡される customData を受け入れます。 まず、この構成によってデプロイに関する問題が発生していないことを確認する必要があります。 何も構成を渡さずに VM をプロビジョニングしてみてください。 VM のプロビジョニングに失敗した場合は、推奨されるトラブルシューティング手順に従ってください。 構成が適用されていない場合は、 手順 4 を参照してください。

手順 2: イメージ要件を確認する

VM のプロビジョニング エラーの主な原因は、OS イメージが Azure で実行するための前提条件を満たしていないことです。 Azure でのプロビジョニングを試行する前に、イメージが適切に準備されていることを確認します。

次の記事では、Azure でサポートされているさまざまな Linux ディストリビューションを準備する方法について説明しています。

• CentOS ベースのディストリビューション
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES と openSUSE
• Ubuntu
• その他: 動作保証外のディストリビューション

サポートされている Azure cloud-init イメージの場合、Linux ディストリビューションでは、Azure にイメージを正しくプロビジョニングするために必要なパッケージと構成が既に用意されています。 独自にキュレートしたイメージから VM が作成できない場合は、既に cloud-init 用に構成されている、サポート対象の Azure Marketplace イメージに対して、オプションの customData を使用してみてください。 customDataが Azure Marketplace イメージで正しく動作する場合は、キュレーションされたイメージに問題がある可能性があります。

ステップ 3: VM ログを収集して確認する

VM のプロビジョニングに失敗すると、Azure に "作成中" 状態が 20 分間表示され、VM が再起動され、さらに 20 分待ってから、最後に VM のデプロイが失敗としてマークされてから、最後に OSProvisioningTimedOut エラーでマークされます。

VM の実行中、プロビジョニングが失敗した理由を理解するには、VM からのログが必要です。 VM のプロビジョニングに失敗した理由を理解するには、VM を停止しないでください。 VM を実行させたままにします。 ログを収集するには、失敗した VM を実行中の状態にしておく必要があります。 ログを収集するには、次のいずれかの方法を使用します。

• ブート診断を有効化してから、VM を作成し、ブート中に表示します。

• シリアル コンソール

• AZ VM Repair を実行 して OS ディスク (lvm、 lvm なし) をアタッチしてマウントします。これにより、これらのログを収集して調べることができます。

  /rescue/var/log/waagent*
  /rescue/var/log/syslog*
  /rescue/var/log/rsyslog*
  /rescue/var/log/messages*
  /rescue/var/log/kern*
  /rescue/var/log/dmesg*
  /rescue/var/log/boot*
  /rescue/ /var/log/cloud-init.log
  /rescue//var/log/cloud-init-output.log
  

> [!NOTE]
> Alternatively, you can create a rescue VM manually by using the Azure portal. For more information, see [Troubleshoot a Linux VM by attaching the OS disk to a recovery VM using the Azure portal](/troubleshoot/azure/virtual-machines/troubleshoot-recovery-disks-portal-linux).
To start initial troubleshooting, begin with the serial logs and cloud-init logs to understand where the failure occurred. Then use the other logs for a  deeper dive to help provide additional insights.

* /var/log/cloud-init.log
* /var/log/cloud-init-output.log
* [Serial/boot logs](/azure/virtual-machines/boot-diagnostics#boot-diagnostics-view)

In all logs, start searching for "Failed," "WARNING," "WARN," "err," "error," and "ERROR." Setting configuration to ignore case-sensitive searches is recommended.

Alternatively, use command `cloud‑init collect‑logs` to collect all necessary logs.
Azure’s latest cloud-init versions (≥ 18.2) include the collect‑logs command, which:

Gathers essential logs: /var/log/cloud-init*.log, instance metadata, system info.

Packages everything into a timestamped .tar.gz archive.

Saves the archive locally (for example, `/tmp/cloud-init-logs-timestamp.tar.gz`).

> [!TIP]
> If you're troubleshooting a custom image, you should consider adding a user during the image. If the provisioning fails to set the admin user, you can still log in to the OS.

#### Analyzing the logs

Here are more details about what to look for in each cloud-init log.

#### /var/log/cloud-init.log

By default, all cloud-init events with a priority of debug or higher, are written to `/var/log/cloud-init.log`. This log provides verbose logs of every event that occurred during cloud-init initialization.

For example:

```console
2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

エラーまたは警告が見つかったら、cloud-init ログを後方に読み取り、cloud-init がエラーまたは警告に達する前に何を試行したかを理解します。 多くの場合、cloud-init は OS コマンドを実行するか、エラーが発生する前にプロビジョニング手順を実行します。 これらのアクションは、エラーがログに表示される理由を説明するのに役立ちます。 次の例は、cloud-init が問題が発生する直前にデバイスをマウントしようとしたことを示しています。

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

シリアル コンソールを利用できる場合は、cloud-init が実行しようとしたコマンドを再実行してみてください。

/var/log/cloud-init.log のログは、/etc/cloud/cloud.cfg.d/05_logging.cfg 内で再構成することもできます。 cloud-init ログの詳細については、 cloud-init のドキュメントを参照してください。

/var/log/cloud-init-output.log

stdoutで、stderr や から情報を取得できます。 通常、このデータには、ルーティング テーブル情報、ネットワーク情報、ssh ホスト キー検証情報、 stdout, 、cloud-init の各ステージの stderr とタイムスタンプが含まれます。 必要であれば、stderr および stdout のログを /etc/cloud/cloud.cfg.d/05_logging.cfg から再構成できます。

シリアル/ブート ログ

Cloud-init には複数の依存関係があります。 これらの依存関係は、ネットワーク、ストレージ、ISO をマウントする機能、一時ディスクのマウントとフォーマットなど、Azure 上のイメージに必要な前提条件に記載されています。 これらの依存関係のいずれかがエラーを発生させ、cloud-init が失敗する可能性があります。 たとえば、VM が DHCP リースを取得できない場合、cloud-init は失敗します。

それでも cloud-init がプロビジョニングに失敗した理由を特定できない場合は、cloud-init ステージとモジュールの実行時期を理解する必要があります。 詳細については、「cloud-init を深く知る」を参照してください。

手順 4: 構成が適用されていない理由を調査する

cloud-init のすべての障害で、致命的なプロビジョニング エラーが発生するわけではありません。 たとえば、cloud-init 構成で runcmd モジュールを使用する場合、コマンドから 0 以外の終了コードを指定すると、VM のプロビジョニングが失敗します。 この動作は、cloud-init の最初の 3 つのステージでコア プロビジョニング手順の後にモジュールが実行されるために発生します。 構成が適用されなかった理由をトラブルシューティングするには、手順 3 のログと cloud-init モジュールを手動で確認します。 例えば次が挙げられます。

• runcmd - スクリプトはエラーなしで実行されますか。 期待どおりに実行されるようにするには、ターミナルから手動で構成を実行します。
• パッケージのインストール - VM はパッケージ リポジトリにアクセスできますか。
• VM に提供された customData 構成を確認します。 このファイルは /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt にあります。

次のステップ

cloud-init が構成をスキップする場合は、各 cloud-init ステージとモジュール実行のタイミングを調べて原因を特定します。 詳細については、 cloud-init 構成の詳細を参照してください。