Azure でのイメージング用に Linux を準備する

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

Azure プラットフォームサービスレベルアグリーメント (SLA) は、動作保証済みディストリビューションのいずれか 1 つを使用する場合にのみ、Linux オペレーティングシステムを実行している仮想マシン (VM) に適用されます。動作保証済みディストリビューションの場合、事前構成済みの Linux イメージが Azure Marketplace で提供されています。詳細については、以下を参照してください:

コミュニティでサポートされているものや動作保証されていないものなど、Azure で実行されている他のすべてのディストリビューションには、いくつかの前提条件があります。

この記事では、Azure 上で Linux ディストリビューションを実行するための一般的なガイダンスについて、重点的に説明します。ディストリビューションはそれぞれ異なるため、この記事ですべてを網羅することはできません。この記事で説明するすべての条件を満たしていても、Linux システムを適切に実行するには、大幅な調整が必要になる場合があります。

Linux のインストールに関する一般的な注記

Important

この記事のリモート NVMe 準備手順は省略可能です。リモート NVMe ディスクコントローラーを使用してデプロイするイメージを作成する場合にのみ、これらを完了します。ターゲット VM で SCSI が使用されている場合は、リモート NVMe のラベルが付いているすべての手順をスキップし、標準設定を保持します。リモート NVMe には、Gen2 イメージとサポートされているオペレーティングシステムのバージョンが必要です。正確なターゲット VM サイズの DiskControllerTypes 機能を確認し、リモート NVMe でサポートされている OS イメージを確認します。 VM シリーズの生成からのみコントローラーの種類を推測しないでください。

Azure では、Hyper-V 仮想ハードディスク (VHDX) 形式はサポートされていません。 Azure でサポートされるのは、容量固定の VHD のみです。 Hyper-V マネージャーまたは Convert-VHD コマンドレットを使用して、ディスクを VHD 形式に変換できます。 VirtualBox を使用する場合は、ディスクの作成時に、既定 (動的に割り当て) ではなく、固定サイズを選択します。
Azure では、Gen1 (BIOS ブート) および Gen2 (UEFI ブート) 仮想マシンがサポートされています。
仮想ファイル割り当てテーブル (VFAT) カーネルモジュールを、カーネルで有効にする必要があります。
VHD のサイズの上限は、1,023 GB です。
Linux システムをインストールする場合は、Logical Volume Manager (LVM) ではなく、標準パーティションを使用することをお勧めします。 LVM は、多くのインストールで既定になっています。

標準パーティションを使用することにより、特に OS ディスクをトラブルシューティングのために別の同じ VM に接続する場合に、LVM 名と複製された VM の競合が回避されます。 LVM または RAID をデータディスク上で使用できます。
ユーザー定義関数 (UDF) ファイルシステムをマウントするためのカーネルサポートが必要です。 Azure での最初の起動時に、UDF でフォーマットされた、ゲストに接続されているメディアを介して、プロビジョニング構成が Linux VM に渡されます。 Azure Linux エージェントは、その構成を読み取り、VM をプロビジョニングする UDF ファイルシステムをマウントする必要があります。
2.6.37 より前の Linux カーネルバージョンは、Hyper-V で大きい VM サイズの Non-Uniform Memory Access (NUMA) をサポートしていません。この問題は、主に、アップストリームの Red Hat 2.6.32 カーネルを使用している以前のディストリビューションに影響します。これは Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504) で修正されました。

2.6.37 より古いカスタムカーネル、または 2.6.32-504 より古い RHEL ベースのカーネルを実行しているシステムでは、numa=off 内のカーネルコマンドラインでブートパラメーターを設定する必要があります。詳細については、Red Hat KB 436883 を参照してください。
OS ディスクにスワップパーティションを構成しないでください。この記事で後述するとおり、一時的なリソースディスク上にスワップファイルを作成するように Linux エージェントを構成できます。
Azure の VHD の仮想サイズはすべて、1 MB (1024 × 1024 バイト) に整列されている必要があります。 RAW ディスクから VHD に変換するときは、この記事で後述するように、変換前の RAW ディスクのサイズが 1 MB の倍数であることを確認してください。
最新の配布バージョン、パッケージ、およびソフトウェアを使用します。
ユーザーとシステムアカウント、公開キー、機密データ、不要なソフトウェアとアプリケーションを削除します。

注記

cloud-init バージョン 21.2 以降では、UDF の要件がなくなります。ただし、udf モジュールが有効になっていないと、プロビジョニング中に CD-ROM がマウントされず、カスタムデータが適用されません。これを回避するには、ユーザーデータを適用します。ただし、カスタムデータとは異なり、ユーザーデータは暗号化されません。詳しくは、cloud-init のドキュメントの「ユーザーデータの形式」をご覧ください。

Hyper-V を使用しないカーネルモジュールのインストール

Azure は、Hyper-V ハイパーバイザーで実行されるため、Linux で Azure を実行するには特定のカーネルモジュールが必要です。 Hyper-V 以外で作成された VM を所有している場合、Hyper-V 環境で実行していることが VM で検出されない限り、Linux インストーラーの初期 RAM ディスク (initrd または initramfs) に Hyper-V 用のドライバーが含まれない場合があります。

別の仮想化システム (Virtualbox や KVM など) を使用して Linux イメージを準備する場合は、少なくとも hv_vmbus と hv_storvsc のカーネルモジュールを初期 RAM ディスクで使用できるように initrd の再構築が必要になる場合があります。これは、アップストリームの Red Hat ディストリビューションに基づくシステムの既知の問題ですが、その他のシステムでも発生する可能性があります。

initrd または initramfs イメージの再構築のためのメカニズムは、ディストリビューションによって異なる場合があります。適切な手順については、使用しているディストリビューションのドキュメントまたはサポートを参照してください。次は、mkinitrd ユーティリティを使用して initrd を再構築する 1 つの例です。

既存の initrd イメージをバックアップします。

cd /boot
sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak

hv_vmbus と hv_storvsc のカーネルモジュールを使用して initrd を再構築します。
```
sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`
```

VHD のサイズ変更

Azure の VHD イメージは、1 MB に整列された仮想サイズが必要です。通常、Hyper-V を使用して作成された VHD は正しく整列されています。 VHD が正しく整列されていない場合は、VHD からイメージを作成しようとすると、次の例のようなエラーメッセージが表示される場合があります。

The VHD http://<mystorageaccount>.blob.core.windows.net/vhds/MyLinuxVM.vhd has an unsupported virtual size of 21475270656 bytes. The size must be a whole number (in MBs).

この場合、Hyper-V マネージャーコンソールまたは Resize-VHD PowerShell コマンドレットを使用して、VM のサイズを変更できます。 Windows 環境で実行していない場合は、qemu-img を使用して変換し (必要な場合)、VHD のサイズを変更することをお勧めします。

注記

QEMU バージョン 2.2.1 およびそれ以降の一部のバージョンでは、qemu-img に既知のバグがあり、VHD が適切にフォーマットされません。この問題は QEMU 2.6 で修正されました。バージョン 2.2.0 以前を使用するか、バージョン 2.6 以降を使用することをお勧めします。

qemu-img や vbox-manage などのツールを使用して直接 VHD のサイズを変更すると、VHD が起動できなくなる可能性があります。最初に以下のコードを使用して VHD を RAW ディスクイメージに変換することをお勧めします。

VM イメージを RAW ディスクイメージとして作成した場合は、このステップをスキップできます。 VM イメージを RAW ディスクイメージとして作成することは、KVM などの一部のハイパーバイザーで既定になっています。
```
sudo qemu-img convert -f vpc -O raw MyLinuxVM.vhd MyLinuxVM.raw
```
仮想サイズが 1 MB に整列されるように、ディスクイメージの必要なサイズを計算します。次の Bash シェルスクリプトは qemu-img info を使用してディスクイメージの仮想サイズを決定し、次の 1 MB までサイズを計算します。
```
rawdisk="MyLinuxVM.raw"
vhddisk="MyLinuxVM.vhd"

MB=$((1024*1024))
size=$(qemu-img info -f raw --output json "$rawdisk" | \
gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')

rounded_size=$(((($size+$MB-1)/$MB)*$MB))

echo "Rounded Size = $rounded_size"
```
$rounded_size を使用して RAW ディスクのサイズを変更します。
```
sudo qemu-img resize MyLinuxVM.raw $rounded_size
```

RAW ディスクを固定サイズの VHD に変換します。

sudo qemu-img convert -f raw -o subformat=fixed,force_size -O vpc MyLinuxVM.raw MyLinuxVM.vhd

または、2.6 より前の QEMU バージョンでは、force_size オプションを削除します。

sudo qemu-img convert -f raw -o subformat=fixed -O vpc MyLinuxVM.raw MyLinuxVM.vhd

Linux カーネルの要件

Hyper-V および Azure 用の Linux Integration Services (LIS) ドライバーは、アップストリームの Linux カーネルに直接提供されています。最新の Linux カーネルバージョン (3.x など) を含む多くのディストリビューションでこれらのドライバーが含まれています。含まれていない場合は、これらのドライバーのバックポートされたバージョンがカーネルと共に提供されます。

LIS ドライバーは、アップストリームのカーネルで新しい修正と機能を含んだ形で常に更新されています。可能な場合は、これらの修正と更新を含む動作保証済みディストリビューションを実行することをお勧めします。

RHEL バージョン 6.0 から 6.3 のバリアントを実行する場合は、Hyper-V 用の最新のLIS ドライバーをインストールする必要があります。 RHEL 6.4 以降 (および派生版) では、LIS ドライバーは既にカーネルに含まれているため、追加のインストールパッケージは必要ありません。

カスタムカーネルが必要な場合は、最新のカーネルバージョン (3.8 以降など) をお勧めします。独自のカーネルを維持するディストリビューションまたはベンダーの場合は、アップストリームのカーネルの LIS ドライバーをカスタムカーネルに定期的にバックポートする必要があります。

比較的新しいカーネルバージョンを既に実行している場合でも、LIS ドライバーのアップストリームの修正を常に追跡し、必要に応じてパックポートすることを強くお勧めします。 LIS ドライバーのソースファイルの場所は、次の Linux カーネルのソースツリーの MAINTAINERS ファイルに記載されています。

    F:    arch/x86/include/asm/mshyperv.h
    F:    arch/x86/include/uapi/asm/hyperv.h
    F:    arch/x86/kernel/cpu/mshyperv.c
    F:    drivers/hid/hid-hyperv.c
    F:    drivers/hv/
    F:    drivers/input/serio/hyperv-keyboard.c
    F:    drivers/net/hyperv/
    F:    drivers/scsi/storvsc_drv.c
    F:    drivers/video/fbdev/hyperv_fb.c
    F:    include/linux/hyperv.h
    F:    tools/hv/

VM のアクティブなカーネルには、次のパッチが含まれている必要があります。この一覧はすべてのディストリビューションを完全に網羅するものではありません。

Azure Linux エージェント

Azure Linux エージェント (waagent) は Azure で Linux仮想マシンをプロビジョニングします。 Linux Agent GitHub リポジトリで、最新バージョンの取得、問題の報告、pull request の提出ができます。

以下は、Azure Linux エージェントを使用するときの注意点です。

Linux エージェントは、Apache 2.0 ライセンス下でリリースされています。数多くのディストリビューションでは、このエージェント用の .rpm または .deb パッケージが既に提供されています。これらのパッケージを簡単にインストールして更新できます。
Azure Linux エージェントには、Python v2.6 以上が必要です。
このエージェントには、python-pyasn1 モジュールも必要です。ほとんどのディストリビューションでは、インストール可能な個別のパッケージとしてこのモジュールを提供しています。
Azure Linux エージェントは NetworkManager と互換性がない場合があります。ディストリビューションによって提供されるパッケージ (.rpm または .deb) の多くは、NetworkManager を waagent パッケージとの競合として構成します。このような場合、Linux エージェントパッケージをインストールすると、NetworkManager はエージェントによってアンインストールされます。
Azure Linux エージェントは、サポートされている最小バージョン以上である必要があります。

注記

udf および vfat モジュールが有効になっていることを確認します。 udf モジュールを無効にすると、プロビジョニングエラーが発生します。 vfat モジュールを無効にすると、プロビジョニングと起動の両方のエラーが発生します。 cloud-init バージョン 21.2 以降では、次の両方の条件に当てはまる場合、UDF を必要とせずに VM をプロビジョニングできます。

パスワードではなく SSH 公開キーを使用して VM を作成した。
カスタムデータを提供しなかった。

Linux システムの一般的な要件

GRUB または GRUB2 のカーネルブートラインを変更して次のパラメーターを含め、すべてのコンソールメッセージが最初のシリアルポートに送信されるようにします。これらのメッセージは、Azure Support での問題のデバッグに役立ちます。
```
GRUB_CMDLINE_LINUX="rootdelay=300 console=ttyS0 earlyprintk=ttyS0 net.ifnames=0"
```
また、次のパラメーターがある場合、それらを "削除" することをお勧めします。
```
rhgb quiet crashkernel=auto
```
クラウド環境では、すべてのログをシリアルポートに送信するため、グラフィカルブートとクワイエットブートは役立ちません。必要に応じて crashkernel オプションは構成したままにすることができますが、このパラメーターにより、VM 内の使用可能なメモリ量が 128 MB 以上減少します。使用可能メモリの減少は、比較的小さいサイズの VM では問題になる可能性があります。
/etc/default/grub の編集が完了したら、GRUB 構成をリビルドします。ディストリビューションに適したコマンドのみを実行します。

Debian または Ubuntu に基づくディストリビューションの場合は、次を実行します。
```
sudo update-grub
```
RHEL、Oracle Linux、SUSE などの grub2-mkconfigを提供するディストリビューションの場合は、次を実行します。
```
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
```
代わりに grub-mkconfig を提供するディストリビューションでは、次のコマンドを実行します。
```
sudo grub-mkconfig -o /boot/grub/grub.cfg
```
GRUB 構成パスは、UEFI のインストールで異なる場合があります。ディストリビューションで別のパスを使用する場合は、そのディストリビューションに記載されているパスを使用します。
Hyper-V モジュールを初期 RAM ディスクに追加します。ディストリビューションで使用されているツールに一致するプロシージャのみを実行します。
1. dracut ベースのディストリビューションの場合は、次を実行します。
```
cd /boot
sudo cp initramfs-<kernel-version>.img <kernel-version>.img.bak
sudo dracut -f -v initramfs-<kernel-version>.img <kernel-version> --add-drivers "hv_vmbus hv_netvsc hv_storvsc"
```
1. mkinitramfsを使用するディストリビューションの場合は、dracut プロシージャの代わりに次のプロシージャを実行します。
```
cd /boot
sudo cp initrd.img-<kernel-version> initrd.img-<kernel-version>.bak
sudo mkinitramfs -o initrd.img-<kernel-version> <kernel-version> --with=hv_vmbus,hv_netvsc,hv_storvsc
```
リモート NVMe ディスクコントローラーのイメージを作成する場合にのみ、NVMe ブートのサポートを構成して確認します。それ以外の場合、この手順はスキップしてください。正確なコマンドはディストリビューションによって異なる場合があります。
1. お使いのディストリビューションに対応した方法で、NVMe ドライバーを含めて initramfs を再構築します。
  
  dracut ベースのディストリビューションの場合、NVMe ドライバーを将来の initramfs イメージで永続的にし、現在の initramfs を再構築します。
```
sudo mkdir -p /etc/dracut.conf.d
printf '%s\n' 'add_drivers+=" nvme nvme_core "' | sudo tee /etc/dracut.conf.d/azure-nvme.conf
sudo dracut --force
```
  initramfs-tools ベースのディストリビューションの場合は、NVMe ドライバーを永続的にし、initramfs を再構築します。
```
printf '%s\n' nvme nvme_core | sudo tee -a /etc/initramfs-tools/modules
sudo update-initramfs -u -k all
```
2. /etc/default/grubの既存のカーネルコマンドラインにnvme_core.io_timeout=240を追加し、ディストリビューションに適したコマンドを使用して GRUB 構成を再構築します。
3. 両方の NVMe ドライバーモジュールがシステムで使用可能であることを確認します。両方のコマンドを実行します。
```
modinfo nvme
modinfo nvme_core
```
  各コマンドは、そのモジュールに関する情報を返す必要があります。いずれかのモジュールが見つからない場合は、続行する前に、ディストリビューションのドキュメントに従ってモジュールをインストールまたは有効にします。
4. 両方の NVMe ドライバーが initramfs に含まれていることを確認します。ディストリビューションのコマンドのみを実行します。
  
  dracut ベースのディストリビューションの場合は、次を実行します。
```
sudo lsinitrd /boot/initramfs-$(uname -r).img | grep -E 'nvme(_core)?\.ko'
```
  initramfs-tools ベースのディストリビューションの場合は、次を実行します。
```
sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'nvme(_core)?\.ko'
```
  出力には、 nvme ドライバーと nvme_core ドライバーの両方が表示されている必要があります。そうでない場合は、ディストリビューションのドキュメントを参照し、最初の RAM ディスクをリビルドしてから続行してください。
SSH サーバーがインストールされており、起動時に開始するように構成されていることを確認します。この構成が通常の既定です。
Azure Linux エージェントをインストールします。

Azure Linux エージェントは、Azure で Linux イメージをプロビジョニングするために必要です。数多くのディストリビューションでは、このエージェントが .rpm または .deb パッケージとして提供されています。通常、パッケージは WALinuxAgent または walinuxagent と呼ばれます。このエージェントは、Azure Linux エージェントガイドの手順に従って手動でもインストールできます。

注記

udf および vfat モジュールが有効になっていることを確認します。それらを削除または無効化すると、プロビジョニングまたは起動が失敗します。 cloud-init バージョン 21.2 以降では、UDF の要件がなくなります。

Azure Linux エージェント、cloud-init、およびその他の必要なユーティリティをインストールします。システムで使用可能なパッケージ・マネージャーのコマンドのみを実行します。

dnfの場合は、次のコマンドを実行します。
```
 sudo dnf install -y WALinuxAgent cloud-init cloud-utils-growpart gdisk hyperv-daemons
```
システムがdnfではなくyumを提供する場合は、dnfを前のコマンドのyumに置き換えます。

aptの場合は、次のコマンドを実行します。
```
sudo apt install walinuxagent cloud-init cloud-utils-growpart gdisk hyperv-daemons
```
zypperの場合は、次のコマンドを実行します。
```
sudo zypper install python-azure-agent cloud-init cloud-utils-growpart gdisk hyperv-daemons
```
その後、すべてのディストリビューションでエージェントと cloud-init を有効にします。
```
sudo systemctl enable waagent.service
sudo systemctl enable cloud-init.service
```
OS ディスクにスワップ領域を作成しないでください。

Azure Linux エージェントまたは cloud-init を使用して、ローカルリソースディスクでスワップ領域を構成できます。 Azureプロビジョニング後にこのリソースディスクを VM に接続します。ローカルリソースディスクは一時的であり、VM のプロビジョニング解除時に空になる可能性があります。

Important

これらの手順は、リモートディスクコントローラーが SCSI か NVMe かを適用します。ローカルの一時リソースディスクを含む VM サイズが必要です。リモートディスクコントローラーの種類では、リソースディスクが使用可能かどうかが判断されません。
1. スワップ領域を管理する方法を 1 つ選択して構成します。
  
  Azure Linux エージェントを使用するには、/etc/waagent.conf で次のパラメーターを変更します。
```
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048    ## NOTE: Set this to your desired size.
```
  代わりに cloud-init を使用するには、プロビジョニングを処理するように cloud-init を構成し、Azure Linux エージェントがリソースディスクをフォーマットしたり、スワップ領域を作成したりしないようにします。
```
sudo sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf
sudo sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf
sudo sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf
```
2. cloud-init を選択した場合は、スワップ構成を提供する方法を選択します。
  
  VM を作成するたびに、 customdata を介して cloud-init 構成を渡すことができます。このメソッドを使用します。
  
  または、VM が作成されるたびにスワップ領域が構成されるように、イメージに cloud-init ディレクティブを追加します。このメソッドを使用するには、.cfg ファイルを作成します。
```
echo 'DefaultEnvironment="CLOUD_CFG=/etc/cloud/cloud.cfg.d/00-azure-swap.cfg"' | sudo tee -a /etc/systemd/system.conf
cat << EOF | sudo tee /etc/cloud/cloud.cfg.d/00-azure-swap.cfg
#cloud-config
# Generated by Azure cloud image build
disk_setup:
  ephemeral0:
    table_type: mbr
    layout: [66, [33, 82]]
    overwrite: True
fs_setup:
  - device: ephemeral0.1
    filesystem: ext4
  - device: ephemeral0.2
    filesystem: swap
mounts:
  - ["ephemeral0.1", "/mnt/resource"]
  - ["ephemeral0.2", "none", "swap", "sw,nofail,x-systemd.requires=cloud-init.service,x-systemd.device-timeout=2", "0", "0"]
EOF
```

プロビジョニングを処理するように cloud-init を構成します。

cloud-init に対して waagent を構成します。

sudo sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf
sudo sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf
sudo sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf

特定の仮想マシンを移行する場合で、汎用化されたイメージを作成したくない場合は、Provisioning.Agent=disabled 構成ファイルでを設定します。

マウントを構成します。

echo "Adding mounts and disk_setup to init stage"
sudo sed -i '/ - mounts/d' /etc/cloud/cloud.cfg
sudo sed -i '/ - disk_setup/d' /etc/cloud/cloud.cfg
sudo sed -i '/cloud_init_modules/a\\ - mounts' /etc/cloud/cloud.cfg
sudo sed -i '/cloud_init_modules/a\\ - disk_setup' /etc/cloud/cloud.cfg

Azure データソースを構成します:

echo "Allow only Azure datasource, disable fetching network setting via IMDS"
cat << EOF | sudo tee /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg
datasource_list: [ Azure ]
datasource:
   Azure:
     apply_network_config: False
EOF

既存のスワップファイルを構成した場合は、削除します。

if [[ -f /mnt/resource/swapfile ]]; then
echo "Removing swapfile" #RHEL uses a swap file by default
swapoff /mnt/resource/swapfile
rm /mnt/resource/swapfile -f
fi

cloud-init のログを構成します。

echo "Add console log file"
cat << EOF | sudo tee -a /etc/cloud/cloud.cfg.d/05_logging.cfg

# This tells cloud-init to redirect its stdout and stderr to
# 'tee -a /var/log/cloud-init-output.log' so the user can see output
# there without needing to look on the console.
output: {all: '| tee -a /var/log/cloud-init-output.log'}
EOF

仮想マシンのプロビジョニングを解除する前に、ディスクマウント構成を検証します。この検証は、SCSI イメージとリモート NVMe イメージの両方に適用されます。
1. /etc/fstabを確認します。再起動やディスクコントローラーの変更時にデバイス名が変更される可能性があるため、 /dev/sd* や /dev/nvme*などのデバイス名は使用しないでください。代わりに、ファイルシステム UUID またはその他の永続的な識別子を使用してください。
  
  ブロックデバイスとその永続的な識別子を一覧表示して、 /etc/fstabのエントリと比較できるようにします。
```
sudo blkid
```
2. /etc/fstab構文エラー、無効なマウントオプション、解決できない参照を確認します。
```
sudo findmnt --verify --verbose
```
3. リモート NVMe ディスクコントローラーのイメージを作成する場合にのみ、構成された I/O タイムアウトを確認します。ソース VM で現在 NVMe が使用されている場合は、次を実行します。
```
cat /sys/module/nvme_core/parameters/io_timeout
```
  値は 240 である必要があります。 SCSI ソース VM では、このランタイムパラメーターが公開されない場合があります。その場合は、が GRUB 構成に存在し、再構築された構成に含まれていることを確認します。
次のコマンドを実行して仮想マシンをプロビジョニング解除します。

注意事項

特定の仮想マシンを移行していて、一般化されたイメージを作成しない場合は、プロビジョニング解除のステップをスキップしてください。コマンド waagent -force -deprovision+user を実行すると、ソースマシンが使用できなくなります。この手順は一般化されたイメージを作成することのみを目的としています。
```
sudo rm -f /var/log/waagent.log
sudo cloud-init clean
sudo waagent -force -deprovision+user
sudo rm -f ~/.bash_history
sudo export HISTSIZE=0
```
VirtualBox では、waagent -force -deprovision 実行後に [Errno 5] Input/output error というエラーメッセージが表示されることがあります。このエラーメッセージは重要ではないため、無視してかまいません。
仮想マシンをシャットダウンし、Azure に VHD をアップロードします。

次のステップ

Azure CLI を使用してカスタムディスクから Linux VM を作成する

SCSI から NVMe に移行する必要がある既存のAzure VM の場合は、Linux を変換し、WINDOWS VM を SCSI から NVMe に変換します。アーキテクチャとサポート情報については、 NVMe の概要を参照してください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-24