В прошлый раз мы пошагово рассмотрели пример миграции виртуальной машины с гостевой ОС Linux Debian 8 c платформы виртуализации oVirt на платформу Hyper-V. При этом мы провели MBR –> GPT конвертацию диска ВМ для возможности запуска в формате Hyper-V Gen2 с загрузчиком UEFI. В этой заметке мы в более сжатом виде рассмотрим пример аналогичной миграции, но уже для виртуальной машины с ПО Avaya IP Office Server на базе CentOS 6 с учётом нюансов, относящихся к данной ОС.
Согласно документа Supported CentOS and Red Hat Enterprise Linux virtual machines on Hyper-V работа UEFI в гостевой ОС CentOS 6 на виртуальной машине Hyper-V Gen2 хоста виртуализации Windows Server 2012 R2 не поддерживается. Однако мы можем воспользоваться методом Offline-настройки EFI-загрузчика в CentOS 6, описанным в статье блога Derek Bernard CentOS 6 Hyper-V Gen 2 vm error: Boot Failed. EFI SCSI Device.
Начнём с того, что получим информацию о дисках виртуальной машины, которую планируется мигрировать. В нашем случае это CentOS 6.9 со старым ядром Linux 2.6 и одним виртуальным диском, который на момент миграции имеет разметку MBR и единственную точку монтирования "/". Убедимся в том, что диск имеет достаточно свободного места для создания дополнительного раздела под EFI загрузчик (~240MB):
# lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL # df -h
Сам процесс конвертации дисков ВМ из среды виртуализации oVirt в среду Hyper-V был рассмотрен ранее в статье Миграция виртуальной машины oVirt 4.2 на Hyper-V (конвертация в VHDX), поэтому здесь мы его пропустим, предполагая, что уме имеем на руках образ диска ВМ в формате VHDX.
Создание виртуальной машины Hyper-V Gen2
На хосте виртуализации Hyper-V c ОС Windows Server 2012 R2 создаём виртуальную машину второго поколения Generation 2. Подключаем к ВМ конвертированный ранее из oVirt VHDX-диск и отключаем Secure Boot
В списке загружаемых устройств выставляем приоритет для DVD-диска с загрузкой из ISO-образа GParted Live Boot CD, актуальную версию которого можно загрузить по ссылке GNOME Partition Editor - Downloads. В нашем примере будет использоваться имеющаяся на момент написания заметки версия GParted Live Boot CD 0.33.0-1 (64-bit).
Учитывая то, что рассматриваемая далее конвертация таблицы разделов на диске - операция серьёзная, а возможные проблемы в процессе этой операции могут привести в потере данных, перед началом процедуры рекомендуется сделать резервную копию виртуального диска, с которым мы будем проводить работу.
Высвобождение дискового ресурса под раздел EFI System Partition
Включаем виртуальную машину и загружаемся в рабочее окружение GParted Live Boot CD. По аналогии с описанным ранее примером. Освобождаем на диске место под раздел EFI размером ~250MB (239MiB) в начале диска и 1MiB в конце диска для служебной резервной области данных таблицы разделов GPT.
Конвертация таблицы разделов диска из MBR в GPT
После того, как на диске организовано свободное место под раздел EFI, с рабочего стола загруженной Live-среды запускаем окно терминала, переходим в режим супер-пользователя и с помощью утилиты gdisk выполняем конвертацию таблицы разделов диска из MBR в GPT
$ sudo su - # gdisk -l /dev/sda
Войдя в интерактивный режим работы утилиты gdisk вызовем опцию восстановления и трансформации с помощью клавиши "r".
Выберем клавишу "f" для построения GPT таблицы разделов из имеющейся MBR таблицы. После этого нам будет задан вопрос о том, действительно ли мы хотим удалить текущую таблицу разделов (MBR). Утвердительно жмём "y".
Сразу после этого жмём "w", чтобы произвести запись новой таблицы разделов (в формате GPT) на диск и утвердительно отвечаем на последующий вопрос "y".
После успешного обновления таблицы разделов на диске утилита gdisk завершит свою работу.
Создание раздела под EFI System Partition
Снова вызовем утилиту gdisk, чтобы создать новый раздел под загрузчик EFI в ранее высвобожденном свободном месте в начале диска.
# gdisk /dev/sda
Обратим внимание на то, что теперь утилита отображает информацию о том, что на нашем диске используется таблица разделов GPT, а из перечня ключевых клавиш нам нужно выбрать "n" для создания нового раздела.
На последующий запрос о вводе номера раздела, выбираем предлагаемый по умолчанию номер "2".
Следующие два запроса будут определять номер начального и конечного сектора диска для создаваемого раздела. Для того, чтобы использовать всё ранее освобождённое нами дисковое пространство, достаточно согласиться с предлагаемыми по умолчанию значениями номеров секторов и просто два раза нажать Enter.
На следующий запрос о выборе типа раздела укажем значение "ef00".
Записываем отредактированную нами таблицу разделов диска с помощью ключевой клавиши "w" и утвердительно отвечаем на вопрос о перезаписи существующей таблицы разделов – "y".
В результате успешного обновления таблицы разделов утилита завершит свою работу.
Следующим шагом нужно отформатировать только что созданный ESP-раздел в файловую систему FAT32.
С помощью lsblk ещё раз проверим имя раздела, который нужно отформатировать и выполним его форматирование.
# mkfs.vfat /dev/sda2
Итак, на данный момент мы имеем сконвертированную в формат GPT таблицу разделов диска, имеем специальный выделенный раздел под загрузчик EFI, однако этот раздел пока пуст и в самой гостевой Linux системе нет упоминаний об этом разделе.
Подготовка гостевой CentOS Linux под EFI загрузчик
Нам не потребуется колдовать с chroot и установкой загрузчика, как в прошлом примере, так как в CentOS 6, которая оказалась у нас под руками, всё нужное для EFI-загрузки уже есть. Нам только потребуется немного "подшаманить" гостевую систему для успешной EFI-загрузки.
Монтируем корневую ФС гостевой ОС CentOS в каталог /mnt:
# mount /dev/sda1 /mnt
Обратите внимание на то, что если у вас каталог /boot вынесен на отдельный раздел, то здесь после монтирования корневой ФС нам дополнительно потребуется подмонтировать этот раздел в /mnt/boot командой типа:
# mount /dev/sdX /mnt/boot
В нашем примере каталог /boot размещён на самой корневой ФС, поэтому данную команду мы не выполняем.
Итак, на смонтированной в /mnt файловой системе CentOS 6 в каталоге /boot уже будет EFI загрузчик в подкаталоге efi/EFI/redhat/grub.efi. Проверим это:
# tree /mnt/boot/efi
Как видим, загрузчик действительно есть.
Общий порядок действий того, что нам дальше нужно сделать такой:
- Отложить загрузчик в сторону, то есть сделать копию файла загрузчика grub.efi во временном каталоге;
- Смонтировать в каталог /mnt/boot/efi ранее приготовленный EFI-раздел с FAT;
- Скопировать загрузчик grub.efi из временного каталога в /mnt/boot/efi, воспроизведя структуру каталогов;
- Скопировать конфигурационный файл grub.conf в каталог с загрузчиком grub.efi
Поехали…
Создаём копию загрузчика во временный каталог и проверяем его:
# cp /mnt/boot/efi/EFI/redhat/grub.efi /tmp # file /tmp/grub.efi
Монтируем в каталог /mnt/boot/efi ранее приготовленный EFI-раздел с файловой системой FAT. После монтирования убеждаемся в том, что теперь каталог пуст.
# mount /dev/sda2 /mnt/boot/efi
Копируем ранее отложенный во временный каталог /tmp загрузчик grub.efi в каталог /mnt/boot/efi, воспроизведя структуру каталогов, которая была ранее в гостевой ОС CentOS 6. В этот же каталог копируем действующий конфигурационный файл grub.conf гостевой ОС (в этом файле записана информация о том, с какого раздела и какое ядро Linux должно загружаться при старте системы). Затем проверяем, что у нас получилось в каталоге /mnt/boot/efi.
# mkdir -p /mnt/boot/efi/EFI/redhat # cp /tmp/grub.efi /mnt/boot/efi/EFI/redhat/ # cp /mnt/boot/grub/grub.conf /mnt/boot/efi/EFI/redhat/ # tree /mnt/boot/efi
Здесь стоит обратите внимание на пару моментов. Во первых, как изложено в исходном материале, основное имя (без расширения) конфигурационного файла должно совпадать с именем загрузчика.
Еще один момент, о котором следует помнить на перспективу. У меня есть подозрение, что последующее обновление ядра в гостевой CentoS может привести к изменению конфигурации в файле /boot/grub/grub.conf и это потребует копирования обновлённой версии файла grub.conf в каталог, где расположен EFI-загрузчик /boot/efi/EFI/redhat. Если этого не сделать, то, предположительно, после перезагрузки ВМ, EFI-загрузчик будет стартовать старое ядро Linux, так как о новом ему ничего не известно. Если такая ситуация действительно возникнет, то в качестве решения проблемы можно будет попробовать в гостевой ОС удалить старый файл /boot/efi/EFI/redhat/grub.conf, а вместо него сделать символическую ссылку на файл /boot/grub/grub.conf.
Правим fstab в гостевой CentOS Linux
Теперь нам нужно внести правку в файл /etc/fstab гостевой системы, добавив туда директиву для монтирования загрузочного раздела EFI. Но для этого нам понадобиться узнать идентификатор UUID этого раздела. Так как раздел EFI уже смонтирован в нашей Live системе, мы можем выяснить идентификатор UUID ESP-раздела командой вида:
# ls -lh /dev/disk/by-uuid
Как видим, в нашем случае ESP-раздел /dev/sda2 имеет идентификатор UUID равный "9D89-5CD4"
Откроем на редактирование принадлежащий гостевой системе конфигурационный фaйл fstab ...
# nano /mnt/etc/fstab
... добавим в конец файла запись о необходимости монтирования EFI раздела, указав соответствующий идентификатор UUID этого раздела. В нашем случае строка монтирования раздела будет выглядеть так:
UUID=9D89-5CD4 /boot/efi vfat umask=0077 0 1
В гостевой системе CentOS 6 у нас всё готово для того, чтобы она могла запускаться с EFI-загрузчика. Теперь нам нужно как-то объяснить гипервизору Hyper-V то, где искать загрузчик гостевой ОС при старте ВМ.
Замена загрузчика в свойствах ВМ Hyper-V
Так как наша Live-система GParted Live загружена с EFI-загрузчика и в ней есть утилита efibootmgr, то воспользуемся возможностями этой утилиты для того, чтобы сообщить в UEFI Firmware виртуальной машины информацию о настроенном нами EFI-загрузчике.
# efibootmgr --create --disk /dev/sda --part 2 --loader /EFI/redhat/grub.efi --label "Linux"
где:
- в опции --disk укажем имя диска для которого требуется регистрация EFI-загрузчика;
- в опции --part укажем номер раздела диска, на котором расположен EFI-загрузчик. В нашем случае это раздел /dev/sda2, поэтому мы должны указать 2;
- в опции --loader укажем путь в файлу загрузчика относительно корня раздела загрузчика;
- в опции --label укажем произвольное имя метки загрузчика.
После выполнения команды проверим свойства виртуальной машины на гипервизоре Hyper-V. Заглянем в раздел Firmware и убедимся в том, что в перечне, определяющем порядок обхода устройств загрузки появился объект типа File, ссылающийся на EFI-загрузчик на диске нашей гостевой ОС CentOS.
Теперь всё готово для того, чтобы ВМ с настроенной гостевой ОС успешно загрузилась с EFI-загрузчика.
Завершаем работу загруженной в ВМ среды GParted Live и можно приступать к проверке результата. Однако, в нашем случае не следует торопиться с первым проверочным запуском гостевой ВМ.
Замечания для ПО Avaya IP Office Server
Учитывая то, что в контексте этой заметки речь идёт о ВМ, которая по сути является Virtual Appliance с ПО Avaya IP Office Server, перед первым запуском мигрированной на другой гипервизор гостевой ОС следует выполнить пару важных шагов, а именно:
- В свойствах ВМ в параметрах виртуального сетевого адаптера в ручную настроить тот MAC-адрес, который ранее использовался на исходном гипервизоре. Это необходимо не только для ПО Avaya IP Office, но и для того, чтобы избежать проблемы, описанной ранее в заметке по использованию миграций методом Live Migration;
- Также для виртуального сетевого адаптера ВМ важно сохранить возможность использования прежнего IP адреса;
- В свойствах ВМ в параметрах Integration Services следует отключить службу синхронизации времени, чтобы гипервизор не пытался навязать гостевой ОС время, установленное на хосте виртуализации. В составе IP Office есть собственная служба синхронизации времени, с которой лучше не шутить.
Если не соблюсти указанные условия, то при первом же запуске гостевой ОС веб-служба управления лицензиями Avaya Web License Manager (WebLM) "переполошиться" и перестанет штатно работать, утянув за собой работоспособность всех базовых сервисов Avaya IP Office Server. Причём, наши эксперименты показали то, что вывести в последствии такой "вошедший в штопор" WebLM можно только путём перерегистрации лицензий в тех.поддержке Avaya, что может оказаться "удовольствием" не из дешёвых.
Загрузка ВМ с EFI загрузчика
Пробуем выполнить запуск виртуальной машины и убеждаемся в том, что гостевая ОС успешно загружается
В нашем случае после миграции oVirt –> Hyper-V с последующей конвертацией MBR –> GPT гостевая ОС CentOS 6 успешно загрузилась c EFI-загрузчика и весь набор веб-служб Avaya IP Office Server заработал, как и ранее на исходной платформе виртуализации.
Компоненты интеграции Hyper-V
Учитывая то, что в нашем примере гостевая ОС ранее была снабжена компонентами интеграции oVirt, нам потребуется выполнить удаление из системы соответствующих служб:
# service ovirt-guest-agent stop # chkconfig ovirt-guest-agent off # yum remove ovirt-guest-agent
Для того же, чтобы установить в гостевую ОС CentOS 6 компоненты интеграции Hyper-V, в общем случае можно воспользоваться статьёй Вики - Установка и проверка компонент интеграции Hyper-V в CentOS Linux
Однако в нашем случае какие-либо репозитории отключены от гостевой ОС производителем Avaya IP Office Server во избежание проблем совместимости ПО в пакетах из репозиториев и пред-настроенного ПО в Virtual Appliance. Поэтому мы не будем искушать судьбу и пытаться подключать какие-либо внешние репозитории, а установим нужные нам пакеты с компонентами интеграции Hyper-V напрямую загружая их из репозитория CentOS:
# wget -P ~/Packages http://mirror.centos.org/centos/6/os/x86_64/Packages/hyperv-daemons-0-0.17.20150108git.el6.x86_64.rpm # wget -P ~/Packages http://mirror.centos.org/centos/6/os/x86_64/Packages/hyperv-daemons-license-0-0.17.20150108git.el6.noarch.rpm # wget -P ~/Packages http://mirror.centos.org/centos/6/os/x86_64/Packages/hypervfcopyd-0-0.17.20150108git.el6.x86_64.rpm # wget -P ~/Packages http://mirror.centos.org/centos/6/os/x86_64/Packages/hypervkvpd-0-0.17.20150108git.el6.x86_64.rpm # wget -P ~/Packages http://mirror.centos.org/centos/6/os/x86_64/Packages/hypervvssd-0-0.17.20150108git.el6.x86_64.rpm # cd ~/Packages/ # yum install hyperv*.rpm
После установки компонент интеграции, выполняем перезагрузку гостевой системы и проверяем успешность запуска соответствующих служб, как это было описано ранее.
Заключение
Описанная последовательность действий может быть применима не только в случае необходимости миграции ВМ с гостевой ОС Linux CentOS 6 из других сред виртуализации в ВМ Hyper-V Gen2, но и в случае необходимости миграции гостевой ОС CentOS/RHEL из ВМ Hyper-V Gen1 в ВМ Hyper-V Gen2. Сам принцип миграции Legacy BIOS -> UEFI с некоторыми оговорками может быть применён и на физических Linux-системах.
Дополнительные источники информации:
RSS - Записи
Добавить комментарий