☰

既存の準仮想 Linux AMI から AWS HVM Linux AMI を作成する

tag-icon • tag-icon linux amazon-ec2 cloud-computing
既存の準仮想 Linux AMI から AWS HVM Linux AMI を作成する

既存の準仮想化 (PV) AMI からハードウェア仮想マシン (HVM) AMI を作成することは可能ですか。

当初の考えは、新しい PV インスタンスを起動し、ec2-create-imageコマンドを使用して仮想化タイプとして HVM を指定しながら新しいイメージを作成することでした。ただし、ec2-create-image仮想化タイプを指定するためのコマンド ライン パラメーターがありません。

これを行う別の方法はありますか?

答え1

アップデート

AWSはEC2 APIでこの機能を有効にしました。これは--virtualization-typeオプションとして利用できます。aws ec2 register-image新しい Boto ベースの awscli で。

元の回答

はい。残念ながら、直接行う方法はありません。また、一部の PV インスタンスでは、カーネルとブートローダーの変更が必要になる場合があります。

  1. 既存の PV AMI からボリュームを作成します。独自の PV AMI の場合は、スナップショットからボリュームを作成できます。サードパーティの AMI の場合は、インスタンスを起動してスナップショットを作成する必要があります。
  2. 任意の AMI を使用して HVM インスタンスを起動します。
  3. その HVM インスタンスを停止します。
  4. そのインスタンスからルート ボリュームを切り離します。
  5. PV ボリュームをルート ボリューム (/dev/sda1 またはパーティション化されている場合は /dev/sda) として HVM インスタンスに接続します。
  6. ec2-create-imageHVM インスタンス上で実行します。
  7. 新しい HVM AMI を使用して他のインスタンスを起動します。

それでも問題が解決しない場合は、手順 5 の前に、そのボリュームを実行中のインスタンスに接続し、chroot を設定し、ディストリビューションのカーネルとブートローダーをインストールする必要があります。ログと cloud-init キャッシュをクリアすることもできます。

答え2

私の場合、作成したインスタンスが起動しなかったため、手動で変換する必要がありましたaws ec2 register-image。私の解決策は、この郵便受けにAWS EC2 フォーラム。

準備

すべてのボリュームが同じ可用性ゾーンにあることを確認してください。

  1. 移行元の PV マシンに SSH で接続し、すべての更新を適用してからログアウトします。

  2. AWS コンソールに移動し、PV システムが作成されたのと同じベース AMI (私の場合は Amazon 64 ビット Linux AMI) を選択して、新しい HVM インスタンスを起動します。

  3. この新しいインスタンスに SSH で接続し、すべての更新を適用してからログアウトします。

  4. AWS コンソールに移動し、PV インスタンスを停止します。ルートデバイスのスナップショットを取得し、SOURCE VOLUMEこのスナップショットから新しいボリューム ( ) を作成します。

  5. HVM インスタンスを停止します。新しいインスタンス上のルート デバイスのスナップショットを取得し、このスナップショットから新しいボリューム ( TARGET VOLUME) を作成します。HVM (新しい) インスタンスを再度起動します。

  6. AWS コンソールの使用:

  • SOURCE VOLUME新しいインスタンスに としてアタッチします/dev/xvdf。
  • TARGET VOLUME新しいインスタンスに としてアタッチします/dev/xvdg。

変換プロセス

  1. 新しいインスタンスに SSH で接続し、ルート アクセスを取得します。

     sudo su

  2. ソース ドライブとターゲット ドライブをマウントします。

     mkdir -p /mnt/source && mount /dev/xvdf /mnt/source
 mkdir -p /mnt/target && mount /dev/xvdg1 /mnt/target

    私の場合、デバイスは/dev/xvdf(ソース) と/dev/xvdg1(ターゲット) でした。これらは、パーティションの数と接続場所に基づいて構成で変更される場合があります (準備の手順 6 を参照)。 を使用してls -al /dev/xvd*ドライブを確認します。

  3. バックアップ/lib/modules/*(PV ami のカーネルが新しい HVM マシンと異なる場合。このモジュールは AWS の一部のサービスで使用されます。)

  4. /bootターゲットボリューム以外のすべてを削除します。

     cd /mnt/target && ls | grep -v boot | xargs rm -Rf

  5. /bootソースボリューム上の削除:

     rm -Rf /mnt/source/boot

  6. すべての属性を保持したまま、ソース ボリュームのデータをターゲット ボリュームにコピーします。

     rsync -aAXHPv /mnt/source/ /mnt/target

  7. /mnt/target/etc/fstabパーティションを編集して/、ステップ (8) で最終的な場所にマウントされたときに参照されるようにしますTARGET VOLUME。ラベルを使用するか、または次のような単純なものを使用します。

     /dev/xvda1 /     ext4    defaults,barrier=0 1 1

次に、/lib/modules/手順 3 でバックアップしたものを復元します (PV ami のカーネルが新しい HVM マシンと異なる場合)。

  1. AWS コンソールを使用してシステムを停止し、すべてのボリュームをデタッチします。 をTARGET VOLUME新しいインスタンスに としてアタッチします/dev/xvda。

    元のルート デバイスがマウントされた場所を必ずメモしてください。ほとんどの場合、 になります/dev/xvda。

  2. HVM インスタンスを起動します。これで PV システムの完全な複製になります。すべて問題なければ、PV インスタンスを削除して もかまいませんSOURCE VOLUME。

答え3

要約:

ec2-register -a x86_64 -d '3.15.7-200.fc20.x86_64' -n 'Fedora_20_HVM_AMI'  --sriov simple --virtualization-type hvm -s snap-b44feb18 --root-device-name /dev/sda1

詳細な手順:

さらに回答するとジェフ・ストランクの回答手順を簡素化し、ec2 レジスタ イメージの詳細をもう少し説明します。

  1. PV イメージを使用してインスタンスを作成します。必要な変更を加えたり更新したりします。

  2. 上記のインスタンスからイメージを作成します。

  3. 上記の AMI で使用されているスナップショット ID は、EC2 コンソールの「EC2」>「Elastic Block Store」>「スナップショット」で見つかります。

    または、ec2 api ツールが設定されている場合:

    ec2-describe-images 上記で作成した ami の ami-id

    amiのスナップショットIDを見つける

    .. 次のステップの前提条件: ec2 キーと API ツールが設定され、使用できる状態になっています。

  4. 上記のスナップショットを使用して新しい HVM AMI を登録します。例:

ec2-register -a x86_64 -d '3.15.7-200.fc20.x86_64' -n 'Fedora_20_HVM_AMI' --sriov simple --virtualization-type hvm -s snap-b44feb18 --root-device-name /dev/sda1

どこ

  • -dはAMIの説明です
  • -nはAMI名です
  • -s は手順 3 のスナップショット ID です。
  • -aはアーキテクチャです
  • hvm にするには --virtualization-type が必要です
  • --sriov は拡張ネットワークを有効にするためのものですが、冗長である可能性があり、よくわかりません。

詳細については：

答え4

ここで紹介されている提案をすべて試してみましたが、どれもうまくいきませんでした。そこで、この件に関する素晴らしいブログ記事を見つけました。https://www.opswat.com/blog/aws-2015-why-you-need-switch-pv-hvm。

手順の要素（詳細）は次のとおりです。

  1. grub移行する PV インスタンス (ソース インスタンス) にインストールします。

  2. ソースインスタンス (ソースボリューム、SV) 上のルートボリュームの予防的スナップショットを作成します。

  3. ボリュームを移行する一時的な HVM インスタンスを作成します。

    1. Amazon Linuxインスタンスを使用しました

  4. 宛先ボリューム (DV) を作成し、これと SV の両方を一時インスタンスに接続します。

    1. DV は少なくとも SV と同じ大きさである必要があります。

    2. SV を/dev/{sd,xvd}f、DV を として添付します/dev/{sd,xvd}g。

    3. DV をパーティション分割します。

    parted /dev/xvdg --script 'mklabel msdos mkpart primary 1M -1s print quit'

    partprobe /dev/xvdg

    udevadm settle

  5. SV の FS を最小サイズに変更し、ddそれをイメージとして DV に書き込みます。

    1. ソースボリュームの FS をクリーンアップします。e2fsck -f /dev/xvdf

    2. 同じことを最小限に抑える:resize2fs -M /dev/xvdf

    3. resize2fs からの出力 (例Resizing the file system on /dev/xvdf to 269020 (4k) blocks) を観察し、次のステップのために書き留めておきます。

    4. SV を DV に複製:dd if=/dev/xvdf of=/dev/xvdg1 bs=<block size from previous step, here 4k> count=<use block count from last step, here 269020>

    5. 新しいパーティションの FS を拡張します。resize2fs /dev/xvdg1

  6. grubDVのブートブロックにインストールする

    1. DV 上にデバイス ファイルを一時的に作成します。mount /dev/xvdg1 /mnt; cp -a /dev/xvdg /dev/xvdg1 /mnt/dev/

    2. grub ファイルをインストールします:

    rm -f /mnt/boot/grub/*stage*

    cp /mnt/usr/*/grub/*/*stage* /mnt/boot/grub/

    rm -f /mnt/boot/grub/device.map

    1. chroot 環境に grub をインストールします。

    cat << ARNIE | chroot /mnt grub --batch

    device (hd0) /dev/xvdg

    root (hd0,0)

    setup (hd0)

    ARNIE

  7. 宛先ボリュームにいくつかの小さな変更を加えた後、ボリュームをスナップし、そこから AMI を作成します。

    1. 一時デバイス ファイルを整理します。rm -f /mnt/dev/xvdg /mnt/dev/xvdg1

    2. を に変更/mnt/boot/grub/grub.confし、カーネル行に を追加（または置換）し、必要に応じてカーネル行のを に置き換えます。root (hd0)root (hd0,0)console=*console=ttyS0root=*root=LABEL=/

    3. では/mnt/etc/fstab、ルートFSの行にラベル付き参照が含まれていることを確認します。例:

    LABEL=/ / ext4 defaults,noatime 1 1

    1. 新しいルートFSにラベルを付けるe2label /dev/xvdg1 /

    2. 一時インスタンスから DV をアンマウントし、一時インスタンスから SV と DV の両方をデタッチします。

    3. DV をスナップし、そのスナップから AMI イメージを作成します。

  8. その HMI から HVM インスタンスを起動します。これが移行されたインスタンスです。

関連情報