Перенос Linux с виртуальной машины на реальную
Обновлено: 21.11.2024
Мигрируйте физическую машину (PM) или виртуальную машину (VM), чтобы перенести ее по сети A-link на новую виртуальную машину в системе. (Вы также можете импортировать в систему файл Open Virtualization Format (OVF), как описано в разделе Создание и миграция виртуальных машин.)
Приведенные ниже процедуры описывают, как перенести PM или VM по сети: загрузите ISO-файл клиента P2V ( virt-p2v ), загрузите ISO-файл клиента P2V на исходном PM или VM, а затем используйте клиент для настройки, инициировать и контролировать безопасную передачу по сети со стороны источника. Никаких действий по настройке в системе не требуется до тех пор, пока миграция не будет завершена, но вы можете подтвердить, что миграция выполняется на странице Volumes консоли everRun Availability Console, когда начнут появляться тома, связанные с новой виртуальной машиной.
Предостережение. Прежде чем приступать к переносу, рекомендуется создать резервную копию исходного PM или VM. Чтобы создать резервную копию виртуальной машины, экспортируйте ее (см. Экспорт виртуальной машины).
Процесс переноса поддерживает PM или виртуальные машины, работающие только со следующими операционными системами:
Microsoft Windows 7, 8.x или 10; или Windows Server 2008 R2, 2012 или 2016.
Windows Server 2003 — для переноса этой ВМ необходимо выполнить другую процедуру. См. раздел Миграция виртуальной машины Windows Server 2003 в систему everRun 7.x.
Ubuntu 14.04 LTS, 16.04 LTS или 18.04 Server — после переноса этой виртуальной машины вам необходимо выполнить дополнительные процедуры. См. раздел Чтобы завершить миграцию виртуальной машины Ubuntu.
При переносе виртуальной машины VMware вы должны выключить виртуальную машину с помощью команд завершения работы операционной системы, а не только через консоль VMware. Если вы отключите виртуальную машину, используя только консоль VMware, миграция завершится ошибкой.
Необходимое условие: на странице «Физические машины» консоли everRun Availability Console убедитесь, что оба PM находятся в рабочем состоянии и что ни один PM не находится в режиме обслуживания или в процессе синхронизации.
- На странице "Загрузки" нажмите everRun (если она еще не отображается) и выберите соответствующую версию.
- Прокрутите вниз до пункта «Драйверы и инструменты», а затем продолжите прокрутку до пункта everRun P2V Client for Virtual или Physical Machine Migration.
- Выберите файл клиента P2V (virt-p2v).
Если вы хотите проверить целостность образа ISO, используйте связанный файл контрольной суммы fciv и исполняемый файл Microsoft File Checksum Integrity Verifier (FCIV), если вы уже загрузили файл Microsoft в свою систему. В противном случае используйте хеш-функцию контрольной суммы MD5.
Загрузите соответствующий файл проверки fciv из раздела «Драйверы и инструменты» на странице «Загрузки». Сохраните файл проверки fciv в каталоге, содержащем загруженный файл ISO.
Откройте окно командной строки. В каталоге, содержащем файлы ISO, исполняемые файлы и файлы проверки, введите команду, подобную следующей, для проверки образа ISO:
fciv -v -xml virt-p2v- n.n.n-n .nnnnnnnn.n.el6.centos.xml
Если команда выполнена успешно (то есть возвращается сообщение Все файлы успешно проверены), перейдите к следующему шагу. Если команда не удалась, повторите загрузку.
Откройте окно командной строки от имени администратора и введите следующее:
CertUtil -hashfile path_to_file MD5
Команда CertUtil отображает сообщение, указывающее, успешно ли она выполнена. Если команда выполнена успешно, перейдите к следующему шагу. Если команда не удалась, повторите загрузку.
Если вы хотите проверить целостность образа ISO, используйте связанный файл контрольной суммы fciv и исполняемый файл Microsoft File Checksum Integrity Verifier (FCIV), если вы уже загрузили файл Microsoft в свою систему. В противном случае используйте хеш-функцию контрольной суммы MD5.
Загрузите соответствующий файл проверки fciv из раздела «Драйверы и инструменты» на странице «Загрузки». Сохраните файл проверки fciv в каталоге, содержащем загруженный файл ISO.
Откройте окно командной строки. В каталоге, содержащем файлы ISO, исполняемые файлы и файлы проверки, введите команду, подобную следующей, для проверки образа ISO:
fciv -v -xml virt-p2v- n.n.n-n .nnnnnnnn.n.el6.centos.xml
Если команда выполнена успешно (то есть возвращается сообщение Все файлы успешно проверены), перейдите к следующему шагу. Если команда не удалась, повторите загрузку.
Откройте окно командной строки от имени администратора и введите следующее:
CertUtil -hashfile path_to_file MD5
Команда CertUtil отображает сообщение, указывающее, успешно ли она выполнена. Если команда выполнена успешно, перейдите к следующему шагу. Если команда не удалась, повторите загрузку.
- Включите исходный PM или VM, чтобы загрузить клиент P2V. Примерно через минуту отобразится окно virt-p2v.
- Клиент P2V автоматически получает сетевые настройки через DHCP.Статические параметры не нужны для процесса миграции, но вы можете дополнительно щелкнуть Настроить сеть, чтобы указать параметры. (При необходимости настройте сетевые параметры целевой ВМ позже в системе everRun.)
- Введите параметры подключения к серверу преобразования (система everRun). Введите имя хоста или IP-адрес системы и пароль для учетной записи root. (Вы должны использовать учетную запись root операционной системы хоста everRun, как описано в разделе Доступ к операционной системе хоста.)
Нажмите Проверить подключение . Если клиент P2V подключается к системе everRun, нажмите «Далее», чтобы продолжить. Появится страница с разделами Целевые свойства , Неподвижные жесткие диски и другие параметры.
Если клиент P2V не может подключиться, проверьте настройки подключения и повторите попытку подключения.
- Рядом с пунктом Вывод в выберите операцию everrunha (высокая доступность) или everrunft (отказоустойчивость). (Информацию о параметрах работы см. в разделе Создание новой виртуальной машины и режимы работы.)
- В поле Формат вывода выберите формат образа диска, необработанный или qcow2 . (Формат qcow2 поддерживает моментальные снимки.)
Выберите, какие фиксированные жесткие диски (тома) следует включить в миграцию, установив флажок рядом с каждым устройством.
Необходимо выбрать хотя бы один том, включая загрузочный том. (Поскольку клиент P2V представляет собой утилиту на базе Linux, все устройства перечислены по именам устройств Linux, где sda или vda представляют загрузочный том.)
Если целевая система everRun имеет более одной группы хранения, вы также можете выбрать группу хранения, в которой будет создаваться каждый том. Дважды щелкните запись тома, чтобы открыть панель Choose Storage Group. Убедитесь, что вы выбрали группу хранения, которая поддерживает размер сектора импортируемого тома (см. Планирование хранилища виртуальной машины), и выберите размер сектора, соответствующий исходному тому (клиент P2V не может преобразовать размер сектора тома). Обратите внимание, что загрузочный том должен иметь размер сектора 512 Б. Вы можете выбрать размер сектора, 4 КБ или 512 Б, только для дисков с данными.
Выберите, какие сетевые интерфейсы включить в миграцию, установив флажок рядом с каждым устройством.
Если целевая система everRun имеет более одной общей сети, вы также можете выбрать общую сеть для подключения к каждому сетевому интерфейсу. Дважды щелкните сетевой интерфейс, чтобы открыть диалоговое окно «Настройка сети», и выберите общую сеть из раскрывающегося списка.
В диалоговом окне «Настройка сети» вы также можете указать MAC-адрес для определенного сетевого интерфейса. Если вы не укажете адрес, система автоматически установит MAC-адрес для каждого сетевого интерфейса.
Нажмите OK, когда закончите настройку сетевого интерфейса.
Примечание. После переноса новая виртуальная машина в системе everRun размещается на основном PM и остается в остановленном состоянии. Перед запуском виртуальной машины выполните миграцию, как описано в следующей процедуре.
-
Откройте страницу Виртуальные машины (см. Страница Виртуальные машины) в Консоли доступности everRun.
Выберите новую виртуальную машину на верхней панели и нажмите «Конфигурация», чтобы открыть мастер повторной инициализации виртуальной машины, как описано в разделе «Повторная инициализация ресурсов виртуальной машины». Используйте мастер, чтобы настроить нужные виртуальные ЦП, память, хранилище и сетевые параметры для виртуальной машины:
- Если у исходного PM или VM было несколько сетевых интерфейсов, настройте дополнительные сетевые интерфейсы, которые не были включены в процесс переноса.
- Если вы продолжите использовать исходный PM или VM, убедитесь, что MAC-адрес для каждого сетевого интерфейса в новой VM отличается от исходного PM или VM.
Нажмите "Готово" на последней странице мастера, чтобы изменения вступили в силу.
Отключите все службы гостевой операционной системы, которые не нужны для работы в системе everRun:
- Если вы мигрировали из источника PM, отключите все службы, взаимодействующие напрямую с оборудованием. Примеры включают:
- Dell OpenManage (OMSA)
- Диспетчер HP Insight
- Дискипер
- Если вы мигрировали из источника ВМ, отключите все службы, связанные с другими гипервизорами. Примеры включают:
- Инструменты VMware
- Инструменты Hyper-V
- Инструменты Citrix для виртуальных машин
После отключения этих служб перезапустите гостевую операционную систему, чтобы изменения вступили в силу.
После того, как вы убедились, что новая ВМ работает правильно, процесс миграции завершен; однако система может продолжать синхронизировать данные между PM, чтобы обеспечить работу в режиме высокой доступности (HA) или отказоустойчивости (FT).
После переноса ВМ с помощью P2V с компьютера с «голым железом» под управлением версии Ubuntu у ВМ могут возникнуть проблемы, например отсутствие активной сети. Чтобы устранить проблему, выполните соответствующую процедуру ниже после переноса виртуальной машины Ubuntu.
- В консоли everRun Availability Console откройте окно консоли в виртуальной машине.
- Войдите в виртуальную машину и перейдите в терминал.
- Введите следующую команду: cd /etc/network .
- Введите следующую команду: sudo vi interfaces .
- Измените интерфейс eno1 на ens3f0 .
- Сохраните изменения.
- Введите следующую команду: sudo systemctl перезапустить networking.service .
Следующая процедура не требует перезагрузки системы.
- В консоли everRun Availability Console откройте окно консоли в виртуальной машине.
- Войдите в виртуальную машину и перейдите в терминал.
- Введите следующую команду: ifconfig .
Обратите внимание, что вывод команды не включает eth0 .
Введите следующую команду:. есликонфиг -а .
Обратите внимание, что вывод команды включает eth0 .
Введите следующую команду: sudo vi interfaces .
В файле интерфейсов измените em1 на eth0 .
Введите следующую команду: sudo vi ifstate.eth0 .
В файле ifstate.eth0 вставьте eth0 в начале файла.
Следующая процедура требует перезагрузки виртуальной машины:
- Из everRun Availability Console откройте окно консоли в виртуальной машине.
- Войдите в виртуальную машину и перейдите в терминал.
- Отредактируйте файл /etc/network/interfaces, заменив em1 на eth0 .
- Перезагрузите виртуальную машину.
При необходимости используйте следующую информацию для решения проблем с процессом переноса.
Чтобы отменить процесс переноса
Выключите исходный PM или VM, на котором запущен клиент P2V.
Чтобы выполнить очистку после отмены или неудачной миграции
Откройте консоль доступности everRun и удалите все перенесенные тома, связанные с исходным PM или VM. Если вы хотите перезапустить процесс переноса, перезагрузите клиент P2V на исходном PM или VM.
Восстановление после неудачной миграции
Если процесс миграции завершается сбоем, в клиенте P2V на исходном PM или VM отображается сообщение об ошибке. В системе everRun может отображаться другое сообщение. Используйте эти сообщения, чтобы определить проблему.
Если миграция по-прежнему не удалась, а этот параметр доступен, включите отладку на стороне сервера. После переноса создайте файл диагностики для отправки авторизованному представителю службы поддержки Stratus, как описано в разделе Создание файла диагностики. Файл диагностики включает все сообщения отладки на стороне сервера, полученные в процессе переноса.
Чтобы восстановиться после миграции, которая завершилась сбоем с сообщением об ошибке Не удалось смонтировать '/dev/sda1: операция не разрешена
Если в процессе переноса PM или ВМ на базе Windows возникает сбой со следующим сообщением об ошибке, это может означать, что включен режим гибернации или быстрого запуска:
Не удалось смонтировать '/dev/sda1': операция не разрешена
Раздел NTFS находится в небезопасном состоянии. Пожалуйста, возобновите работу и полностью завершите работу Windows (без гибернации или быстрого перезапуска) или смонтируйте том только для чтения с параметром монтирования 'ro'.Чтобы решить эту проблему, отключите спящий режим и быстрый запуск в исходном PM или VM:
- Войдите в операционную систему исходного PM или VM.
- Откройте панель управления "Электропитание" и нажмите "Выбрать, что делают кнопки питания".
- Рядом с параметром Когда я нажимаю кнопку питания , выберите Выключить (вместо гибернации или спящего режима, если они есть).
- В разделе "Параметры завершения работы" снимите флажок "Включить быстрый запуск (рекомендуется)" , если он установлен.
- Нажмите Сохранить изменения .
Откройте Power Shell администратора и выполните следующую команду:
Восстановление, когда только что перенесенная виртуальная машина на базе Linux зависла в состоянии "загрузки"
Виртуальная машина на базе Linux может не выйти из состояния загрузки в everRun Availability Console, если сеть виртуальной машины отключена.
Во время миграции клиент P2V пытается установить новый MAC-адрес для каждого сетевого интерфейса, чтобы предотвратить конфликты с исходной виртуальной машиной. Некоторые операционные системы на базе Linux обнаруживают новый MAC-адрес и автоматически создают для него новый сетевой интерфейс, сохраняя при этом исходный интерфейс. Гостевая операционная система загружается, но сеть может оставаться в автономном режиме, пока вы не настроите параметры сети вручную.
Чтобы устранить проблему, откройте консоль виртуальной машины, войдите в гостевую операционную систему и обновите сценарии запуска сети. Убедитесь, что вы сохранили только одну запись для каждого сетевого интерфейса и что каждый интерфейс использует уникальный MAC-адрес и правильные сетевые настройки для вашей среды.
Чтобы восстановить отсутствующие тома данных на виртуальной машине в системе everRun
Если тома данных не отображаются на виртуальной машине в системе everRun после импорта, вам может потребоваться восстановить тома вручную следующим образом:
- Выключите виртуальную машину, запустите мастер повторной инициализации виртуальной машины и убедитесь, что вы включили тома на странице "Тома".
- Для виртуальных машин на базе Windows используйте Управление дисками, чтобы перевести тома данных в оперативный режим.
- Для виртуальных машин на базе Linux отредактируйте файл /etc/fstab, чтобы отразить новые имена устройств для устройств хранения, от Avance (от /dev/xvda до /dev/xvdh) до everRun (от /dev/vda до /dev). /вдх). Имена устройств также могли измениться, например, если тома не были включены в импорт.
Чтобы восстановить отсутствующие сетевые устройства в виртуальной машине в системе everRun
Если сетевые устройства не отображаются в виртуальной машине в системе everRun после импорта, вам может потребоваться восстановить их вручную следующим образом:
- Выключите виртуальную машину, запустите мастер повторной инициализации виртуальной машины и убедитесь, что вы включили сети на странице "Сети".
- Для виртуальных машин на базе Linux перенастройте сценарий запуска сети, чтобы он отражал новые имена устройств для сетевых интерфейсов.
Чтобы вручную установить новый сетевой драйвер
После переноса PM или VM сетевой драйвер может быть установлен неправильно (например, диспетчер устройств может указать драйвер с предупреждением ). В этой ситуации установите драйвер вручную:
- В окне консоли виртуальной машины откройте Диспетчер устройств в гостевой операционной системе.
- Разверните Сетевые адаптеры и щелкните правой кнопкой мыши Ethernet-адаптер Red Hat VirtIO (драйвер, который работает неправильно).
- Выберите «Обновить программное обеспечение драйвера».
- Во всплывающем окне нажмите Поиск драйвера на моем компьютере .
Нажмите "Выбрать из списка драйверов устройств" .
После установки драйвера проверьте состояние ВМ в консоли доступности everRun. Если состояние работает ( ), драйвер работает правильно.
Возможно/выполнимо ли перенести установку Ubuntu на виртуальную машину на физическую машину? Если возможно, насколько сложно это будет сделать и какие шаги мне нужно предпринять, чтобы подготовиться к переносу.
Я бы хотел протестировать виртуальную машину и, если получится, перенести эту систему на физическое оборудование, а не переустанавливать все заново. Возможно ли это?
5 ответов 5
Да, это возможно. Это даже не настолько сложно, просто потребуется некоторое время, компакт-диск с Ubuntu LiveCD, липкая задняя часть пластика и внешний USB-диск (если у вас не более одного внутреннего диска).
Предварительный шаг: Преобразуйте диск во что-нибудь полезное
И VMWare, и VirtualBox (среди прочего) используют форматы дисков, которые не подходят для прямой записи на диск. Вы можете, но я лично считаю, что удобнее сначала написать посреднику, стандартному изображению. Вы можете сделать это из своей текущей системы, не загружаясь с LiveCD.
Загрузите терминал и запустите:
Переместите /media/wherever-the-image-is/disk.img куда-нибудь, куда вы не собираетесь писать. Если вы планируете записать его на диск, на котором он находится в данный момент, вам следует поместить его на отдельный внутренний диск или, в худшем случае, на внешний диск.
Следующие инструкции предполагают, что вы переместили его в /media/dave/disk.img (dave — это внешний USB-диск)
Прежде чем писать что-то серьезное, убедитесь, что у вас есть резервные копии. Это клише, но одна опечатка, и есть вполне реальная возможность, что вы уничтожите свою систему. Предполагайте, что что-то пойдет не так, и будьте готовы. CloneZilla может помочь вам создавать резервные копии всего диска, если у вас есть место для хранения этих данных.
Записать образ на отдельный диск
Вы захотите сделать что-то подобное. Это предполагает, что вы собираетесь перезаписать весь диск. Если вы хотите выполнить установку параллельно с Windows, не следуйте этим инструкциям! Перейти после маркеров.
Загрузитесь с компакт-диска Ubuntu Live и нажмите «Попробовать Ubuntu».
Смонтируйте место, где хранится ваш образ vmdk (например, внешний USB-диск как /media/dave ). Не монтируйте место, куда вы хотите записать.
Тогда приступаем к работе:
Вы хотите заменить sdX на правильный путь к целевому диску. Пароль sudo пуст, просто нажмите «Ввод».
Затем вы можете открыть gparted или что-то еще, и вы должны увидеть свой раздел Ubuntu на диске. Вы должны иметь возможность расширить его.
Записать образ на диск вместе с другой операционной системой
Возможно, это более безопасный способ работы. Идея очень похожа, за исключением того, что вы правильно устанавливаете Ubuntu, а затем просто синхронизируете файлы из disk.img .
На этот раз ваш LiveCD должен иметь ту же версию Ubuntu, что и ваша виртуальная установка. Загрузитесь с Live CD и снова нажмите «Установить».
Следуйте инструкциям установщика, перераспределите элементы по своему усмотрению. Примерно через 10 минут вы будете установлены, и вам будет предложено перезагрузиться. Не перезагружайтесь.Неважно, если вы это сделаете случайно, просто убедитесь, что вы вернулись в LiveCD для получения следующих инструкций.
Смонтируйте раздел вашей новой установки и внешний диск, где вы ранее сохранили disk.img (просто дважды щелкните их в nautilus).
Смонтируйте ISO-образ disk.img в терминале:
-Примечание. После создания нужного файла .img иногда при попытке подключить его как кольцевое устройство может появиться следующая ошибка
"Отсутствует подпись NTFS. Не удалось смонтировать '/dev/loop0': недопустимый аргумент Устройство '/dev/loop0' не имеет действительной NTFS. "
Итак, если вы определили смещение как «xxx», вы можете смонтировать свой раздел с помощью
Оттуда вы можете либо выбрать файлы, либо просто скопировать все поверх вашей новой установки Ubuntu, используя что-то вроде:
Перезагрузитесь, и вы должны увидеть старую установку VMWare, но на голом железе. Если у вас возникнут неприятные проблемы с grub, вы можете исправить это, вернувшись к Live CD, chroot и исправив ситуацию.
Для установок в Windows/VirtualBox внутренние команды VBoxManage converttoraw your-virtualbox-disk.vdi /dev/sdX будут по-прежнему работать. Все, что нужно, это перейти в Program Files\Oracle\VirtualBox перед запуском первой команды.
@Aust Я сомневаюсь, что /dev/sdX является допустимой целью в Windows. Насколько я знаю, это будет \\Device\Harddisk0 или что-то в этом роде.
Внутренние команды VBoxManage converttoraw your-virtualbox-disk.vdi /dev/sdX не работают. В Linux выдает ошибку: VBoxManage: ошибка: невозможно создать файл назначения «/dev/sdX»: VERR_ALREADY_EXISTS. Необходимо использовать команду VBoxManage, чтобы сначала отправить его на изображение. Затем используйте DD, чтобы поместить образ на физический диск.
Возможно, это не совсем то, о чем вы просите, но это может привести к тому, что вы хотите сделать.
Поскольку все ваши настройки хранятся в вашем домашнем каталоге, вы можете просто сделать их резервную копию в другой раздел на реальном диске. После того, как вы установили новый Ubuntu на реальный диск, просто запустите программу резервного копирования еще раз, чтобы восстановить домашний каталог со всеми настройками.
Вы можете использовать действительно удобную программу резервного копирования под названием Déjà Dup.
Информация из центра программного обеспечения Ubuntu:
Déjà Dup – это простой инструмент для резервного копирования. Он скрывает сложность резервного копирования «Правильно» (зашифрованного, удаленного и обычного) и использует дублирование в качестве серверной части.
Поддержка локальных, удаленных или облачных хранилищ резервных копий, таких как Amazon S3 или Rackspace Cloud Files
Надежно шифрует и сжимает ваши данные
Инкрементное резервное копирование, позволяющее восстанавливать данные из любой конкретной резервной копии
Планирует регулярное резервное копирование
Хорошо интегрируется в рабочий стол GNOME
Вы закончите менее чем за два часа!
Идея состоит в том, чтобы передать весь ваш vmdk с виртуальной машины на физическую машину, где он записывается на физический жесткий диск.
Процедура описана ниже.
Поскольку у вас есть файл vmdk, в вашем распоряжении может быть рабочая станция VMWare, даже полная виртуальная машина, к которой подключен этот vmdk. Запустите вашу виртуальную машину с этим конкретным vmdk, но вместо обычной загрузки используйте PartedMagic liveCD для загрузки.
При запуске liveCD перейдите в главное меню и найдите клонирование диска UDPCast. Его диалоги говорят сами за себя (см. скриншот)
Выбрав эту виртуальную машину в качестве отправителя, вы должны выбрать, какой диск вы хотите транслировать (используя нотацию Unix, например, /dev/sda).
Стоит отметить, что вы должны принять все необходимые меры для обеспечения сетевого подключения между вашей виртуальной машиной и физическим оборудованием. Вы должны принять необходимые меры предосторожности, если ваш vmdk содержит личные данные, поскольку его содержимое будет эффективно передаваться по вашей сети. Другое дело, что ваш целевой hdd должен иметь не меньшую емкость, чем емкость вашего vmdk. Это очевидно, но также стоит отметить, что ваш образ расположен один к одному на целевом жестком диске, и вам необходимо выполнить соответствующие операции с gparted или подобным, чтобы использовать большую емкость вашего нового жесткого диска.
Если текущий хост виртуальной машины (ВМ) становится неподходящим или больше не может использоваться, или если вы хотите перераспределить рабочую нагрузку хостинга, вы можете перенести ВМ на другой хост KVM.
9.1. Как работает миграция виртуальных машин
Важной частью миграции виртуальной машины (ВМ) является копирование XML-конфигурации виртуальной машины на другой хост-компьютер. Если перенесенная виртуальная машина не отключена, миграция также передает состояние памяти виртуальной машины и всех виртуализированных устройств на конечный хост-компьютер. Чтобы виртуальная машина оставалась работоспособной на целевом хосте, образы дисков виртуальной машины должны оставаться доступными для нее.
По умолчанию перенесенная виртуальная машина является временной на целевом хосте и остается определенной также на исходном хосте.
Вы можете перенести работающую ВМ с помощью активной или неактивной миграции. Чтобы перенести отключенную ВМ, необходимо использовать автономную миграцию. Подробнее см. в следующей таблице.
Таблица 9.1. Типы миграции ВМ
Динамическая миграция
ВМ продолжает работать на исходном хост-компьютере, пока KVM передает страницы памяти ВМ на конечный хост. Когда миграция почти завершена, KVM очень ненадолго приостанавливает работу ВМ и возобновляет ее работу на целевом хосте.
Полезно для виртуальных машин, которым требуется постоянное время безотказной работы. Однако виртуальные машины, которые изменяют страницы памяти быстрее, чем их может передать KVM, например виртуальные машины с высокой нагрузкой ввода-вывода, не могут быть перенесены в режиме реального времени, и вместо этого необходимо использовать нединамическую миграцию.
Образы дисков ВМ должны располагаться в общей сети, доступной как для исходного, так и для целевого хоста.
Неактивная миграция
Приостанавливает работу ВМ, копирует ее конфигурацию и память на целевой хост и возобновляет работу ВМ.
Вызывает простои ВМ, но в целом более надежен, чем динамическая миграция. Рекомендуется для ВМ с высокой нагрузкой ввода-вывода.
Образы дисков ВМ должны располагаться в общей сети, доступной как для исходного, так и для целевого хоста.
Офлайн-миграция
Перемещает конфигурацию ВМ на целевой хост
Рекомендуется для отключения ВМ.
Образы дисков ВМ не обязательно должны быть доступны в общей сети. Вместо этого их можно копировать или перемещать вручную на целевой хост.
Дополнительные ресурсы
- Дополнительную информацию о преимуществах миграции виртуальных машин см. в разделе 9.2, «Преимущества миграции виртуальных машин».
- Инструкции по настройке общего хранилища для переноса ВМ см. в Раздел 9.4, «Совместное использование образов дисков виртуальных машин с другими хостами».
9.2. Преимущества переноса виртуальных машин
Миграция виртуальных машин (ВМ) может быть полезна для:
Виртуальные машины балансировки нагрузки можно переместить на менее загруженные хост-компьютеры, если их хост перегружен или если другой хост недогружен. Независимость от оборудования Когда вам нужно обновить, добавить или удалить аппаратные устройства на хост-компьютере, вы можете безопасно переместить виртуальные машины на другие хосты. Это означает, что виртуальные машины не испытывают простоя для усовершенствования оборудования. Энергосберегающие виртуальные машины могут быть перераспределены на другие хосты, и, таким образом, незагруженные хост-системы могут быть отключены для экономии энергии и сокращения расходов в периоды низкого использования. Виртуальные машины с географической миграцией можно перемещать в другое физическое расположение для снижения задержки или по другим причинам.
9.3. Ограничения на перенос виртуальных машин
Перед переносом виртуальных машин (ВМ) в RHEL 8 убедитесь, что вы знаете об ограничениях переноса.
- Миграция динамического хранилища невозможна в RHEL 8, но вы можете перенести хранилище, когда виртуальная машина отключена. Обратите внимание, что динамическая миграция хранилища доступна в Red Hat Virtualization.
- Миграция виртуальных машин из или в сеансовое соединение libvirt ненадежна и поэтому не рекомендуется.
ВМ с назначенными хост-устройствами не будут работать должным образом после миграции, или миграция завершится ошибкой. К таким конфигурациям относятся:
- Переход через устройство
- Назначение устройства SR-IOV
- Устройства-посредники, такие как vGPU
Эмулируемые ЦП как на исходной ВМ, так и на целевой ВМ должны быть идентичными, иначе миграция может завершиться ошибкой. Любые различия между ВМ в следующих областях, связанных с ЦП, могут вызвать проблемы при переносе:
- Модель ЦП
- Настройки прошивки
- Версия микрокода
- Версия BIOS
- Настройки BIOS
- Версия QEMU
- Версия ядра
9.4. Совместное использование образов дисков виртуальной машины с другими хостами
Для выполнения динамической миграции виртуальной машины (ВМ) между поддерживаемыми узлами KVM требуется общее хранилище ВМ. В этом разделе приведены инструкции по совместному использованию локально сохраненного образа ВМ на исходном и целевом хостах с использованием протокола NFS.
Предпосылки
- ВМ, предназначенная для переноса, отключена.
- Необязательно: хост-система доступна для размещения хранилища, которое не является исходным или целевым хостом, но и исходный, и конечный хост могут получить к нему доступ через сеть. Это оптимальное решение для общего хранилища, рекомендованное Red Hat.
- Убедитесь, что блокировка файлов NFS не используется, так как она не поддерживается в KVM.
NFS установлена и включена на исходном и целевом хостах. Если это не так:
Установите пакеты NFS:
Убедитесь, что порты для NFS, например 2049, открыты в брандмауэре.
Запустите службу NFS.
Процедура
Подключитесь к хосту, который предоставит общее хранилище. В данном примере это узел грузового отсека:
Создайте каталог, в котором будет храниться образ диска и который будет использоваться совместно с узлами переноса.
Скопируйте образ диска ВМ с исходного хоста во вновь созданный каталог. Например, следующий код копирует образ диска виртуальной машины странник1 в каталог /var/lib/libvirt/shared-images/ на хосте `cargo-bay`:
На хосте, который вы хотите использовать для общего доступа к хранилищу, добавьте общий каталог в файл /etc/exports. В следующем примере каталог /var/lib/libvirt/shared-images используется совместно с хостами исходного и конечного примеров:
И на исходном, и на целевом хосте смонтируйте общий каталог в каталоге /var/lib/libvirt/images:
Подтверждение
- Чтобы убедиться, что процесс прошел успешно, запустите виртуальную машину на исходном хосте и проверьте, правильно ли она загружается.
Дополнительные ресурсы
9.5. Миграция виртуальной машины с помощью интерфейса командной строки
Если текущий хост виртуальной машины (ВМ) становится неподходящим или больше не может использоваться, или если вы хотите перераспределить рабочую нагрузку хостинга, вы можете перенести ВМ на другой хост KVM. В этом разделе приведены инструкции и примеры для различных сценариев такой миграции.
Предпосылки
- И исходный хост, и конечный хост используют гипервизор KVM.
- Хост-источник и хост-получатель могут связываться друг с другом по сети. Используйте утилиту ping, чтобы проверить это.
- Чтобы Red Hat поддерживала миграцию, на исходном и целевом хостах должны использоваться определенные операционные системы и типы компьютеров. Чтобы убедиться в этом, см. Раздел 9.7, «Поддерживаемые хосты для миграции виртуальных машин».
Образы дисков ВМ, которые будут перенесены, расположены в отдельном сетевом расположении, доступном как для исходного, так и для целевого хоста. Это необязательно для автономной миграции, но необходимо для миграции работающей ВМ.
При переносе работающей ВМ пропускная способность сети должна быть выше, чем скорость, с которой ВМ создает грязные страницы памяти.
Чтобы получить частоту грязных страниц для вашей ВМ до начала динамической миграции, выполните следующие действия:
Контролируйте скорость создания грязных страниц виртуальной машиной в течение короткого периода времени.
После завершения мониторинга получите его результаты:
В этом примере виртуальная машина генерирует 2 МБ грязных страниц памяти в секунду. Попытка динамической миграции такой ВМ в сети с пропускной способностью 2 МБ/с или менее приведет к тому, что динамическая миграция не будет выполняться, если вы не приостановите работу ВМ или не снизите ее рабочую нагрузку.
Чтобы обеспечить успешное завершение динамической миграции, Red Hat рекомендует, чтобы пропускная способность вашей сети была значительно выше, чем скорость создания грязных страниц виртуальной машиной.
Убедитесь, что служба libvirtd включена и работает.
Процедура
Используйте команду virsh migrate с параметрами, соответствующими вашим требованиям миграции.
Следующее выполняет миграцию виртуальной машиныстранника1 с вашего локального хоста на системное подключение хоста целевого примера с использованием туннеля SSH. ВМ продолжит работу во время переноса.
Следующее позволяет вручную изменить конфигурацию виртуальной машиныстранника2, работающей на локальном хосте, а затем перенести виртуальную машину на хост-пример назначения. Перенесенная виртуальная машина автоматически будет использовать обновленную конфигурацию.
Эта процедура может быть полезна, например, когда целевому хосту необходимо использовать другой путь для доступа к общему хранилищу ВМ или при настройке функции, специфичной для целевого хоста.
Следующее приостанавливает работу виртуальной машиныстранника3 с хоста исходного примера, переносит ее на хост конечного примера и дает ей указание использовать скорректированную конфигурацию XML, предоставленную файломстранник3-alt.xml. Когда миграция завершена, libvirt возобновляет работу виртуальной машины на целевом хосте.
После переноса виртуальная машина остается в приостановленном состоянии на исходном хосте, а перенесенная копия удаляется после завершения работы.
Следующее удаляет выключенную виртуальную машину Wanderer4 с хоста исходного примера и перемещает ее конфигурацию на хост целевого примера.
Обратите внимание, что этот тип миграции не требует перемещения образа диска ВМ в общее хранилище. Однако, чтобы виртуальную машину можно было использовать на целевом хосте, необходимо перенести образ диска виртуальной машины. Например:
Дождитесь завершения переноса. Процесс может занять некоторое время в зависимости от пропускной способности сети, загрузки системы и размера виртуальной машины. Если параметр --verbose не используется для virsh migrate , интерфейс командной строки не отображает никаких индикаторов выполнения, кроме ошибок.
Во время миграции вы можете использовать утилиту virsh domjobinfo для отображения статистики миграции.
Подтверждение
На целевом хосте перечислите доступные ВМ, чтобы проверить, была ли миграция ВМ:
Если миграция все еще выполняется, эта команда отобразит состояние ВМ как приостановленное.
Устранение неполадок
-
В некоторых случаях целевой хост будет несовместим с определенными значениями XML-конфигурации перенесенной виртуальной машины, такими как сетевое имя или тип ЦП. В результате виртуальная машина не сможет загрузиться на целевом хосте. Чтобы устранить эти проблемы, вы можете обновить проблемные значения с помощью команды редактирования virsh.
Если динамическая миграция занимает много времени, это может быть связано с тем, что виртуальная машина находится под большой нагрузкой и изменяется слишком много страниц памяти, чтобы динамическая миграция была возможной. Чтобы решить эту проблему, измените миграцию на неактивную, приостановив виртуальную машину.
Дополнительные ресурсы
- Дополнительные параметры и примеры миграции виртуальных машин см. в virsh migrate --help или на справочной странице virsh.
9.6. Живая миграция виртуальной машины с помощью веб-консоли
Если вы хотите перенести виртуальную машину (ВМ), которая выполняет задачи, требующие ее постоянной работы, вы можете перенести эту ВМ на другой хост KVM, не выключая ее. Это также известно как живая миграция. В следующих инструкциях объясняется, как это сделать с помощью веб-консоли.
Для задач, которые изменяют страницы памяти быстрее, чем KVM может их передать, например задач с высокой нагрузкой ввода-вывода, рекомендуется не выполнять динамическую миграцию виртуальной машины.
Предпосылки
- В вашей системе установлен подключаемый модуль виртуальной машины для веб-консоли.
- Исходный и конечный хосты работают.
- Образы дисков ВМ находятся в общем хранилище, доступном как для исходного, так и для целевого хоста.
При переносе работающей ВМ пропускная способность сети должна быть выше, чем скорость, с которой ВМ создает грязные страницы памяти.
Чтобы получить частоту грязных страниц для вашей ВМ до начала динамической миграции, выполните следующие действия в интерфейсе командной строки:
Контролируйте скорость создания грязных страниц виртуальной машиной в течение короткого периода времени.
После завершения мониторинга получите его результаты:
В этом примере виртуальная машина генерирует 2 МБ грязных страниц памяти в секунду. Попытка динамической миграции такой ВМ в сети с пропускной способностью 2 МБ/с или менее приведет к тому, что динамическая миграция не будет выполняться, если вы не приостановите работу ВМ или не снизите ее рабочую нагрузку.
Чтобы обеспечить успешное завершение динамической миграции, Red Hat рекомендует, чтобы пропускная способность вашей сети была значительно выше, чем скорость создания грязных страниц виртуальной машиной.
Процедура
В интерфейсе виртуальных машин веб-консоли нажмите кнопку меню ⋮ для виртуальной машины, которую вы хотите перенести.
Появится раскрывающееся меню с элементами управления различными операциями с ВМ.
Появится диалоговое окно "Перенос виртуальной машины на другой хост".
Настройте продолжительность переноса:
- Постоянно — не устанавливайте этот флажок, если вы хотите перенести виртуальную машину на постоянной основе. Постоянная миграция полностью удаляет конфигурацию ВМ с исходного хоста.
- Временный — при временном переносе копия виртуальной машины переносится на целевой хост. Эта копия удаляется с целевого хоста при выключении виртуальной машины. Исходная ВМ остается на исходном хосте.
Ваша виртуальная машина перенесена на целевой хост.
Подтверждение
Чтобы убедиться, что виртуальная машина была успешно перенесена и работает правильно:
- Убедитесь, что ВМ отображается в списке ВМ, доступных на целевом хосте.
- Запустите перенесенную виртуальную машину и посмотрите, загружается ли она.
9.7. Поддерживаемые хосты для переноса виртуальных машин
Чтобы миграция виртуальной машины (ВМ) работала правильно и поддерживалась Red Hat, исходный и конечный хосты должны иметь определенные версии RHEL и типы машин. В следующей таблице показаны поддерживаемые пути миграции ВМ.
Таблица 9.2. Совместимость с динамической миграцией
В поддерживаемых системах RHEL 7: типы компьютеров i440fx и q35
В поддерживаемых системах RHEL 8: типы компьютеров i440fx и q35
В поддерживаемых системах RHEL 7: типы компьютеров i440fx и q35 в RHEL 7.6.0 и более поздних версиях.
В поддерживаемых системах RHEL 8: тип машины q35 .
В поддерживаемых системах RHEL 7. Полностью поддерживается для машин типов i440fx и q35.
Динамическая миграция позволяет перемещать работающую виртуальную машину между физическими хостами без прерывания обслуживания. Виртуальная машина остается включенной, а пользовательские приложения продолжают работать, пока виртуальная машина перемещается на новый физический хост. В фоновом режиме оперативная память виртуальной машины копируется с исходного узла на целевой узел. Хранилище и сетевое подключение не изменяются.
6.13.1. Предварительные требования для динамической миграции
Динамическая миграция используется для беспрепятственного перемещения виртуальных машин для поддержки ряда общих задач обслуживания.Заблаговременно убедитесь, что ваша среда виртуализации Red Hat правильно настроена для поддержки динамической миграции.
Исходный и конечный хосты должны быть членами одного и того же кластера, чтобы обеспечить совместимость ЦП между ними.
Примечание
Исходный и конечный хосты должны иметь доступ к домену хранилища данных, в котором находится виртуальная машина.
На целевом хосте должно быть достаточно мощности ЦП для поддержки требований виртуальной машины.
На целевом хосте должно быть достаточно оперативной памяти, которая не используется для поддержки требований виртуальной машины.
Кроме того, для лучшей производительности сети хранения и управления должны быть разделены, чтобы избежать перегрузки сети. Миграция виртуальной машины включает передачу больших объемов данных между хостами.
Динамическая миграция выполняется с использованием сети управления. Каждое событие динамической миграции ограничено максимальной скоростью передачи 30 МБ/с, и количество поддерживаемых одновременных миграций также ограничено по умолчанию. Несмотря на эти меры, параллельные миграции могут привести к перенасыщению сети управления. Рекомендуется создавать отдельные логические сети для хранения, отображения и данных виртуальной машины, чтобы свести к минимуму риск перенасыщения сети.
6.13.2. Оптимизация динамической миграции
Динамическая миграция виртуальных машин может быть ресурсоемкой операцией. Следующие два параметра можно задать глобально для каждой виртуальной машины в среде, на уровне кластера или на уровне отдельной виртуальной машины, чтобы оптимизировать динамическую миграцию.
Параметр миграции Auto Converge позволяет указать, будет ли использоваться автоконвергенция во время динамической миграции виртуальных машин. Большие виртуальные машины с высокой рабочей нагрузкой могут загрязнять память быстрее, чем скорость передачи, достигаемая во время динамической миграции, и препятствовать конвергенции миграции. Возможности автоматической конвергенции в QEMU позволяют форсировать конвергенцию миграций виртуальных машин. QEMU автоматически обнаруживает отсутствие конвергенции и запускает дросселирование виртуальных ЦП на виртуальной машине.
Параметр «Включить сжатие миграции» позволяет указать, используется ли сжатие миграции во время динамической миграции виртуальной машины. Эта функция использует Xor Binary Zero Run-Length-Encoding, чтобы сократить время простоя виртуальной машины и общее время динамической миграции для виртуальных машин, выполняющих рабочие нагрузки с интенсивным записью в память, или для любого приложения с разреженным шаблоном обновления памяти.
Процедура 6.28. Настройка автоматической конвергенции и сжатия при миграции для миграции виртуальной машины
Читайте также: