web-dev-qa-db-ja.com

Ubuntu 16 PVをUbuntu 16 HVMに変換した後、EC2インスタンスに接続できない

だから数日経ったのですが、Ubuntu 16を実行しているEC2で新しいHVMインスタンスに接続できません。参考までに、Ubuntu 16を実行しているm3インスタンスからUbuntu 16を実行しているC5インスタンスにサーバーをアップグレードしようとしています。私が試したほぼすべての方法で、新しいC5インスタンスを停止し、すべてのボリュームを切り離し、新しく更新されたソースボリュームを/dev/sda1として接続するポイントに到達できますが、その後、インスタンス、私は常にタイムアウトになります。 Amazonのステータスチェックも失敗します。これは、インスタンスに到達できないことを示しているためです。ただし、システムログは起動時に問題を示しません。

この投稿 ですべてを試しました。 この投稿 も試しました。私は他のサイトを調べて、 this と this を試してみました。 ec2コマンドラインツールの方法とec2コンソールからAMIを変換する（オンライン）の両方を試しましたが、変換されたAMIでC5インスタンスを起動できないか、インスタンスが停止して失敗します（の場合）コマンドラインによる変換）。

それが原因であると私が本当に考えることができる唯一のことは、C5インスタンスのパーティションの命名規則です。私が見たガイドはすべてxvda/xvdf/xvdgを使用しています。私は間違っている可能性がありますが、これらのパーティションまたはディスクがなく、代わりにnvme0n1、nvme0n1p1、（新しいHVMルート）、nvme1n1、およびnvme1n1p1があります。 HVM /ソース/ターゲットディスクの方法を試したところ、nvme0n1/nvme0n1p1、nvme1n1（ターゲット-すべてが終わるはずの場所）、およびnvme2n1/nvme2n1p1（ソース-すべてのソースがあった場所）がありました。 、m3）。私は nvmeに関するこのAmazonの投稿 を見つけたので、/mnt/を使用するときに正しいディスク/パーティションを使用しているだけなので、これは問題ではないと思います。 mkdir -p /mnt/target && mount /dev/nvme1n1 /mnt/targetの代わりにmkdir -p /mnt/target && mount /dev/xvdf /mnt/targetを呼び出しますが、これまでのところ何も機能していません。 targetを/dev/sda1としてアタッチすると、インスタンスに到達できなくなります。

それで、nvme*という名前のディスクを使用してこれらを実行するときに欠けているものはありますか？問題を理解するのに役立つ他の情報やデバッグ情報はありますか？

amazon-ec2hard-drivenvmeparavirtualizationhvm
4
Alex

この質問はあまり見られなかったことに気づきましたが、念のために言えば、私の結果が将来の誰かを助けることができることを願っています（多分、私が次にこれを試すときも）。インスタンスを移行するのを手伝ってくれたAmazonサポートのSteve Eに感謝します<3

とにかく、Ubuntu 16.04 M3（PV）インスタンスをUbuntu 16.04 C5（HVM）インスタンスに移行するときに2つの問題がありました。最初の問題は、新しいC5インスタンスが新しい命名規則を使用するため、PVをHVMに移行することに関する他のチュートリアルがまったく同じように機能しないことでした。もう1つの問題は、私のM3（PV）インスタンスがUbuntuにアップグレードされていたことです。私は実際に過去1年ほどでUbuntu 12-> Ubuntu 14-> Ubuntu 16から移行しました。これにより、クラウドネットワークファイルが生成されないという問題が発生したため、インスタンスに到達できませんでした。

とにかく、新しいnvme命名規則を使用してUbuntu 16.04 PVインスタンスをHVMインスタンスに移行するには、次のようにします。

前提条件の要約：

  1. 開始する前に、PVインスタンスに以下をインストールしてください。

    $ Sudo apt-get install grub-pc grub-pc-bin grub-legacy-ec2 grub-gfxpayload-lists
$ Sudo apt-get install linux-aws
  2. PVインスタンスを停止＆ スナップショットを作成 ルートボリュームの このスナップショットを復元 ソースの同じアベイラビリティーゾーンに新しいEBSボリュームとして（PVインスタンスを右に開始スナップショット作成後）
  3. 新しいC5 HVMインスタンスを起動します （宛先）ソースインスタンスと同じアベイラビリティーゾーンでUbuntu Server 16.04 LTS（HVM）を選択します（このルートボリュームとして、この新しいインスタンスのEBSルートボリュームサイズを8GBに保ちます）一時的にのみ使用されます）
  4. インスタンスが起動した後、 ボリュームをアタッチ は、ステップ1で（PVインスタンスからのルートボリュームである）/dev/sdfとして復元しました（Ubuntuシステムでは、名前はnvme1n1になります）。
  5. 新しい（空の）EBSボリュームを作成 （「ソース」PVルートボリュームと同じサイズ）、HVMインスタンスに/dev/sdgとしてアタッチします（Ubuntuシステムでは、名前はnvme2n1になります）。

移行：

インスタンスにログインしたら、Sudo suを使用して、すべてのコマンドをrootユーザーとして実行します。

  1. ボリュームを表示する

    # lsblk 
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0    8G  0 disk 
└─nvme0n1p1 259:1    0    8G  0 part /
nvme1n1     259:2    0  100G  0 disk 
nvme2n1     259:3    0  100G  0 disk

    nvme0n1は、作成したばかりのHVMルートです（今回のみ起動します）nvme1n1は、復元されたPVルートです（HVMに変換されます）nvme2n1は、空のボリュームです（PVルートからnvme1n1として変換を受け取ります）

  2. nvme2n1に新しいパーティションを作成します（nvme2n1p1が作成されます）

    # parted /dev/nvme2n1 --script 'mklabel msdos mkpart primary 1M -1s print quit'
# partprobe /dev/nvme2n1
# udevadm settle

  3. 「ソース」ボリュームを確認し、元のファイルシステムのサイズを最小化して、プロセスを高速化します。次のステップでディスクの空き容量をコピーしたくありません。

    # e2fsck -f /dev/nvme1n1 ; resize2fs -M /dev/nvme1n1

  4. 「ソース」ボリュームを「宛先」ボリュームに複製

    # dd if=/dev/nvme1n1 of=/dev/nvme2n1p1 bs=$(blockdev --getbsz /dev/nvme1n1) conv=sparse count=$(dumpe2fs /dev/nvme1n1 | grep "Block count:" | cut -d : -f2 | tr -d "\\ ")

  5. 「宛先」ボリュームのサイズを最大に変更します。

    # e2fsck -f /dev/nvme2n1p1 && resize2fs /dev/nvme2n1p1

  6. 宛先ボリュームを準備します。

    # mount /dev/nvme2n1p1 /mnt/ && mount -o bind /dev/ /mnt/dev && mount -o bind /sys /mnt/sys && mount -o bind /proc /mnt/proc

  7. chrootを新しいボリュームに

    # chroot /mnt/

  8. chrubedボリュームにgrubを再インストールする ：

    # grub-install --recheck /dev/nvme2n1
# update-grub

    chrootを終了します

    # exit

    インスタンスをシャットダウンします

    # shutdown -h now

  9. 変換後、これを実行する必要があります：

    HVMインスタンス上に以前持っていた3つのボリュームを切り離します。作成した最後のボリューム（ブランク）を、HVMインスタンスのコンソール（以前は/dev/sda1として接続されていた）に/dev/nvme2n1として接続します。 HVMインスタンスを起動します。

これで、新しいHVMインスタンスが正常に起動し、古いソースPVインスタンスの正確なコピーになります（正しいソースボリュームを使用した場合）。すべてが機能していることを確認したら、ソースインスタンスを終了できます。

ネットワーク構成の更新（オプション）

ここで、上記の手順は、ここにいる大多数の人々に対して機能します。ただし、インスタンスのステータスにまだ到達していません。その理由は、新しいイメージから開始するのではなく、インスタンスでUbuntuをアップグレードしたためです。これにより、eth0構成がアクティブになり、50-cloud-init.cfg構成ファイルがなくなりました。

/etc/network/interfaces.d/50-cloud-init.cfgファイルが既にある場合は、新しいファイルを作成する代わりに、ファイルを更新して更新できます。また、すべてのコマンドがSudo suを介して実行されると仮定します。

  1. インスタンスをシャットダウンし、ボリュームを切り離して、以前と同じ構成を入力します。 8GBボリュームを/dev/sda1/として、最終的な宛先ボリュームを/dev/sdf/として接続します。インスタンスを起動してログインします。

  2. 以下を実行して、/dev/sdfをnvme1n1p1にマウントします。

    # mount /dev/nvme1n1p1 /mnt/ && mount -o bind /dev/ /mnt/dev && mount -o bind /sys /mnt/sys && mount -o bind /proc /mnt/proc

  3. ファイルを作成または更新します。

    /etc/network/interfaces.d/50-cloud-init.cfg

    以下の場合：

    # This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto ens5
iface ens5 inet dhcp

  4. chroot（exit）を終了し、インスタンスをシャットダウンします（shutdown -h now）。

  5. 前から手順9を実行してください！

あなたはやるべきです！

5
Alex

おかげで、ネットワーク構成のヒントはアップグレードの場合に機能しました（Ubuntu 14.04 PVからUbuntu 18.04 PV）。アップグレードされたUbuntu 18.04 PVを、ネットワーク構成にわずかな調整を加えたUbuntu 18.04 HVMに変換しました。次の構成で新しい/etc/netplan/50-cloud-init.configを作成しました

network:
    version: 2
    ethernets:
        all-en:
            match:
                name: "en*"
            dhcp4: true
        all-eth:
            match:
                name: "eth*"
            dhcp4: true
0
Yogesh Sinhal