Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions articles/vm/keep-troubled-vm.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
title: VM の削除前に残すべき情報
date: 2026-06-15 12:00
updated: 2026-06-15 15:50
tags:
- VM
- HowTo
---
こんにちは、Azure IaaS サポートの前田です。

弊チームでは Azure VM のデプロイや特定の操作に失敗する、または、Azure VM の状態に関する調査依頼を頂戴することがございます。
一方で、VM やその他証跡が既に削除されているなどの理由で調査に必要な情報が残っていないことにより、原因について調査やご案内が叶わず、原因不明のままサポートがクローズとなってしまう場合も多くございます。

本記事では、Azure VM や各リソースの状態に関する調査をご希望の場合に、どのように情報保全を行うべきかという点についてご案内いたします。

なお、Azure サポートでは発生事象に対する障害対応 (Break & Fix) が原則となります。また、以下の内容をご提供いただくことによる解決や原因究明をお約束するものではございません。
円滑な技術サポートへのお問い合わせとするための、ご参考としてお考えいただきますようお願いいたします。

ご参考:[Azure サポートにおけるアドバイザリ (ハウツーやベストプラクティス共有) のお問い合わせにつきまして | Japan Azure IaaS Core Support Blog](https://jpaztech.github.io/blog/information/advisory-inquiries-in-the-Azure-Support/)

<!-- more -->

## 目次
- はじめに:なぜリソースの削除が調査の障害になるのか
- 調査のために保全いただきたいリソースや情報について
- お問い合わせ後に依頼させていただく可能性のある事項
- おわりに

## はじめに:なぜリソースの削除が調査の障害になるのか
Azure 基盤では、お客様の情報を適切に保護する観点より、削除されたリソースの情報へのアクセスは非常に限定的、または実行不能となります。このため、お客様環境にて何らかの問題が発生した際に、そのリソースが削除されてしまうことによって、サポートからの原因調査のご支援が困難となるシナリオがございます。

具体的には、以下のような事象が該当いたします。
- Azure VM のデプロイ時にエラーが発生したため、問題の VM を削除して新しい VM を作成した
- 利用している Azure VM が急に起動しなくなり、再構築を行ったがその後問題の VM リソースを削除した
- Azure Compute Gallery のイメージを用いて VM を新規作成した際に問題が発生したが、イメージの作成時に利用した VM は削除済みであった

## 調査のために保全いただきたいリソースや情報について
Azure VM のリソースの状態に対する調査をご希望の場合、以下の内容を依頼することが多くございます。
これらが全てではございませんが、予めお手元にご準備いただき、お問い合わせ内容に含めていただくことでサポートでの円滑な調査が可能となります。

### 原則として例外なく調査に必要な情報
- 問題が発生したリソースのリソース ID ※ Azure Portal からのお問い合わせ起票時に紐づけいただくことが可能です
- 事象発生日時および発生頻度
- 発生した事象の詳細 (例:エラー メッセージ、問題が発生している画面のスクリーンショットなど)
- エラーに至るまでの操作内容

### 調査をより円滑に行うために必要、または特定のシナリオにおいて必須となる情報
- 発生事象への解決を必要とする背景や、最終的にどのような状態にされたいかのご要望
- 正常に稼働したことがある環境か、または一度も正常に稼働していない環境か
- 事象の再現性 (例:事象が再現しない、条件が明確で任意に再現可能、頻繁に再現するか条件が不明 など)
- 事象の発生前後にて実施した、関連の Azure リソースまたはゲスト OS 上への設定変更の有無
- 事象に関連するリソースが他にもある場合、そのリソースのリソース ID

リソース ID の確認方法につきましては、以下の技術ブログをご参照ください。

ご参考:[サブスクリプション ID とリソース ID の確認について | Japan Azure IaaS Core Support Blog](https://jpaztech.github.io/blog/information/Subscription-ID-verification/)

なお、いくつかの項目につきましては、サポート リクエストを Azure Portal から起票いただく際の画面上にて、同様の内容が表示されます。この際、弊社基盤側からの調査に必要な情報が不足している場合は、結果としてご対応にお時間をいただいてしまう可能性がございます。

お手間である点は重々承知ではございますが、お急ぎの際も先述の内容を参考に、可能な限り詳細に発生事象について記載いただくことをお勧めいたします。

ご参考:[お問い合わせの発行方法について | Japan Azure IaaS Core Support Blog](https://jpaztech.github.io/blog/information/How-to-inquiry-to-the-Azure-Support/)

## お問い合わせ後に依頼させていただく可能性のある事項
お問い合わせにより異なる部分ではございますが、Azure VM の状態に対する調査では、一般に以下内容を依頼させていただくことが多くございます。

事象の切り分けや、弊社基盤側からの情報取得にあたり必要な事項となりますことから、実施が難しい環境におきましては調査内容が限定される場合がございますので、予めご理解のほどよろしくお願いいたします。

- リソースの状態を変更せず、お問い合わせ時のまま保持いただく
- 問題が発生した VM について、割り当て解除せずに起動状態を保持いただく
- リソースやゲスト OS に対し、お客様のお手元での設定変更や、再度問題が発生した際と同様の操作を依頼する

## おわりに
弊社基盤側より確認可能なログにつきましては、原則として一定期間内にてローテーションが発生いたします。
このため、問題の発生後、お手元の切り分けにおいても事象が改善しない場合、上記情報と共に数日以内を目途として可能な限り速やかにお問い合わせいただくことをお勧めしております。

本記事の内容が技術サポートへの円滑なお問い合わせのご参考となりましたら幸いでございます。
Loading