Глава 7. Виртуальные машины: Установка, настройка и управление жизненным циклом

Содержание

Глава 7. Виртуальные машины: Установка, настройка и управление жизненным циклом
Создание ВМ при помощи virt-manager
Применение virt-manager
Применение команд virt-*
virt-viewer
virt-xml
virt-clone
qemu-img
Создание новой ВМ при помощи Cockpit
Создание новой ВМ при помощи oVirt
Настройка вашей ВМ
Добавление и удаление оборудования в вашей ВМ
Миграция ВМ
Преимущества миграции ВМ
Настройка необходимой среды
Миграция в отключённом состоянии
Миграция в реальном времени или во включённом состоянии
Выводы
Вопросы
Дальнейшее чтение

В этой главе мы изучим различные способы установки и настройки Виртуальных мащин (ВМ, VM) - из приглашения командной строки и/ или Графического интерфейса пользователя (GUI, graphical user interface). Мы глубже окунёмся в некоторые инструменты и утилиты, которые мы уже применяли (virt-manager, virt-install, oVirt) и выстроим свои знания, полученные в предыдущих главах. Затем мы пространно обсудим миграцию ВМ, одну из наиболее основательных сторон виртуализации, поскольку практически невозможно представить себе применение виртуализации без вариантов миграции. Чтобы быть способными настроить своё окружение под миграцию ВМ, мы также воспользуемся темами, обсуждавшимися в Главе 4, Сетевая среда libvirt и в Главе 5, Хранилище libvirt, ибо для работы миграции имеются предварительные условия, которые должны быть выполнены.

В данной главе мы обсудим следующие темы:

  • Создание новой ВМ при помощи virt-manager и с применением команд virt.

  • Создание новой ВМ с использованием oVirt

  • Настройку вашей ВМ

  • Добавление виртуального оборудования в вашу Вм и его удаление из неё

  • Миграцию ВМ

Создание ВМ при помощи virt-manager

virt-manager (инструмент с графическим интерфейсом для управления ВМ) и virt-install (утилита командной строки для управления ВМ) это две наиболее широко применяемые утилиты в виртуализации KVM (Kernel-based VM, Основанных на ядре ВМ). Применяя их, мы способны делать со своими ВМ практически всё - создавать, запускать, удалять и многое иное. Нам уже выпадала в предыдущих главах возможность поработать с этими двумя утилитами, но мы нуждаемся в более структурированном подходе к этому предмету, поскольку они предлагают загрузку дополнительных вариантов, которые у нас пока не было возможности обсуждать. Мы также добавим некоторые прочие утилиты, которые являются частью стека команд virt-*, которые весьма, весьма полезны.

Давайте начнём с virt-manager и его знакомого GUI.

Применение virt-manager

virt-manager это ключевая утилита с графическим интерфейсом управления ВМ KVM. Она чрезвычайно понятна и проста в применении, хотя слегка и обделена функциональностью, о чём мы расскажем позднее. Вот основное окно virt-manager:

 

Рисунок 7-1


Основное окно virt-manager

Из данного снимка экрана мы можем видеть, что в данном сервере уже имеются установленными три виртуальные машины. Мы можем пользоваться меню верхнего уровня (File, Edit, View и Help)для дальнейшей настройки своего сервера и/ или ВМ, а также подключаться к прочим хостам KVM в своей сетевой среде, как вы можете это наблюдать на следующем снимке экрана:

 

Рисунок 7-2


Подключение к другому хосту KVM при помощи параметра Add Connection…

После того как мы выбрали вариант Add Connection…, нас поприветствует мастер подключения к внешнему хосту и нам потребуется лишь пробить некоторые основные сведения - значение имени пользователя (он обязан быть пользователем, который обладает правами администратора) и названием хоста или адресом Internet Protocol (IP) этого удалённого сервера. Прежде чем мы сделаем это, нам также потребуется настроить ключи Secure Shell (SSH) в своей локальной машине и скопировать свой ключ в эту удалённую машину, ибо это установленный по умолчанию метод идентификации для virt-manager. Этот процесс отображён на следующем снимке экрана:

 

Рисунок 7-3


Подключение к удалённому хосту KVM

На данном этапе вы можете приступить к бесплатной установке своей ВМ в этом удалённом хосте KVM, если вы решите это осуществить, щёлкните правой кнопкой по имени хоста и выберите New, как это отображено на следующем снимке экрана:

 

Рисунок 7-4


Создание новой ВМ в удалённом хосте KVM

Поскольку данный мастер тот же самый что и для установки ВМ в вашем локальном сервере, мы рассмотрим обе эти ситуации за один проход. Самый первый шаг в нашем мастере New VM состоит в выборе того, где вы устанавливаете свою ВМ и откуда. Как вы можете обнаружить на приводимом ниже снимке экрана, существуют доступными четыре варианта:

 

Рисунок 7-5


Выбор носителя запуска

Эти варианты таковы:

  • Когда у вас уже имеется доступным файл ISO (International Organization for Standardization) в вашей локальной машине (или в качестве физического устройства), выбирайте самый первый вариант.

  • Кли вы желаете выполнять установку из своей сетевой среды, выбирайте второй вариант.

  • Если вы обладаете в своей среде установкой запуска PXE (Preboot eXecution Environment) и вы способны запускать установку своей ВМ из имеющейся сетевой среды, выберите третий вариант.

  • Когда у вас уже имеется диск ВМ и вы просто желаете воспользоваться им в качестве основы для определяеиой ВМ, выбирайте четвёртый способ.

Обычно мы обсуждаем сетевые установки (второй вариант) или сетевые установки с PXE- запуском (третий вариант), поскольку это наиболее популярные варианты применения в промышленных случаях. Основная причина для этого очень проста - абсолютно нет нужды тратить впустую локальное дисковое пространство под файлы ISO, которые в наши дни достаточно велики. Например, файл ISO CentOS 8 v190 составляет в размере почти 8 гигабайт (ГБ). Если вам требуется способность установки множества операционных систем или даже множества версий этих операционных систем, вам лучше быть в состоянии с неким видом централизованного пространства хранения только под ISO файлы.

В основанных на VMware ESXi (ESX integrated) инфраструктурах люди обычно используют для такой функциональности хранилища данных или библиотеки содержимого ISO. В инфраструктурах на основе Microsof Hyper-V люди обычно применяют совместное хранилище файлов SMB (Server Message Block) с файлами ISO, необходимыми для установки ВМ. Было бы совершенно бессмысленно иметь копию ISO операционной системы для каждого хоста, поэтому какой-то общий подход намного удобнее и является хорошим механизмом экономии места.

Допустим, мы устанавливаем ВМ из сетевой среды (HTTP (HyperText Transfer Protocol), HTTPS (HyperText Transfer Protocol Secure) или FTP (File Transfer Protocol)). Для продолжения нам понадобится пара вещей, а именно:

  • Некий URL (Uniform Resource Locator), с которого мы можем завершить установку - в нашем примере мы намерены применять http://mirror.linux.duke.edu/pub/centos. По этой ссылке выберите самый последний каталог 8.x.x, а затем пройдите в BaseOS/x86_64/os.

  • Очевидно, работающее подключение к Интернету - как можно более быстрое, ибо мы намерены загружать все установочные пакеты со своего предыдущего адреса URL.

  • Как вариант, мы можем открыть треугольник URL options и воспользоваться дополнительными вариантами для строки ядра - чаще всего параметры запуска с точка (kickstart) с чем- то вроде следующего:

    
ks=http://kickstart_file_url/file.ks

Итак, давайте наберём это следующим образом:

 

Рисунок 7-6


Выбор URL и гостевой операционной системы

Обратите внимание, что мы вручную выбрали Red Hat Enterprise Linux 8.0, поскольку целевая гостевая операционная система CentOS 8 (1905), которую не распознал virt-manager из предписанного нами URL. Если бы эта операционная система присутствовала в нашем перечне распознаваемых в данный момент операционных систем, мы бы могли просто выбрать соответствующую флаговую кнопку Automatically detect from installation media / source, которую порой требуется перепроверить и отменить пометку пару раз пока она не сработает.

После того как вы кликните по кнопке Forward, мы столкнёмся с установками для этой ВМ памяти и ЦПУ (CPU, central processing unit). И снова, вы сможете здесь пойти двумя путями следующим образом:

  • Выбрать голый минимум ресурсов (например, 1 vCPU (virtual CPU) и 1 ГБ памяти, а затем добавлять если вам потребуется больше лошадиных сил ЦПУ и/ или больше памяти.

  • Выбрать пристойный объём ресурсов (скажем, 2 vCPU и 4 ГБ ОЗУ) имея в виду конкретное применение. Например, когда мы намерены применять эту ВМ в качестве файлового сервера, вы не получите жутко много мощности если вы добавите в неё 16 vCPU и 64 ГБ оперативной памяти, однако имеются и прочие варианты применения, когда это окажется подходящим.

Наш следующий шаг состоит в настройке хранилища ВМ. Имеются два возможных варианта, и можем обнаружить их на слвоём следующем снимке экрана:

 

Рисунок 7-7


Настройка хранилища ВМ

Очень важно чтобы вы выбрали для своей ВМ надлежащее устройство хранения, поскольку если вы этого не сделаете, у вас могут быть в будущем проблемы разного сорта. Например, если вы поместите в промышленной среде свою ВМ на плохое устройство хранения, вам придётся выполнять миграцию хранилища этой ВМ в другое устройство хранения, что является утомительным и временеёмким процессом, который будет обладать воздействиями отвратительной силы если вам придётся загружать запущенные ВМ на устройстве хранения источника или получателя. Для того кто запускает это окажет существенное воздействие на его производительность. Далее, если у вас имеется в вашей среде некий механизм динамического управления рабочими нагрузками, это может включать в вашей инфраструктуре дополнительные ВМ или перемещения хранилищ ВМ. Такие функциональные возможности, как Distributed Resource Scheduler (DRS)/ Storage DRS VMware, оптимизация производительности и ресурсов Hyper-V (прт интеграции с System Center Operations Manager (SCOM) ), а также политики управления кластером oVirt/ Red Hat Enterprise Virtualization поступают именно так. Поэтому приспособление к стратегии подумай дважды, прежде чем сделать здесь может оказаться уместным подходом.

Если вы выберете первый вариант, Create a disk image for the virtual machine, virt-manager создаст жёсткий диск ВМ в установленном по умолчанию местоположении, для Red Hat Enterprise Linux (RHEL) и CentOS это каталог /var/lib/libvirt/images. Убедитесь что у вас имеется достаточно пространства под жёсткий диск вашей ВМ. Допустим, у вас имеется свободным 8 ГБ пространства, доступного в каталоге /var/lib/libvirt/images и лежащих в его основе разделах. Если вы оставите всё как есть из ситуации на нашем предыдущем снимке экрана, мы получим сообщение об ошибке потому как пытаемся создать файл в 10 ГБ в имеющем лишь 8 ГБ локальном диске.

После того как мы кликнем снова по кнопке Forward, мы окажемся на финальной стадии процесса создания своей ВМ (которая появится в virt-manager), персонализации самой конфигурации перед процессом её установки и выбора того какую виртуальную сетевую среду будет применять эта ВМ. В этой главе мы слегка подробнее рассмотрим индивидуализацию оборудования под свою ВМ. После того как мы нажимаем на Finish, как то показано на идущем далее снимке экрана, ваша ВМ будет готова к развёртыванию, а после того как мы установим необходимую операционную систему - и к применению:

 

Рисунок 7-8


Завершающий шаг настройки virt-manager

Применение virt-manager для создания некой ВМ, определённо, не было сложной задачей, однако в реальных промышленных средах вы не обязательно обнаружите установленном на сервере графический интерфейс. Таким образом, нашей логичной следующей задачей будет узнать об утилитах командной строки для управления ВМ, в особенности, о командах virt-*. Давайте займёмся этим далее.

Применение команд virt-*

Как уже упоминалось ранее, нам необходимо изучить некоторые новые команды для овладения необходимой задачей базового администрирования ВМ. Для этой конкретной задачи у нас имеется стек команд virt-*. Давайте кратко пройдёмся по некоторым наиболее важным из них и изучим как их применять.

 

virt-viewer

Мы уже интенсивно применяли команду virt-install ранее (проверьте Главу 3, Установка гипервизора KVM, libvirt и oVirt, в которой мы установили достаточно ВМ при помощи этой команды), мы намерены рассмотреть оставшиеся команды.

Давайте начнём с virt-viewer, поскольку мы уже пользовались этим приложением ранее. всякий раз как мы дважды кликаем по некой ВМ в virt-viewer, мы открываем консоль ВМ и это происходит по той причине, что virt-viewer выступает в фоновом режиме этой процедуры. Но что если мы желаем применять virt-viewer из оболочки - как это часто делают люди - нам требуются некие сведения относительно этого. Итак, давайте воспользуемся парой примеров.

Прежде всего давайте подключимся к локальному KVM с названием MasteringKVM01, который располагается в том хосте, к которому мы в настоящий момент подключены от имени root, запустив следующую команду:


# virt-viewer --connect qemu:///system MasteringKVM01

К тому же мы желаем подключиться к своей ВМ в режиме kiosk, что означает, что virt-viewer будет закрыт после того как мы выключим ту ВМ, к которой мы подключены. Для этого нам бы следовало выполнить такую команду:


# virt-viewer --connect qemu:///system MasteringKVM01 --kiosk --kiosk-quit on-disconnect

Если нам требуется подключиться к удалённому хосту, мы также можем воспользоваться virt-viewer, однако нам потребуется пара дополнительных параметров. Наиболее распространённый способ аутентификации в удалённой системе заключается в работе через SSH, а потому мы можем поступить так:


# virt-viewer --connect qemu+ssh://username@remote-host/system VirtualMachineName

Когда мы настроим ключи SSH и скопируем их в username@remote-host, наша предыдущая команда не будет запрашивать у нас пароль. Но если мы не сделаем этого, она запросит у нас пароль дважды - для установления подключения к гипервизору и для установления соединения с сеансом Virtual Network Computing (VNC) этой ВМ.

 

virt-xml

Наша следующая утилита командной строки из списка virt-xml. Мы можем применять её вместе параметрами командной строки virt-virtinstall для изменения настроек своей ВМ. Давайте начнём с базового примера - давайте просто включим меню запуска для этой ВМ следующим образом:


# virt-xml MasgteringKVM04 --edit --boot bootmenu=on

Затем давайте добавим в эту ВМ диск с динамическим выделением за три шага - прежде всего создадим сам такой диск, а затем подключим его своей ВМ и проверим что всё работает как надо. Получаемый вывод можно видеть на приводимом следом снимке экрана:

 

Рисунок 7-9


Добавление динамически выделяемого виртуального диска формата qcow2 (copy- on- write, копируемого записью) в ВМ

Как вы можете видеть, virt-xml достаточно полезна. С её помощью мы добавили ещё один диск к своей ВМ и это всего лишь одна простейшая вещь, которую мы могли сделать. Мы также можем применять её для развёртывания любых дополнительных частей оборудования к имеющейся ВМ. Мы также можем применять её для изменения настроек ВМ, что действительно удобно в средах больше́го размера, в особенности когда вам необходимо писать сценарий для автоматизации таких процедур.

 

virt-clone

Давайте проверим virt-clone при помощи пары примеров. Скажем, мы просто хотим быстрый и простой способ клонирования некоторой имеющейся ВМ без каких бы то ни было дополнительных сложностей. Мы можем сделать это следующим образом:


# virt-clone --original VirtualMachineName --auto-clone

В результате это произведёт ВМ с названием VirtualMachineName-clone, которую мы сразу начнём использовать. Давайте посмотрим на это в действии:

 

Рисунок 7-10


Создание клона ВМ при помощи virt-clone

Давайте посмотрим как это можно слегка персонализировать. При помощи virt-clone мы собираемся создать ВМ с названием MasteringKVM05 через клонирование ВМ, именуемой как MasteringKVM04, и мы собираемся также индивидуализировать и названия виртуальных дисков, что проиллюстрировано на следующем снимке экрана:

 

Рисунок 7-11


Персонализированное создание ВМ: индивидуализация названий ВМ и имён файлов виртуальных жёстких дисков

В реальной практике имеются ситуации которые требуют от вас преобразования ВМ из одной технологии виртуализации в иную. Груда подобной работы состоит в реальном преобразовании имеющегося формата диска ВМ из одного формата в другой. Этому посвящена virt-convert. Давайте изучим как она это выполняет.

 

qemu-img

Давайте посмотрим как мы преобразовываем виртуальный диск из одного формата в другой и как мы можем конвертировать некий файл настроек из одного метода виртуализации в другой. В качестве источника мы воспользуемся ВМ VMware и преобразуем её виртуальный диск vmdk и файл .vmx в некий новый формат, что иллюстрируется приводимым ниже снимком экрана:

 

Рисунок 7-12


Преобразование виртуального диска VMware в формат для KVM

Когда мы сталкиваемся с проектами, в которые вовлечены перемещения и конвертации ВМ между этими платформами, нам необходимо иметь уверенность, что применим такие утилиты, поскольку их просто использовать и понимать, и они требуют всего лишь одного момента - немного времени. Например, когда у нас имеется виртуальный диск VMware в 1 терабайт (ТБ, VM Disk (VMDK) и плоский файл VMDK), для преобразования в формат qcow2 могут понадобиться часы, а потому нам необходимо быть терпеливыми.Кроме того, нам потребуется время от времени быть готовыми к изменению файлов настроек vmx, поскольку процесс преобразования из vmx в kvm не на 100% гладок, как мы могли бы ожидать. На протяжении прохождения этого процесса создаётся новый файл настроек. Каталог по умолчанию для файлов настроек ВМ KVM /etc/libvirt/qemu и мы можем просто просматривать файлы Extensible Markup Language (XML) в этом каталоге - это файлы настроек наших ВМ KVM. Названия файлов, представляют имена ВМ из списка вывода virsh.

 

Рисунок 7-13


Названия файлов, представляющие имена ВМ

В CentOS существуют также некоторые утилиты, которые упрощают для нас управление не только самим локальным сервером, но и виртуальными машинами. Одним из таких выступает веб интерфейс Cockpit - он обладает способностью выполнять базовое управление ВМ в неком локальном хосте KVM {Прим. пер.: и в удалённых также}. Всё что нам требуется, это просто подключиться к нему через веб браузер и мы упоминали об этом в Главе 3, Установка гипервизора KVM, libvirt и oVirt, когда обсуждали развёртывание приложений oVirt. {Прим. пер.: также рекомендуем наш перевод Дополнение A, Обзор веб интерфейса Cockpit CentOS 8 (Глава 7 Всего сущего CentOS 8)}. Итак, давайте ознакомимся с управлением ВМ при помощи Cockpit.

Создание новой ВМ при помощи Cockpit

Чтобы воспользоваться Cockpit для управления нашим сервером и его ВМ, нам потребуется установить и запустить Cockpit и его дополнительные пакеты. Давайте начнём с этого следующим образом:


# dnf -y install cockpit*
# systemctl enable --now cockpit.socket

После этого мы можем запустить Firefox и указать ему https://kvm-host:9090/, так как это значение порта по умолчанию, по которому можно достигать Cockpit, а также зарегистрируемся в качестве root с его значением пароля, что предоставит нам следующий интерфейс пользователя (user interface (UI)):

 

Рисунок 7-14


Веб консоль Cockpit, которую можно применять для развёртывания ВМ

На своём предыдущем шаге,когда мы устанвливали cockpit*, мы также установили и cockpit-machines, который является подключаемым модулем для самой веб консоли Cockpit и который позволяет нам управлять ВМ libvirt в веб консоли Cockpit. Итак, после того, как мы кликнем по VMs, мы запросто сможем увидеть предварительно установленные ВМ и затем открыть их конфигурации, а также устанавливать новые ВМ при помощи простого мастера, как это проиллюстрировано на снимке экрана ниже:

 

Рисунок 7-15


Веб консоль Cockpit, которую можно применять для развёртывания ВМ

Этот мастер для установки ВМ действительно прост- нам всего лишь требуется установить базовые настройки для своей новой ВМ и мы можем запустить установку следующим образом:

 

Рисунок 7-16


Установка ВМ KVM из веб консоли Cockpit

Теперь, когда мы рассмотрели как мы можем устанавливать ВМ локально, то есть мы имеем в виду что без какого бы то ни было вида приложения централизованного управления, давайте вернёмся обратно и проверим как мы можем устанавливать ВМ через oVirt.

Создание новой ВМ при помощи oVirt

Когда мы добавили некий хост в oVirt при регистрации в нём, мы можем проследовать в Compute-VMs и начать развёртывание ВМ применяя некий простой мастер. Поэтому, после клика по кнопке New в этом меню, мы можем делать в точности это, и мы получим такой экран:

 

Рисунок 7-17


Мастер новой ВМ в oVirt

Имея в виду, что oVirt это некое решение централизованного управления для хостов KVM, нам приходится загружать дополнительные параметры по сравнению с установкой локальной ВМ в неком хосте KVM - мы можем выбрать некий кластер, который будет размещать эту ВМ; мы можем применять шаблон, настраивать оптимизацию и тип экземпляра, настраивать Высокую доступность (HA, high availability), выделение ресурсов, параметры запуска..., в целом, это то, что мы в шутку называем вариантом паралитика, хотя всё это для нашего удобства, поскольку централизованные решения всегда будут слегка отличаться от вида локального решения.

Как минимум, нам придётся настроить общие свойства ВМ - название, операционную систему, и сетевой интерфейс ВМ. Затем мы можем проследовать в закладку System, в которой мы настроим размер памяти и число виртуальных ЦПУ, что проиллюстрировано на следующем снимке экрана:

 

Рисунок 7-18


Выбор конфигурации ВМ: виртуальные ЦПУ и память

Несомненно мы пожелаем настроить варианты запуска - подключить CD/ ISO, добавить виртуальный жёсткий диск, а также настроить порядок запуска, как это иллюстрируется следующим снимком экрана:

 

Рисунок 7-19


Настройка вариантов запуска в oVirt

Мы можем персонализировать свои действия после установки ВМпри помощи sysprep или cloud-init, что мы будем обсуждать в Главе 9, Персонализация ВМ при помощи cloud-init.

Вот как выглядит базовая конфигурация в oVirt:

 

Рисунок 7-20


Установка ВМ KVM в oVirt: убедитесь что вы выбрали верные варианты запуска

На практике, когда вы управляете некой средой с более чем двумя или тремя хостами KVM, вы захотите для управления ими воспользоваться неким видом централизованной утилиты. oVirt действительно хороша для этого, поэтому не упускайте её.

Теперь, когда мы выполнили всю процедуру развёртывания во всём разнообразии различных способов, пришло время задуматься о настройке ВМ. Имейте в виду, что ВМ это некий объект, который обладает многими важными атрибутами - такими как значение числа виртуальных ЦПУ, объём памяти, виртуальные сетевые карты и тому подобное - очень важно чтобы вы изучили как персонализировать такие настройки ВМ. Итак, давайте выберем это нашей следующей темой.

Настройка вашей ВМ

Когда мы пользуемся virt-manager, если вы прошли все шаги вплоть до самого последнего, существует интересная возможность, которую вы могли бы выбрать, и это вариант Customize confguration before install . К тому же самому окну настроек мы можем получать доступ когда вы проверяете конфигурацию ВМ после установки. Итак, каким бы способом вы не добрались сюда, вы столкнётесь с самым полным масштабом вариантов настроек для всех аппаратных устройств ВМ, которые были выделены только что созданной нами ВМ, что можно видеть на снимке экрана, приводимом ниже:

 

Рисунок 7-21


Параметры настройки ВМ

Например, если вы щёлкнете по варианту CPUs со стороны левой руки, вы обнаружите значение числа доступных ЦПУ (текущее и максимально выделяемое), а также вы обнаружите некоторые приятные возможности, такие как CPU topology (Sockets/Cores/Treads), что позволяет нам настраивать особенные варианты настройки NUMA (non-uniform memory access, неоднородного доступа к памяти). Вот как выглядит такое окно настроек:

 

Рисунок 7-22


Настройка ЦПУ ВМ

Именно это является очень важной частью настройки ВМ, в особенности когда вы проектируете некую среду, в которой хосты загружают виртуальные серверы. Более того, это становится ещё более важным когда виртуальные серверы размещают приложения с интенсивными операциями ввода/ вывода (I/O), такими как базы данных. Если вы желаете узнать больше об этом, вы можете проверить ссылки в конце данной главы в разделе Дальнейшее чтение, поскольку они снабдят вас загрузкой дополнительных сведений относительно проектирования ВМ.

Далее, если мы откроем вариант Memory, мы можем изменить выделение памяти и снова в плавающей терминологии (текущее и максимальное выделение). Мы обсудим слегка подробнее эти варианты когда мы начнём работать с командами virt-*. Вот как выглядит вариант настроек Memory virt-manager:

 

Рисунок 7-23


Настройка памяти ВМ

Один из наиболее важных вариантов настроек, доступный в virt-manager расположен в подменю Boot Options, которое отображено на следующем снимке экрана:

 

Рисунок 7-24


Настройка параметров запуска ВМ

Здесь вы можете сделать два следующих очень важных момента:

  • Выбрать эту ВМ как автоматически запускаемую в этом хосте

  • Разрешить меню запуска и выбрать устройство запуска и приоритеты устройств запуска

Что касается вариантов конфигурации, то, несомненно, наиболее богатым функционалом меню конфигураций для virt-manager выступает меню виртуального хранилища - в нашем случае, VirtIO Disk 1. Когда мы кликнем по нему, мы намерены получить такой выбор вариантов конфигурации;

 

Рисунок 7-25


Настройка жёсткого диска и параметров контроллера хранения ВМ

Давайте рассмотрим что означают некоторые из этих вариантов конфигурации, а именно:

  • Disk bus - Здесь обычно имеется пять вариантов, причём значением по умолчанию выступает VirtIO (и он наилучший). В точности как и в случае Vmware, ESXi, а также Hyper-V, KVM, имеются доступными различные виртуальные контроллеры хранения. Например, VMware обладает BusLogic, LSI Logic, Paravirtual и прочими типами виртуальных контроллеров хранения, в то время как Hyper-V имеет контроллеры integrated drive electronics (IDE) и small computer system interface (SCSI). Данный параметр определяет тот контроллер хранения, который эта ВМ намерена наблюдать внутри своей гостевой операционной системы.

  • Storage format - имеются два формата: qcow2 и raw (формат типа dd). Наиболее распространённым вариантом выступает qcow2, так как он представляет наиболее гибкое управление для ВМ - например, он поддерживает динамичное выделение и моментальные снимки.

  • Режим Cache - Имеется шесть типов: writethrough, writeback, directsync, unsafe, none и default. Эти режимы поясняют как данные записываются из операций ввода/ вывода, которые возникают из этой ВМ в лежащее у её основе хранилище. Например, при использовании writethrough, весь ввод/ вывод кэшируется в самом хосте ВМ и также записывается и на диск этой ВМ. С другой стороны, когда мы пользуемся none, в её хосте не происходит кэширование (за исключением кэширования writeback самого диска), а данные записываются напрямую в диск этой ВМ. Различные режимы обладают различными за и против, но, как правило, наилучшим вариантом для управления ВМ выступает none. Вы можете получить дополнительные сведения об этом в разделе Дальнейшее чтение.

  • Режим IO - Существуют два режима: native и threads. В зависимости от этих настроек ввод/ вывод ВМ будет записываться либо через асинхронный ввод/ вывод ядра, или же через пул потоков в пространстве пользователя (что также выступает в качестве установки по умолчанию). При работе с форматом qcow2, обычно считается что режим threads лучше, ибо формат qcow2 сначала выделяет секторы, а затем производит в них запись, что бкдет пожирать выделенные этой ВМ vGPU и обладает прямым воздействием на производительность ввода/ вывода.

  • Режим Discard - Здесь имеются два возможных режима, с названиями ignore и unmap. Если вы выберете unmap, когда вы удаляете файлы из своей ВМ (что транслируется в свободное пространство в вашем файле qcow2 диска ВМ), соответствующий файл диска ВМ qcow2 будет усекаться чтобы отражать вновь высвобожденную ёмкость. В зависимости от того какие именно дистрибутив Linux, ядро и исправления ядра вы применили и от версии используемого Quick Emulator (QEMU), эта функция может быть доступной только с шиной диса SCSI. Он поддерживается для версии QEMU 4.0+.

  • Detect zeroes - Доступными имеются три режима: off, on и unmap. Когда вы выбираете unmap, запись нулей будет транслироваться как создающая отсутствие операции (как это было разъяснено в режиме Discard). Если установка выполнена в on, нулевые операции записи операционной системы будут транслироваться в особые команды нулевой записи.

На протяжении жизни каждой определённой ВМ имеется значительная вероятность того, что вы будете её перенастраивать. Будет ли это означать добавление или удаление виртуального оборудования (естественно, как правило, это добавление), это будет важной стороной для жизненного цикла ВМ. А потому давайте изучим как справляться с этим.

Добавление и удаление оборудования в вашей ВМ

Применяя свой экран настроек ВМ мы запросто можем добавлять дополнительное оборудование или также удалять аппаратные средства. Например, если мы кликнем по кнопке Add Hardware в нижнем левом углу, мы легко можем добавить устройство - скажем, виртуальную сетевую карту. Приводимый ниже снимок экрана иллюстрирует этот процесс:

 

Рисунок 7-26


После клика по Add Hardware мы можем выбрать мы можем выбрать какое устройство виртуального оборудования мы желаем добавить в вашу ВМ

С другой стороны,, если мы выберем некое виртуальное аппаратное устройство (допустим, Sound ich6) и нажмём на кнопку Remove, которая появляется вслед за этим, мы также можем и удалить это виртуальное аппаратное устройство, после подтверждения того, что мы желаем это осуществить, как это показано на следующем снимке экрана:

 

Рисунок 7-27


Процесс для удаления оборудования ВМ: выберите его с левой стороны и кликните Remove

Как вы можете наблюдать, добавление и удаление оборудования ВМ просто как раз- два- три. Мы вы действительности изучили эту тему ранее, когда мы работали с виртуальными сетевыми средами и хранилищами (Главе 4, Сетевая среда libvirt), однако там мы применяли команды оболочки и определения файлов XML. Вернитесь к тем примерам, если вы желаете их вспомнить.

Виртуализация - это гибкость, а возможность размещать ВМ в любом приданном хосте в нашей среде - это гигантская часть этого. Имея это в виду, миграция ВМ это одна из функциональных возможностей виртуализации, которая может применяться в качестве рекламного плаката для виртуализации и её многочисленных преимуществ. Что представляет собой миграция ВМ? Именно с этим мы и собираемся разобраться далее.

Миграция ВМ

Проще говоря, миграция позволяет вам перемещать вашу ВМ с одной физической машины на другую физическую машину, причём с очень малым временем простоя или без него вовсе. Мы также способны перемещать хранилище ВМ, что является ресурсо- прожорливой операцией, которая требует аккуратного планирования и - когда это возможно - выполнять во вне рабочее время с тем, чтобы он не оказывала воздействия на производительность прочих ВМ настолько сильно, насколько она способна..

Существуют различные типы миграции и они таковы:

  • Ofine (в отключённом состоянии - по- холодному)

  • Online (в рабочем состоянии - по- живому)

  • Миграция с приостановкой

Также имеются различные типы миграции в рабочем состоянии, в зависимости от того, что именно вы перемещаете, а именно:

  • Вычислительную часть ВМ (перемещение ВМ с одного хоста KVM на другой хост KVM)

  • Хранимую часть ВМ (перемещение файлов ВМ из одного пула хранения в другой пул хранения)

  • И то, и другое (перемещение ВМ с хоста хост, а также из пула хранения в пул хранения одновременно)

Существуют некоторые отличия в плане того какие сценарии миграции поддерживаются когда вы применяете просто обычные хосты в противоположность oVirt или Red Hat Enterprise Virtualization. Если вы желете выполнять миграцию работающего хранилища, вы не можете выполнять это в хосте KVM напрямую, но вы запросто можете сделать это когда такая ВМ остановлена. Если вам требуется миграция хранилища в реальном масштабе времени, вам придётся воспользоваться oVirt или Red Hat Enterprise Virtualization.

Мы также обсуждали single-root input-output virtualization (SR-IOV) Peripheral Component Interconnect (PCI), проброс устройства , virtual graphics processing units (vGPUs) и подобные им понятия (в Главе 2, KVM в качестве решения виртуализации и в Главе 4, Сетевая среда libvirt). В CentOS 8 вы не имеете возможности выполнять миграцию ВМ в реальном масштабе времени, когда любой из этих вариантов присутствует в запущенной ВМ.

Каким бы ни был вариант применения, нам требуется помнить, что миграцию необходимо выполнять либо от имени пользователя root, либо в качестве относящегося к группе libvirt пользователя (что Red Hat именует как системный, а не пользовательский сеанс libvirt).

Имеются различные причины, по которым миграция ВМ выступает ценным инструментом для обладания им в вашем арсенале. Некоторые из этих причин очевидны; другие менее. Давайте попробуем пояснить различные варианты использования миграции ВМ и их преимущества.

Преимущества миграции ВМ

Перечислим наиболее важные преимущества миграции ВМ в реальном времени:

  • Увеличение рабочего времени и снижение времени простоя - Аккуратно спланированная среда виртуализации предоставит вам максимальное время работы для вашего приложения.

  • Энергосбережение и следование зелёным трендам - Вы запросто можете консолидировать свои ВМ на основе их нагрузки и применять меньшее число гипервизоров на протяжении часов с меньшей нагрузкой. Раз ваши ВМ мигрируют, вы можете отключать свои не используемые гипервизоры.

  • Простой процесс обновления оборудования/ программных средств при перемещении ваших ВМ между различными гипервизорами - Раз у вас имеется возможность свободно перемещать свои ВМ между различными физическими серверами, такие преимущества бессчётны.

Миграция Вм требует надлежащего планирования. Существуют некоторые базовые требования, которым надлежит следовать при миграции. Давайте рассмотрим их по одному.

Требования миграции для промышленных сред таковы:

  • Подлежащие миграции ВМ обязаны применять пул хранения, который создан в неком совместно используемом хранилище.

  • Значение имён самого пула хранения и пути к виртуальному диску обязаны оставаться теми же самыми в обоих гипервизорах (гипервизорах источника и назначения).

Чтобы освежить свои сведения о том как создавать пул хранения и применять разделяемое хранилище, обратитесь к Главе 4, Сетевая среда libvirt и Главе 5, Хранилище libvirt.

Как и всегда, имеются некоторые применимые здесь правила. Они достаточно просты, а потому нам требуется узнать их прежде чем мы начнём процессы миграции. Они таковы:

  • Имеет ся возможность осуществлять миграцию в реальном масштабе времени при помощи пула хранения, который создан в не разделяемом хранилище. Вам только требуется поддерживать те же самое название пула хранения и местоположение файла, но всё же рекомендуется в промышленных средах применять совместно используемое хранилище.

  • Когда имеется некий неуправляемый виртуальный диск, подключённый к ВМ, которая пользуется Fiber Channel (FC), Internet Small Computer Systems Interface (iSCSI), Logical Volume Manager (LVM) и тому подобным, в обоих гипервизорах обязано быть доступным одно и то же хранилище.

  • Используемые подлежащей миграции ВМ виртуальные сетевые среды должны быть доступными в обоих гипервизорах.

  • Мост, который настроен для сетевого взаимодействия должен быть доступным в обоих гипервизорах.

  • Миграция может закончиться отказом если основные версии libvirt и qemu-kvm в гипервизорах отличаются, однако вы должны быть способны без проблем мигрировать те ВМ, которые обладают более низкой версией libvirt или qemu-kvm в гипервизор, который имеет более высокие версии этих пакетов.

  • Значение времени и в гипервизоре источника и в гипервизоре получателя обязаны быть синхронными. Настоятельно рекомендуется тобы вы выполняли синхронизацию своих гипервизоров при помощи тех же самых серверов Network Time Protocol (NTP) или Precision Time Protocol (PTP).

  • Важно что эти системы используют сервер Domain Name System (DNS) для разрешения имён. Добавление подробностей об имеющихся хостах в /etc/hosts не работает. Вы должны быть способны разрешать свои имена хостов при помощи команды host.

Существуют некоторые предварительные требования, которыми нам надлежит иметь в виду при планировании своей среды для миграции ВМ. По большей части эти предварительные требования в основном те же самые для всех решений виртуализации. Давайте далее обсудим эти предварительные требования и, в целом, как настраивать свою среду для миграции ВМ.

Настройка необходимой среды

Давайте соберём необходимую среду для выполнения миграции ВМ - как миграцию в отключённом состоянии, так и миграцию в реальном режиме времени. Следующая схема рисует два стандартных хоста виртуализации KVM, запускающих ВМ ч некого совместного хранилища:

 

Рисунок 7-28


ВМ в разделяемом хранилище

Мы начнём это с настройки совместного хранилища. В данном примере мы применяем для своего совместного хранилища Network File System (NFS). Мы намерены применять NFS по причине её простоты в настройке, что посодействует вам более простому следованию примерам миграции. В реальном промышленном применении рекомендуется использовать пулы хранения на основе iSCSI или FC. NFS не лучший выбор когда ваши файлы велики, а ваши ВМ выполняют интенсивные операции ввода/ вывода. Gluster является хорошей альтернативой NFS и мы бы рекомендовали вам испробовать его. Gluster хорошо интегрирован в libvirt.

Мы собираемся создать совместный ресурс NFS в сервере CentOS 8. Её мы намерены разместить в каталоге /testvms, который мы намерены экспортировать через NFS. Название этого сервера nfs-01 (IP адресом nfs-01 выступает 192.168.159.134).

  1. Самый первый шаг состоит в создании и экспорте каталога /testvms из nfs-01 и настройки SELinux (проверьте в разделе Ceph как это сделать).

    
# mkdir /testvms
# echo '/testvms *(rw,sync,no_root_squash)' >> /etc/exports

  2. Далее разрешите исполнение своей службе NFS в межсетевом экране следующим образом:

    
# firewall-cmd --get-active-zones
public
interfaces: ens33
# firewall-cmd --zone=public --add-service=nfs
# firewall-cmd --zone=public --list-all

  3. Запустите службу NFS так:

    
# systemctl start rpcbind nfs-server
# systemctl enable rpcbind nfs-server
# showmount -e

  4. Убедитесь что ваш совместный ресурс доступен из обоих гипервизоров KVM. В нашем случае это PacktPhy01 и PacktPhy02. Выполните следующий код:

    
# mount 192.168.159.134:/testvms /mnt

  5. В случае отказа в монтировании, перенастройте настройки межсетевого экрана в своём сервере NFS и повторите проверку этого монтирования. Это можно выполнить при помощи таких команд:

    
firewall-cmd --permanent --zone=public --add-service=nfs
firewall-cmd --permanent --zone=public --add-service=mountd
firewall-cmd --permanent --zone=public --add-service=rpc-bind
firewall-cmd -- reload

  6. После того, как вы проверили точку монтирования в обоих гипервизорах, размонтируйте этот том следующим образом:

    
# umount /mnt

  7. В PacktPhy01 и PacktPhy02 создайте пул хранения с названием testvms:

    
# mkdir -p /var/lib/libvirt/images/testvms/
# virsh pool-define-as --name testvms --type netfs
--source-host 192.168.159.134 --source-path /testvms
--target /var/lib/libvirt/images/testvms/
# virsh pool-start testvms
# virsh pool-autostart testvms

Пул хранения testvms теперь создан и запущен в обоих гипервизорах.

В своём следующем примере мы намерены изолировать собственно миграцию и обмен ВМ. Настоятельно рекомендуется чтобы вы осуществили такую изоляцию в своей промышленной среде, в особенности когда вы выполняете большое число миграций, поскольку это разгрузит такой требовательный процесс в обособленный сетевой интерфейс, тем самым освобождая прочие перегруженные сетевые интерфейсы. Итак имеются две основные причины для этого, а именно:

  • Производительность сетевой среды: Сама миграция ВМ использует всю полосу пропускания сетевой среды целиком. Когла вы применяете ту же самую сетевую среду для сетевого обмена ВМ и собственно сетевой миграции, такая миграция задушит эту сетевую среду, тем самым воздействуя на способность служб своих ВМ. Вы можете контролировать значение полосы пропускания миграции, однако это увеличит величину времени миграции.

    Во как мы создаём такую изоляцию:

    
PacktPhy01 -- ens36 (192.168.0.5) <--switch------gt; ens36
(192.168.0.6) -- PacktPhy02
    ens37 -gt; br1 <-----switch------gt; ens37 -> br1

    Интерфейсы ens192 в PacktPhy01 и PacktPhy02 используются для миграции, а также для задач администрирования. Они обладают назначенными IP и подключением к некому сетевому коммутатору. Мост br1 создан при помощи ens224 и в PacktPhy01, и в PacktPhy02. br1 не обладает неким выделенным ему IP и применяется исключительно для обмена ВМ (восходящая ссылка для того коммутатора, к которому подключены сами ВМ). Он также подключён к (физическому) сетевому коммутатору.

  • Причины безопасности: Всегда рекомендуется чтобы вы удерживали своё управление сетевой средой и виртуальной сетью изолированными также и по причинам безопасности. Вы не пожелаете чтобы ваши пользователи путались в вашей сети управления, в которой вы выполняете доступ к своим гипервизорам и осуществляете администрирование.

Мы обсудим три из наиболее важных сценариев - миграцию в отключённом режиме, миграцию без реального времени (с приостановкой), а также миграцию в реальном масштабе времени. Затем мы обсудим миграцию хранилища как отдельный сценарий, который требует дополнительные планирование и продуманность.

Миграция в отключённом состоянии

Как и подразумевает её название, в процессе миграции в отключённом состоянии значением состояния такой ВМ будет либо полный останов, или приостановка. Эта ВМ затем возобновляется или запускается в назначенном ей хосте. При данной модели миграции libvirt буде просто копировать файл настроек XML этой ВМ с хоста KVM источника в хост получателя. Это также предполагает, что вы также обладаете одним и тем же совместным пулом хранения созданным и готовым для применения в получателе. В качестве самого первого шага в этом процессе миграции вам потребуется настроить двухстороннюю аутентификацию SSH в гипервизорах KVM участников. В нашем примере они имеют названия PacktPhy01, и в PacktPhy02.

Для нашего следующего упражнения временно отключите Security-Enhanced Linux (SELinux).

В /etc/sysconfig/selinux для изменения следующей строки воспользуйтесь предпочитаемым вами редактором:


SELINUX=enforcing

Её требуется изменить следующим образом:


SELINUX=permissive

Кроме того, в своей командной строке от имени root нам требуется на время установить режим SELinux в разрешительный следующим образом:


# setenforce 0

В PacktPhy01 от имени root исполните следующую команду:


# ssh-keygen
# ssh-copy-id root@PacktPhy02

В PacktPhy02 от имени root исполните следующую команду:


# ssh-keygen
# ssh-copy-id root@PacktPhy01

Теперь вы будете способны зарегистрироваться в обоих этих гипервизорах в качестве root без ввода пароля.

Давайте выполним миграцию MasteringKVM01 в отключённом состоянии, которая уже установлена с PacktPhy01 в PacktPhy02. Общий формат команды миграции выглядит аналогично следующему:


# virsh migrate migration-type options name-of-the-vm-destination-uri

В PacktPhy01 выполните такой код:


[PacktPhy01] # virsh migrate --offline --verbose –-persistent MasteringKVM01 qemu+ssh://PacktPhy02/system
Migration: [100 %]

В PacktPhy02 запустите следующий код:


[PacktPhy02] # virsh list --all
# virsh list --all
Id Name State
----------------------------------------------------
- MasteringKVM01 shut off
[PacktPhy02] # virsh start MasteringKVM01
Domain MasteringKVM01 started

Когда ВМ располагается в совместном хранилище, а вы обладаете некой проблемой в одном из своих хостов, вы можете также вручную зарегистрировать ВМ в другом хосте. Это означает, что вы могли бы закончить с положением, при котором одна и та же ВМ зарегистрирована в двух гипервизорах, после чего вы можете устранить ту проблему, которую вы испытываете в своём хосте с первоначальной проблемой. Это то, что происходит когда вы вручную управляете KVM без централизованной платформы управления, такой как oVirt, которая не допускает подобного сценария. Итак, что произойдёт если вы окажетесь в подобной ситуации Давайте обсудим такой сценарий.

Что если я случайно запущу свою ВМ в обоих гипервизорах?

Случайный запуск вашей ВМ в обоих гипервизорах может превратиться в ночной кошмар системного администратора. Это может повлечь к разрушения файловой системы ВМ, в особенности когда эта Вм не осведомлена о кластере. Разработчики libvirt подумали об этом и пришли к механизму блокировки. В действительности, они предложили два механизма блокировок. Когда они включены, они препятствуют одновременному запуску ВМ в двух гипервизорах.

Эти два механизма блокировки таковы:

  • lockd: lockd пользуется рекомендательной способностью блокировки POSIX fcntl(). Она запускается демоном virtlockd. Он требует некой совместно используемой файловоё системы (предпочтительно NFS), доступной всем тем хостам, которые совместно применяют один и тот же пул хранения.

  • sanlock: Он применяется проектами oVirt. Это использует алгоритм paxos для сопровождения непрерывно обновляемых овладений.

Для реализаций только с libvirt мы предпочитаем lockd над sanlock. Для oVirt лучше применять sanlock.

Включение lockd

Для пулов хранения на основе образа, которые совместимы с POSIX, вы можете разрешить lockd просто сняв комментарий со следующей команды в /etc/libvirt/qemu.conf или в обоих гипервизорах:


lock_manager = "lockd"

Теперь включите и запустите в обоих своих гипервизорах службу lockd. Также перезапустите в обоих своих гипервизорах libvirtd следующим образом:


# systemctl enable virtlockd; systemctl start virtlockd
# systemctl restart libvirtd
# systemctl status virtlockd

Запустите MasteringKVM01 в PacktPhy02 как показано ниже:


[root@PacktPhy02] # virsh start MasteringKVM01
Domain MasteringKVM01 started

Запустите ту же самую MasteringKVM01 в PacktPhy01 следующим образом:


[root@PacktPhy01] # virsh start MasteringKVM01
error: Failed to start domain MasteringKVM01
error: resource busy: Lockspace resource '/var/lib/libvirt/
images/ testvms/MasteringKVM01.qcow2' is locked

Другой метод включения lockd состоит в использовании некого хэша в пути файла своего диска. Блокировки сохраняются в неком совместном каталоге, который экспортируется через NFS или аналогичный совместный ресурс, в свои гипервизоры. Это очень полезно когда вы обладаете виртуальными дисками, которые создаются и подключаются при помощи logical unit number (LUN) со множеством путей. При таких ситуациях fcntl() не может применяться. Для включения такой блокировки мы рекомендуем чтобы вы применяли те методы, которые мы подробнее поясним далее.

В своём сервере NFS исполните приводимый ниже код (вначале убедитесь что вы не запустили ни одну из ВМ с этого сервера NFS!):


# mkdir /flockd
# echo "/flockd *(rw,no_root_squash)" >> /etc/exports
# systemctl restart nfs-server
# showmount -e
Export list for :
/flockd *
/testvms *

В /etc/fstab для обоих гипервизоров добавьте следующий код и наберите остальные эти команды:


# echo "192.168.159.134:/flockd /var/lib/libvirt/lockd/flockd nfs rsize=8192,wsize=8192,timeo=14,intr,sync" >> /etc/fstab
# mkdir -p /var/lib/libvirt/lockd/flockd
# mount -a
# echo 'file_lockspace_dir = "/var/lib/libvirt/lockd/flockd"' >> /etc/libvirt/qemu-lockd.conf

Перезапустите оба гипервизора и, по окончанию их перезапуска, убедитесь что демоны libvirtd и virtlockd правильно запущены в обоих гипервизорах следующим образом:


[root@PacktPhy01 ~]# virsh start MasteringKVM01
Domain MasteringKVM01 started
[root@PacktPhy02 flockd]# ls
36b8377a5b0cc272a5b4e50929623191c027543c4facb1c6f3c35bacaa7455ef
51e3ed692fdf92ad54c6f234f742bb00d4787912a8a674fb5550b1b826343dd6

MasteringKVM01 обладает двумя виртуальными дисками, один создан из пула хранения NFS, а другой создан непосредственно из некого LUN. Если вы попробуете его включить в своём хосте гипервизора PacktPhy02, MasteringKVM01 откажется запускаться, что можно обнаружить из следующего фрагмента кодв:


root@PacktPhy02 ~]# virsh start MasteringKVM01
error: Failed to start domain MasteringKVM01
error: resource busy: Lockspace resource
'51e3ed692fdf92ad54c6f234f742bb00d4787912a8a674fb5550b1b826343dd6' is locked

При использовании томов LVM, которые могут видеться во множестве систем хостов, вместо их путей желательно осуществлять блокировку на основе соответствующего universally unique identifer (UUID), ассоциируемого с каждым томом. Настройка следующего пути заставит libvirt осуществить для LVM блокировку на основе UUID:


lvm_lockspace_dir = "/var/lib/libvirt/lockd/lvmvolumes"

Когда вы применяете тома SCSI, которые могут видеться во множестве систем хостов, вместо таких путей желательно выполнять блокировку на основании значения UUID, ассоциируемого с каждым томом. Установка приводимого ниже пути заставит libvirt выполнить блокировку на основе UUID для SCSI:


scsi_lockspace_dir = "/var/lib/libvirt/lockd/scsivolumes"

Как и для file_lockspace_dir, значения предыдущих каталогов также надлежит применять совместно в используемых гипервизорах.

[Замечание]Замечание

Если вы не способны запустить ВМ по причине ошибок блокирования, просто убедитесь что они не запущены где- то ещё и затем удалите такие блокирующие файлы. Запустите эту ВМ снова. Мы слегка отклонились от темы миграции для lockd. Даватй вернёмся обратно к миграции.

Миграция в реальном времени или во включённом состоянии

При этом типе миграции соответствующая ВМ мигрирует в установленный хост получателя в то время как она исполняется на своём хосте источника. Это процесс невидим её пользователям, который работают применяя такие ВМ. Они даже и не представляют что используемые ими ВМ переносятся на другой хост в то время как они работают с ними. Миграция в реальном масштабе времени это одна из основных функциональных возможностей, которая делает виртуализацию столь популярной.

Реализация миграции в KVM не требует никакой поддержки от самой ВМ. Это означает, что вы можете в реальном масштабе времени выполнять миграцию любой ВМ, причём независимо от той операционной системы, которую они применяют. Уникальной функциональной особенностью миграцией в реальном времени KVM является то, что она практически полностью аппаратно независима. В идеале вы будете иметь возможность выполнять миграцию в реальном масштабе времени некой ВМ, исполняемой в гипервизоре, который обладает процессором Advanced Micro Devices (AMD) в гипервизор на основе Intel.

Мы не говорим, что это будет работать в 100% случаев, или что мы как- то рекомендуем применять такой вид смешанных сред, однако в большинстве случаев это должно выполняться.

Прежде чем мы запустим этот процесс, давайте слегка глубже разберёмся в том, что происходит под капотом. Когда мы осуществляем миграцию в реальном масштабе времени, мы перемещаем запущенную ВМ в то время как к ней осуществляют доступ пользователи. Это означает, что пользователи не ощущают никакого нарушения в доступности ВМ при выполнении миграции вживую.

Миграция в реальном масштабе времени это сложный процесс из пяти этапов, сложный, даже несмотря на то что никакие из этих процессов не выставляются своим системным администраторам. После того как активирована миграция такой ВМ, всю необходимую работу выполняет libvirt. Поясним в приводимом далее перечне те этапы, через которые проходит миграция ВМ:

  1. Подготовка получателя: После того как вы инициируете миграцию в реальном масштабе времени, libvirt (SLibvirt) вашего источника осуществит контакт с libvirt (DLibvirt) своего получателя на предмет подробностей той ВМ, которую мы намерены передавать в реальном времени. DLibvirt передаст эти сведения лежащему в её основе QEMU, причём с надлежащими параметрами для разрешения миграции в реальном масштабе времени. QEMU запустит действительный процесс миграции вживую, стартуя соответствующую ВМ в режиме pause и приступит к отслеживанию по порту Transmission Control Protocol (TCP) данных ВМ. После того как соответствующий получатель готов, DLibvirt уведомит SLibvirt, причём со всеми подробностями относительно QEMU. К этому времени QEMU, в качестве источника, уже готов переместить саму ВМ и подключиться к порту TCP получателя.

  2. Передача самой ВМ: Когда мы говорим о переносе ВМ, мы не передаём всю ВМ целиком; переносятся лишь те части, которые пропущены в её получателе - например, собственно память и значения состояний виртуальных устройств (состояние ВМ). Всё прочее помимо собственно памяти и значения состояния ВМ, всё иное виртуальное оборудование (виртуальная сеть, виртуальные диски и виртуальные устройства) доступны в самом получателе. Вот как QEMU перемещает собственно память в своего получателя:

    1. Сама ВМ продолжает исполняться в своём источнике, а та же самая ВМ запускается в своём получателе в режиме pause.

    2. За один проход передаётся вся используемая этой ВМ память своему получателю. Значение скорости обмена зависит от полосы пропускания сетевой среды. Допустим, ваша ВМ занимает 10 gibibytes (GiB); это потребует того же самого времени, что и передача 10 GiB данных при помощи протокола ] Secure Copy Protocol (SCP) своему получателю. Именно по этой причине мы отделяем свою сетевую среду администрирования от сетевой среды обмена ВМ.

    3. После того, как вся память находится в своём получателе, QEMU запускает обмен своими недействительными страницами (dirty pages, страницами, которые ещё пока не записаны на её диск). Когда эта ВМ занятая, значение числа недействительных страниц будет высоким и потребуется время для их перемещения. Помните, недействительные страницы присутствуют всегда, и не существует состояния с нулевым числом недействительных страниц в исполняющейся ВМ. Следовательно, QEMU прекратит передачу своих недействительных страниц когда он достигнет нижнего порога (50 или менее страниц).

      QEMU также рассмотрит прочие факторы, такие как итерации, общее число выработанных недействительных страниц и тому подобное. Это также может быть определено в migrate-setmaxdowntime, которое задаётся в миллисекундах.

  3. Останов этой ВИ в её хосте источника: После того как значение недействительных страниц достигнет оговоренного порогового значения, QEMU остановит эту ВМ в своём хосте источника. Он также выполнит синхронизацию своих виртуальных дисков.

  4. Передача состояния ВМ: На этом этапе QEMU передаст значение состояния виртуальных устройств этой ВМ и оставшихся недействительных страниц своему получателю так ьыстро, как это только возможно. На данном этапе мы не имеем возможности ограничивать значение полосы пропускания.

  5. Возобновление этой ВМ: В своём получателе эта ВМ будет продолжена из своего состояния паузы. Виртуальные network interface controllers (NICs) становятся активными, а соответствующий мост будет по своей инициативе рассылать Address Resolution Protocols (ARPs) для объявления о происшедших изменениях. После получения таких объявлений от соответствующего моста, задействованные сетевые коммутаторы обновят свои соответствующие кэши ARP и начнут отправлять все данные в ту ВМ, которая находится в своём новом гипервизоре.

Обратите внимание, что шаги 3,4 и 5 будут выполнены за миллисекунды. При возникновении каких бы то ни было ошибок QEMU прервёт данную миграцию и эта ВМ продолжит своё исполнение в гипервизоре источника. На протяжении всего этого процесса миграции службы libvirt обоих участвующих гипервизоров будут отслеживать этот процесс миграции.

Наша ВМ с названием MasteringKVM01 в данный момент безопасно запущена в PacktPhy01, причём lockd включён. Мы же намерены осуществить миграцию MasteringKVM01 в реальном масштабе времени в PacktPhy02.

Нам надлежит открыть все необходимые порты, применяемые для миграции. Вам потребуется выполнить это только на стороне получателя, но хорошим практическим приёмом будет выполнить это раз за разом во всей вашей среде с тем, чтобы вам не приходилось выполнять такое микро управление когда оно потребуется в будущем. В целом, вам придётся открыть эти порты в всех участвующих гипервизорах при помощи идущих следом команд firewall-cmd для установленной по умолчанию зоны (в нашем случае это зона public):


# firewall-cmd --zone=public --add-port=49152-49216/tcp --permanent

Провеим разрешимость имён в обоих своих серверах следующим образом:


root@PacktPhy01 ~] # host PacktPhy01
PacktPhy01 has address 192.168.159.136
[root@PacktPhy01 ~] # host PacktPhy02
PacktPhy02 has address 192.168.159.135
[root@PacktPhy02 ~] # host PacktPhy01
PacktPhy01 has address 192.168.159.136
[root@PacktPhy02 ~] # host PacktPhy02
PacktPhy02 has address 192.168.159.135

Проверьте и убедитесь что все необходимые подключённые виртуальные диски доступны в вашем получателе, причём по тому же самому пути и с тем же самым названием пула хранения. Это применимо также и для подключённых неуправляемых (iSCSI и FC LUN, а также тому подобного) виртуальных дисков.

Проверьте и убедитесь что все необходимые сетевые мосты и виртуальные сетевые среды, применяемые этой ВМ, доступны в вашем получателе. После этого мы можем запустить сам процесс миграции, выполним следующий код:


# virsh migrate --live MasteringKVM01 qemu+ssh://PacktPhy02/system --verbose --persistent
Migration: [100 %]

Наша ВМ пользуется лишь 4 096 megabytes (MB) памяти, а потому все пять этапов выполнены за пару секунд. Параметр --persistent не является обязательным, но мы рекомендуем добавлять его.

Вот вывод ping на протяжении нашего процесса миграции (10.10.48.24 это значение IP адреса MasteringKVM01):


# ping 10.10.48.24
PING 10.10.48.24 (10.10.48.24) 56(84) bytes of data.
64 bytes from 10.10.48.24: icmp_seq=12 ttl=64 time=0.338 ms
64 bytes from 10.10.48.24: icmp_seq=13 ttl=64 time=3.10 ms
64 bytes from 10.10.48.24: icmp_seq=14 ttl=64 time=0.574 ms
64 bytes from 10.10.48.24: icmp_seq=15 ttl=64 time=2.73 ms
64 bytes from 10.10.48.24: icmp_seq=16 ttl=64 time=0.612 ms
--- 10.10.48.24 ping statistics ---
17 packets transmitted, 17 received, 0% packet loss, time
16003ms
rtt min/avg/max/mdev = 0.338/0.828/3.101/0.777 ms

Если вы получите приводимое ниже сообщение об ошибке, измените в своём подключённом виртуальном диске cache в none:


# virsh migrate --live MasteringKVM01 qemu+ssh://PacktPhy02/system --verbose
error: Unsafe migration: Migration may lead to data corruption if disks use cache != none
# virt-xml MasteringKVM01 --edit --disk target=vda,cache=none

target это значение диска для изменения значения кэширования. Вы можете обнаружить это имя цели выполнив такую команду:


virsh dumpxml MasteringKVM01

Вы можете испробовать несколько дополнительных параметров при выполнении миграции в реальном масштабе времени, а именно:

  • --undefine domain: Параметр применяется для удаления домена KVM из хоста KVM.

  • --suspend domain: Приостанавливает домен, а именно, ставит на паузу домен KVM до тех пор, пока мы не выведем его из этого состояния.

  • --compressed: При выполнении миграции ВМ этот параметр позволяет нам сжимать память. Это подразумевает более быстрый процесс миграции на основании значения параметра –comp-methods.

  • --abort-on-error: Кога процесс миграции сталкивается с некой ошибкой, он автоматически останавливается. Именно этот безопасный параметр установлен по умолчанию, ибо он помогает в тех ситуациях, когда на протяжении вашего процесса миграции может произойти любой вид разрушений.

  • --unsafe: Некий вид по другую сторону от параметра --abort-on-error. Это параметр принуждает выполнение миграции при любой её стоимости, даже в случае ошибок, разрушений данных или прочего непредвиденного сценария. Будьте особенно внимательны с этим параметром - не пользуйтесь им часто или в тех случаях, когда ключевым предварительным требованием вы желаете иметь на 100% уверенность в состоятельности данных ВМ.

Относительно этих параметров вы можете получить дополнительные сведения в RHEL 7—Virtualization Deployment and Administration guide (вы обнаружите ссылку на него в разделе Дальнейшее чтение в конце этой главы). Кроме того, наша команда virsh поддерживает также следующие параметры:

  • virsh migrate-setmaxdowntime <domain>: При миграции некой ВМ, временами неизбежно что ВМ становится недоступной на короткий промежуток времени. Это может происходить - к примеру - по причине процесса потери связи, когда мы выполняем миграцию ВМ с одного хоста на другой и мы просто приходим в некий момент равновесного состояния (то есть когда и хост источника, и хост получателя обладают одним и тем же содержимым ВМ готовы удалить такую ВМ источника из описи хоста своего источника и запустить её в своём хосте получателя). В целом, небольшая пауза происходит потому что наша ВМ источника ставится на паузу и уничтожается, а ВМ её хоста получателя снимается с паузы и возобновляется. Применяя данную команду имеющийся стек KVM пытается оценить насколько долго длилась такая стадия останова. Это жизнеобеспечивающий параметр, в особенности для тех ВМ, которые действительно заняты и тем самым происходит много изменений их состояния памяти пока мы выполняем их миграцию.

  • virsh migrate-setspeed <domain> bandwidth;: Мы можем рассматривать его как почти Quality of Service (QoS) параметр. Воспользовавшись им, мы имеем возможность установить объём полосы пропускания в MiB/s, который мы предоставляем своему процессу миграции. Это очень хороший параметр когда наша сетевая среда занята (например, у нас имеется множество virtual local area networks (VLANs), работающих в той же самой физической сетевой среде и по этой причине мы имеем ограничения в полосе пропускания). Численное уменьшение замедляет сам процесс миграции.

  • virsh migrate-getspeed <domain>: Мы можем рассматривать это как параметр сбора сведений косманды migrate-setspeed, чтобы проверить какие настройки мы назначили для команды virsh migrate-setspeed.

Как вы можете видеть, миграция это сложный процесс с технической точки зрения и он обладает множеством различных типов и загрузок различных дополнительных параметров настроек, которые вы можете применять для целей управления. Как уже было сказано, это всё ещё настолько важная возможность виртуальной среды, что очень трудно представить работу без неё.

Выводы

В этой главе мы рассмотрели различные способы создания ВМ и настройки оборудования ВМ. Мы также подробно осветили миграцию ВМ, причём выполняя миграцию как в реальном времени, так и в отключённом состоянии. В этих понятия очень важно разобраться, поскольку они сделают вашу жизнь администрирования виртуальной среды намного более простой.

Вопросы

  1. Какие инструменты командной строки мы можем применять для развёртывания ВМ в libvirt?

  2. Какие инструменты графического интерфейса мы можем применять для развёртывания ВМ в

  3. При настройке наших ВМ с какими сторонами настройки следует быть аккуратными?

  4. В чём разница между миграцией в ВМ реальном времени и в откючённом состоянии?

  5. В чём разница между миграцией ВМ и миграцией хранилища ВМ?

  6. Как мы можем настраивать полосу пропускания для своего процесса миграции?

Дальнейшее чтение

Для получения дополнительных сведений относящихся к рассмотренному нами в этой главе воспользуйтесь, пожалуйста, следующими ссылками:

Управление ВМ при помощи virt-manager

oVirt - устнаовка ВМ Linux

Выбор ВМ

Миграция ВМ

Кэширование

Влияние NUMA и расположения памяти на производительность Microsof SQL Server 2019

Руководство по развёртыванию и администрированию виртуализации