Не удается подключиться к экземпляру EC2 после преобразования Ubuntu 16 PV в Ubuntu 16 HVM

Прошло несколько дней, а я все еще не могу подключиться к моему новому экземпляру HVM с запущенным EC2 Ubuntu 16. Для справки, я пытаюсь обновить наш сервер с экземпляра m3 с Ubuntu 16 до экземпляра C5 с Ubuntu 16. Практически для каждого метода, который я пробовал, Я могу добраться до точки, когда я остановлю свой новый экземпляр C5, отсоединю все тома и присоединю недавно обновленный исходный том как / dev / sda1 , но затем, когда я перейду к подключению к экземпляру, Я всегда заканчиваю тайм-аут. Проверка статуса Amazon также не выполняется, поскольку в ней говорится, что экземпляр недоступен. Однако системный журнал не показывает никаких проблем при запуске.

Я пробовал делать все, что описано в этой публикации . Я также пробовал этот пост . Я поискал на других сайтах и ​​попробовал это и это . Я даже пробовал как метод инструментов командной строки ec2, так и преобразование AMI из консоли ec2 (онлайн), однако я либо не могу запустить экземпляр C5 с преобразованным AMI, или экземпляр остановится и выйдет из строя (в случае преобразования через командную строку).

Единственное, что я действительно могу думать о том, что могло бы его вызвать, - это соглашение об именах для разделов в экземпляре C5. Все руководства, которые я видел, используют xvda / xvdf / xvdg . Я могу ошибаться, но у меня нет этих разделов или дисков, а вместо них есть nvme0n1 , nvme0n1p1 , (новый корень HVM), nvme1n1 и nvme1n1p1 . Когда я попробовал метод HVM / исходный / целевой диск, у меня были nvme0n1 / nvme0n1p1 , nvme1n1 (цель - где все должно закончиться) и nvme2n1 / nvme2n1p nvme2n1 / nvme2n1p 11125291] (источник - откуда все было, на м3). Я нашел этот пост на Amazon о nvme , поэтому я не Думаю, это должно быть проблемой, поскольку я просто использую правильный диск / раздел при использовании / mnt / , т.е. Я вызываю mkdir -p / mnt / target && mount / dev / nvme1n1 / mnt / target вместо mkdir -p / mnt / target && mount / dev / xvdf / mnt / target , но пока ничего не работает. Мой экземпляр становится недоступным в тот момент, когда я прикрепляю цель как / dev / sda1 .

Итак, есть ли что-то, что я? m отсутствует при выполнении этого с диском с именем nvme * ? Могу ли я предоставить какую-либо другую информацию или отладочные данные, которые помогут понять проблему?

4
задан 22 February 2018 в 05:23
2 ответа

Я понимаю, что этот вопрос мало кто видел, но на всякий случай я надеюсь, что мои результаты помогут кому-то в будущем (может быть, даже мне, когда я в следующий раз попытаюсь это сделать ). Я хотел бы поблагодарить Стива Э. из службы поддержки Amazon за помощь в переносе моего экземпляра <3

В любом случае, при миграции моего экземпляра Ubuntu 16.04 M3 (PV) на экземпляр Ubuntu 16.04 C5 (HVM) возникло 2 проблемы. Первая проблема заключалась в том, что новые экземпляры C5 действительно используют новые соглашения об именах, поэтому другие руководства по миграции PV на HVM не работают таким же образом. Другая проблема заключалась в том, что мой экземпляр M3 (PV) был обновлен до Ubuntu. Я фактически перешел с Ubuntu 12 -> Ubuntu 14 -> Ubuntu 16 за последний год или около того. Это вызвало проблему, из-за которой файлы облачной сети не создавались, и мой экземпляр не мог быть достигнут.

В любом случае, чтобы перенести экземпляр Ubuntu 16.04 PV на экземпляр HVM с использованием нового соглашения об именах nvme, сделайте следующее:

Сводка предварительных требований:

  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 для этого нового экземпляра равным 8 ГБ , поскольку этот корневой том будет использоваться только временно)
  4. После запуска экземпляра присоедините том , который вы восстановили на шаге 1 (это корневой том из экземпляра PV) как / dev / sdf (в системе Ubuntu имя будет nvme1n1 ).
  5. Создайте новый (пустой) том EBS (такого же размера, как ваш «исходный» корневой том PV) и прикрепите к экземпляру HVM как / dev / sdg (в системе Ubuntu имя будет nvme2n1 )

Миграция:

После регистрации в свой экземпляр, используйте sudo su для выполнения всех команд от имени пользователя root.

  1. Отображение ваших томов

     # lsblk
    НАЗВАНИЕ ГЛАВНОЕ: МИН. РАЗМЕР RM ТИП RO ГОРКА
    nvme0n1 259: 0 0 8G 0 диск
     └─nvme0n1p1 259: 1 0 8G 0 часть /
    nvme1n1 259: 2 0 100G 0 диск
    nvme2n1 259: 3 0 100G 0 диск
     

    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 урегулировать
     
  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 "Количество блоков:" | 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. Переустановите grub на chrooted-томе:

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

    Выход из chroot

     # exit
     

    Завершить работу экземпляра

     # shutdown -h сейчас
     
  9. После преобразования вам необходимо сделать следующее:

    Отсоедините 3 тома, которые у вас были ранее на экземпляре HVM. Прикрепите последний созданный том (пустой) как / dev / sda1 на консоли (ранее он был прикреплен как / dev / nvme2n1 ) к экземпляру HVM. Запустите экземпляр HVM.

Теперь новый экземпляр HVM должен успешно загрузиться и будет точной копией старого исходного экземпляра PV (если вы использовали правильный исходный том). После того, как вы убедитесь, что все работает, исходный экземпляр можно прекратить.


Обновление конфигурации сети (необязательно)

Теперь описанные выше шаги будут работать для большинства людей. Однако статус моего экземпляра все еще не был достигнут. Причина заключалась в том, что я обновил Ubuntu на своем экземпляре вместо того, чтобы начинать со свежего образа. При этом конфигурация eth0 оставалась активированной, а конфигурационный файл 50-cloud-init.cfg отсутствует.

Если у вас уже есть файл / etc / network / interfaces. d / 50-cloud-init.cfg , затем вы можете следить и обновлять файл, вместо того, чтобы создавать новый. Также предположим, что все команды запускаются через sudo su .

  1. Завершите работу экземпляра, отсоедините тома и введите ту же конфигурацию, что и раньше. Прикрепите том 8 ГБ как / 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
     

    Со следующим:

     # Этот файл создан на основе информации, предоставленной
     # источник данных.  Его изменения не сохранятся в экземпляре.
     # Чтобы отключить возможности настройки сети cloud-init, напишите файл
     # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg со следующим:
     # сеть: {config: disabled}
    авто лоу
    iface lo inet loopback
    
    авто Ens5
    iface ens5 inet dhcp
     
  4. Выход chroot ( exit ), завершение работы экземпляра ( shutdown -h now ).

  5. Выполните шаг 9, как было сказано ранее!

Готово!


5
ответ дан 3 December 2019 в 03:15

Спасибо, подсказка по настройке сети сработала в случае обновления (с 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
ответ дан 3 December 2019 в 03:15

Теги

Похожие вопросы