web-dev-qa-db-ja.com

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

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

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

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

linuxamazon-ec2cloud-computing
38
javacavaj

更新

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

元の答え

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

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

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

22
Jeff Strunk

私の場合、aws ec2 register-imageを使用して作成したインスタンスが起動しなかったため、手動で変換を行う必要がありました。私のソリューションは AWS EC2フォーラム の この投稿 に基づいています。

準備

すべてのボリュームが同じアベイラビリティーゾーンにあることを確認してください。

  1. 移行元のPVマシンにSSHで接続し、すべてのアップデートを適用して、ログアウトします。

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

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

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

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

  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. 手順（8）で最終的な場所にマウントされたときに/mnt/target/etc/fstabを参照するように、/パーティションのTARGET VOLUMEを編集します。ラベルを使用するか、単にそれに沿って何かをする：

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

次に、ステップ3でバックアップした/lib/modules/を復元します（PV AMIのカーネルが新しいHVMマシンと異なる場合）。

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

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

  2. HVMインスタンスを起動します。これで、PVシステムの正確な複製になります。すべて問題なければ、PVインスタンスとSOURCE VOLUMEを削除できます。

13
tolgamorf

TLDR：

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

詳細な手順：

Jeff Strunkの応答 に基づいてさらに回答すると、手順が簡略化され、ec2レジスタイメージの詳細が少し追加されます。

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

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

  3. EC2> Elastic Block Store> EC2 Consoleのスナップショットで、上記のAMIが使用するスナップショットIDを見つけます。

    または、ec2 apiツールをセットアップしている場合：

    ec2-describe-images AMI-id_of_above_created_AMI

    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はアーキテクチャです
  • --virtualization-typeはhvmにするために必要です
  • --sriovは、拡張ネットワーキングを有効にするためのものですが、冗長である可能性があります。

詳細については：

10
Anshu Prateek

これは、AWSウェブインターフェースの内部から行うことができます。 snapshotsに移動し、hvmに変換する目的のスナップショットをクリックして、actionsをクリックし、次にcreate imageをクリックします。イメージ作成ウィザードのドロップダウンで[〜＃〜] hvm [〜＃〜]を選択します。

2
Justin