Запущенный ранее виртуальный аплайнс Avaya Meetings (Equinox) Management Server 9.1 может функционировать в формате Hyper-V Gen1, так как на его виртуальном диске используется таблица разделов MBR и загрузчик Legacy BIOS. Если мы хотим улучшить конфигурацию ВМ до уровня Hyper-V Gen2, то нам потребуется выполнить процедуры преобразования таблицы разделов на диске в формат GPT и подготовки гостевой ОС Red Hat Enterprise Linux (RHEL) к использованию UEFI загрузчика. В этой заметке мы рассмотрим данные процедуры на примере "родственного" аплайнса Avaya Meetings (Equinox) Media Server 9.1 на базе ОС RHEL 7.6.
-
Конвертация формата загрузчика Legacy BIOS (таблица разделов MBR) в формат UEFI (таблица разделов GPT) на диске виртуальной машины Hyper-V для аплайнса Avaya Meetings (Equinox) с гостевой ОС RHEL 7.6
-
Миграция виртуальной машины c Linux CentOS 6 (Avaya IP Office Server) из среды oVirt в Hyper-V Gen2 с конвертацией диска из формата загрузчика Legacy BIOS (таблица разделов MBR) в формат UEFI (таблица разделов GPT)
В прошлый раз мы пошагово рассмотрели пример миграции виртуальной машины с гостевой ОС Linux Debian 8 c платформы виртуализации oVirt на платформу Hyper-V. При этом мы провели MBR –> GPT конвертацию диска ВМ для возможности запуска в формате Hyper-V Gen2 с загрузчиком UEFI. В этой заметке мы в более сжатом виде рассмотрим пример аналогичной миграции, но уже для виртуальной машины с ПО Avaya IP Office Server на базе CentOS 6 с учётом нюансов, относящихся к данной ОС.
-
Миграция виртуальной машины c Linux Debian 8 из среды oVirt в Hyper-V Gen2 с конвертацией диска из формата загрузчика Legacy BIOS (таблица разделов MBR) в формат UEFI (таблица разделов GPT)
Базовая процедура миграции виртуальной машины из среды виртуализации oVirt в среду Hyper-V была рассмотрена ранее в статье Миграция виртуальной машины oVirt 4.2 на Hyper-V (конвертация в VHDX). То есть сначала виртуальная машина экспортируется из oVirt в качестве контейнера OVA, затем файл *.ova распаковывается и вложенный в него RAW-диск с помощью утилиты qemu-img конвертируется в формат VHDX. Запуск виртуальной машины Hyper-V с полученным в результате миграции VHDX-диском не представляет сложностей в том случае, если ВМ была создана в формате Hyper-V Gen1. Проблема может возникнуть, если мы захотим без предварительных манипуляций создать на основе полученного диска виртуальную машину Hyper-V Gen2. Далее мы рассмотрим такую ситуацию с вариантом решения поставленной задачи, опирающимся на статью Jens Getreu - Switch Debian from legacy to UEFI boot mode. Читать далее...
-
Используем Veeam Backup Free Edition 9.5 для резервного копирования виртуальных машин с хоста Hyper-V на выделенный файловый сервер на базе Debian Linux 8.6 c дедупликацией от QUADStor
Возникла задача организации резервного копирования виртуальных машин Hyper-V с отдельных хостов виртуализации (без кластера) на нескольких удалённых площадках. В силу того, что одной из вводных этой задачи является наличие очень скромных и нестабильных каналов связи, идея использования единого сервера резервного копирования на центральной площадке отпала сама по себе. Ибо одно дело, когда можно стягивать резервные копии в одно центральное место с учётом блочных изменений, сокращая при этом нагрузку на сеть, например тем же System Center DPM, и совсем другое дело, если в сжатые сроки потребуется выполнить полное восстановление ВМ на определённый момент времени по этим же слабеньким каналам. Таким образом, нужно было подумать над тем, как организовать резервное копирование виртуальных машин непосредственно на удалённой площадке, при условии отсутствия увеличения текущих затрат на лицензируемое ПО и на имеющемся оборудовании.