Прошло несколько дней, а я все еще не могу подключиться к моему новому экземпляру 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 *
? Могу ли я предоставить какую-либо другую информацию или отладочные данные, которые помогут понять проблему?
Я понимаю, что этот вопрос мало кто видел, но на всякий случай я надеюсь, что мои результаты помогут кому-то в будущем (может быть, даже мне, когда я в следующий раз попытаюсь это сделать ). Я хотел бы поблагодарить Стива Э. из службы поддержки 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, сделайте следующее:
Перед запуском убедитесь, что на вашем экземпляре PV установлено следующее:
$ sudo apt-get install grub-pc grub-pc-bin grub-legacy-ec2 grub-gfxpayload-lists
$ sudo apt-get install linux-aws
/ dev / sdf
(в системе Ubuntu имя будет nvme1n1
). / dev / sdg
(в системе Ubuntu имя будет nvme2n1
) После регистрации в свой экземпляр, используйте sudo su
для выполнения всех команд от имени пользователя root.
Отображение ваших томов
# 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
)
Создайте новый раздел на nvme2n1
( nvme2n1p1
будет создан)
# parted / dev / nvme2n1 --script 'mklabel msdos mkpart primary 1M -1s print quit'
# partprobe / dev / nvme2n1
# udevadm урегулировать
Проверьте «исходный» том и минимизируйте размер исходной файловой системы, чтобы ускорить процесс. Мы не хотим копировать свободное дисковое пространство на следующем шаге.
# e2fsck -f / dev / nvme1n1; resize2fs -M / dev / nvme1n1
Дубликат тома «источник» в «место назначения»
# dd if = / dev / nvme1n1 of = / dev / nvme2n1p1 bs = $ (blockdev --getbsz / dev / nvme1n1) conv = sparse count = $ (dumpe2fs / dev / nvme1n1 | grep "Количество блоков:" | cut -d: -f2 | tr -d "\\")
Максимальный размер «целевого» тома:
# e2fsck -f / dev / nvme2n1p1 && resize2fs / dev / nvme2n1p1
Подготовьте целевой том:
# mount / dev / nvme2n1p1 / mnt / && mount -o bind / dev / / mnt / dev && mount -o bind / sys / mnt / sys && mount -o bind / proc / mnt / proc
chroot
в новый том
# chroot / mnt /
Переустановите grub на chrooted-томе:
# grub-install --recheck / dev / nvme2n1
# update-grub
Выход из chroot
# exit
Завершить работу экземпляра
# shutdown -h сейчас
После преобразования вам необходимо сделать следующее:
Отсоедините 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
.
Завершите работу экземпляра, отсоедините тома и введите ту же конфигурацию, что и раньше. Прикрепите том 8 ГБ как / dev / sda1 /
, а конечный целевой том как / dev / sdf /
. Запустите экземпляр и войдите в систему.
Смонтируйте / 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
Создайте или обновите файл:
/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
Выход chroot
( exit
), завершение работы экземпляра ( shutdown -h now
).
Выполните шаг 9, как было сказано ранее!
Готово!
Спасибо, подсказка по настройке сети сработала в случае обновления (с 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