RHEL 9.4 を SMC で Alibaba Cloud へ移行した後に起動に失敗する問題

0x01 問題の概要

オンプレミスのサーバーを Alibaba Cloud（アリババクラウド）の SMC（Server Migration Center）で ECS へ移行したところ、作成した ECS が起動に失敗しました。VNC で確認すると、OS が起動時のローディングアニメーションのまま止まっています。

移行の流れは次のとおりです。SMC を使ってまずオンプレミスのサーバーを Alibaba Cloud ECS のカスタムイメージとして取り込み、そのカスタムイメージから ECS を作成します。

移行元（オンプレミス環境）は、システム領域（/boot・/・/var）とデータ領域（/db）がいずれも LVM 上にあり、これとは別に swap パーティション（/dev/sda1）を持つ構成です。blkid の出力は以下のとおりです。

/dev/mapper/rhel-var: UUID="38511531-8a41-4514-9aa8-df83a8dafafd" TYPE="xfs"
/dev/sdd1: UUID="S38k2p-nQyq-98D3-1F19-mb9v-7i1D-JCfn4I" TYPE="LVM2_member" PARTUUID="4458b648-01"
/dev/sdb2: UUID="485B-D988" TYPE="vfat" PARTUUID="43b84253-02"
/dev/sdb1: UUID="d49856a9-31d6-4e25-8d1f-8b3b4a6b195d" TYPE="xfs" PARTUUID="43b84253-01"
/dev/mapper/db-data: UUID="6b6af6c3-fb4e-434e-9fd7-aa4169a22e4d" TYPE="xfs"
/dev/mapper/rhel-root: UUID="f8c7fece-6131-4b40-8339-906761a96570" TYPE="xfs"
/dev/sdc: UUID="Giumx5-1oGw-ltWK-Dg2z-vWcv-Gkei-G3MO4P" TYPE="LVM2_member"
/dev/sda1: UUID="e96b1ffd-bd8b-4a15-9aac-a62264f2437d" TYPE="swap" PARTUUID="0b72d651-01"

0x02 問題発生までの経緯

00x01 サーバーをイメージ化する

Alibaba Cloud の SMC コンソールでコマンドラインインポート用のアクティベーションコードを生成し、移行元サーバー上でそのコマンドを実行して移行元を登録します。

画面に Please Goto SMC Console To Create New Job と表示されたら、SMC コンソールに戻って移行ジョブを作成します。

移行ジョブを作成し、オンプレミスのサーバーをイメージ化します。その際、LVM を有効にします。

00x02 ECS を作成する

移行で生成されたカスタムイメージを指定して ECS を作成します。

ECS は作成後に自動で起動し、その直後に冒頭の問題が発生しました。

0x03 問題の調査

VNC で接続し、起動中にいずれかの矢印キーを押して、テキスト形式の起動ログ画面に切り替えます。

0x04 原因の分析

00x01 SMC 移行で変わるもの・変わらないもの

000x01 SMC が行うこと

• ブロック単位／ファイル単位で移行元ディスクのデータをクラウドディスクへ移し、移行設定に従ってパーティション構成を組み替える（移行元の 4 台のディスク → 移行先ではシステムディスク vda とデータディスク vdb、といった構成）
• 仮想化関連ドライバーの置き換えと、Alibaba Cloud の初期化コンポーネントの組み込み
• 末尾に smcs_bak_<日時> が付いた GRUB バックアップエントリー（BLS）を新たに生成

000x02 SMC が行わないこと（障害の根本原因）

• カーネルコマンドラインを書き換えない：移行元の resume=UUID=… が一字一句そのまま移行先へ持ち込まれる
• /etc/lvm/devices/system.devices を更新しない：移行元ディスクの ID（sys_serial / WWID など）が記録されたまま
• NetworkManager の接続設定を書き換えない：移行元の interface-name=ens33 と移行元の MAC アドレスに紐付いたまま

一方、移行後の環境では、ディスクのシリアル番号／WWID、NIC 名、MAC アドレスがすべて変わり、swap パーティションに至っては丸ごと存在しないこともあります。その結果、「設定に記録された古い識別情報」と「実環境の新しい識別情報」が一致せず、システムは起動の初期段階で、永遠に現れないものを待ち続けることになります。

00x02 問題の確認

以下のコマンドを SMC の移行元環境で実行すると、移行前に問題の有無を確認できます。

Q1 について：cat /proc/cmdline と swapon --show --output NAME,TYPE,SIZE,UUID をそれぞれ実行し、両方の出力を突き合わせます。cat /proc/cmdline に resume=UUID=<UUID> が含まれ、かつその UUID が swapon の出力に表示される UUID と一致する場合、移行後にローディングアニメーションのまま停止する問題が発生します。

Q2 について：lvmconfig --type full devices/use_devicesfile を実行し、出力が use_devicesfile=1 で、かつ /etc/lvm/devices/system.devices が存在する場合、Alibaba Cloud のデータディスクへ移行した LVM がマウントできなくなるおそれがあります。

Q3 について：nmcli -f NAME,UUID,TYPE,DEVICE,FILENAME connection show を実行して現在アクティブな接続の DEVICE 列を確認し、さらに grep -RH -E '^(interface-name|mac-address)=' /etc/NetworkManager/system-connections/ で NetworkManager の詳細設定を走査して、eth0 にマッチする設定項目があるかを確認します。マッチするものがない場合、移行後にネットワークに接続できなくなります。

00x03 問題のまとめ

0x05 問題の修復

00x01 Q1 への対処

000x01 起動を復旧する

1. VNC が接続済みであることを確認する
2. ECS コンソールで「再起動」をクリックする
3. GRUB メニューが表示されたら、矢印キーを押してカウントダウンを止める
4. e キーを押して編集モードに入る

以下の内容を削除し、Ctrl+X で起動します。

resume=UUID=e96b1ffd-bd8b-4a15-9aac-a62264f2437d

これでサーバーは正常に起動します。ただし GRUB 編集画面での変更は一時的なものなので、続けてデフォルトの起動パラメーターを修正します。

000x02 GRUB のデフォルトパラメーターを修正する

grubby で該当する起動パラメーターを削除します。grub2-mkconfig による grub.cfg の再生成は任意です。

grubby --update-kernel=ALL --remove-args="resume=UUID=<UUID>"
grub2-mkconfig -o /boot/grub2/grub.cfg   # 省略可

あわせて /etc/default/grub の GRUB_CMDLINE_LINUX からも resume=UUID=… を削除しておきます。grubby はこのファイルを更新しないため、残したままだと将来 grub2-mkconfig を実行した際にパラメーターが復活します。

grep resume /etc/default/grub
sed -i 's/ \?resume=UUID=[^ "]*//' /etc/default/grub

検証：以下のコマンドを実行し、出力のうちファイル名の末尾が smcs_bak_<日時> のバックアップエントリーにのみ resume=UUID=<UUID> が含まれていることを確認します。

grep -R 'resume' /boot/grub2/grub.cfg /boot/loader/entries

00x02 Q2 への対処

起動後に lsblk と df -h を確認すると、vdb1 上の LVM ボリュームがアクティブ化されておらず、/db が存在しません。

RHEL 9 以降、LVM ではデフォルトで use_devicesfile=1 が有効になっており、許可リストは /etc/lvm/devices/system.devices にあります。明示的に登録されたデバイスだけを使用し、自ホストに属さない LVM ボリュームを誤って認識・アクティブ化するのを防ぐための仕組みです。

まず lsblk でデバイス名を確認し、次に pvs --devices /dev/vdb1 で移行した LVM ボリュームの状態を確認し、最後に lvmdevices --adddev /dev/vdb1 で新しいデータディスクを許可リストに追加します。

lsblk
pvs --devices /dev/vdb1
lvmdevices --adddev /dev/vdb1

続いて、LVM ボリュームが起動時に自動でマウントされるよう /etc/fstab に登録します。

# デバイス名を確認
lsblk

# LV 上のファイルシステムの UUID を取得
DEVICE_UUID=$(blkid -s UUID -o value /dev/mapper/vg1-lv0)

# 起動時に自動マウントされるよう登録
mkdir -p /db
echo "UUID=${DEVICE_UUID}   /db    xfs   defaults    0 0" >> /etc/fstab

# 再起動前に fstab の記述を検証
mount -a && df -h /db

00x03 Q3 への対処

現象：ネットワーク接続に失敗し、SSH などで接続できず、インバウンド／アウトバウンド通信もできません。VNC から以下のコマンドで接続設定を追加します。

00x04 再起動して検証

1. reboot で再起動する
2. lsblk で /db がマウントされていることを確認する
3. ip -4 addr で eth0 が IP アドレスを取得していることを確認する

0x06 移行前の準備

同様の環境では、移行前に移行元システムの設定をあらかじめ調整しておくことで、Alibaba Cloud への SMC 移行後に上記の問題が発生するのを防げます。

00x01 resume=UUID パラメーターを削除する

カーネルコマンドラインの resume=UUID=<UUID> が移行元サーバーの swap パーティションを指していることを確認できた場合は、SMC 移行を実行する前にこのパラメーターを削除しておくことをお勧めします。

grubby --update-kernel=ALL --remove-args="resume=UUID=<UUID>"

今回確認できた情報に基づき、以下を実行します。

grubby --update-kernel=ALL --remove-args="resume=UUID=e96b1ffd-bd8b-4a15-9aac-a62264f2437d"

検証：以下のコマンドを実行し、resume=UUID=<swap パーティションの UUID> が出力されなくなったことを確認します。

grep -RH 'resume=' /boot/loader/entries/ /etc/default/grub

00x02 LVM の devices file（デバイス許可リスト）を削除する

lvmconfig --type full devices/use_devicesfile を実行して use_devicesfile=1 と表示され、かつ移行先のデータディスクでも LVM を引き続き使う場合は、移行前に古いデバイス許可リストを削除しておくことをお勧めします。

まず、既存の devices file をバックアップします。

mkdir -p /root/smc-backup
cp -a /etc/lvm/devices/system.devices /root/smc-backup/system.devices

次に、既存の許可リストを削除し、initramfs を再生成します。

rm -f /etc/lvm/devices/system.devices
dracut -f --regenerate-all

検証：以下のコマンドを実行し、出力に lvm.conf のみが含まれ、system.devices が含まれていないことを確認します。

lsinitrd /boot/initramfs-$(uname -r).img | grep -E 'system.devices|lvm.conf'

00x03 NetworkManager を事前設定する

SMC の移行先インスタンスで eth0 が使われることが確認できている場合は、移行前に NetworkManager のプロファイルを用意しておくことができます。

nmcli connection add type ethernet ifname eth0 con-name smc-eth0 ipv4.method auto connection.autoconnect yes

0x07 まとめ

Alibaba Cloud（アリババクラウド）の SMC はディスクの内容とパーティション構成を忠実に移してくれますが、移行元の識別情報に依存する OS 側の設定までは書き換えません。RHEL 9 系のサーバーを Alibaba Cloud ECS へ移行する際は、次の 3 点を移行前に点検しておくことをお勧めします。

• カーネルコマンドライン：swap を指す resume=UUID=… が残っていないか
• LVM の devices file：use_devicesfile=1 のまま移行元ディスクの ID が system.devices に固定されていないか
• NetworkManager：接続プロファイルが移行元の NIC 名・MAC アドレスにだけ紐付いていないか

いずれも移行前に数分で確認・修正できる項目です。移行後に起動しなくなった場合も、本記事の手順で GRUB・LVM・ネットワークの順に復旧できます。Alibaba Cloud への移行でお困りの際は、Cloud Navi までお気軽にご相談ください。