Глава 5. Виртуальные машины KVM

Как и подразумевает их название, KVM добавляют возможности гипервизора в ядро Linux. KVM позволяют вам создавать полностью изолированные виртуальные машины, которые не зависят от ядра хоста. Изолированность создаётся путём эмуляции определённых элементов оборудования, таких как ЦПУ, ОЗУ, звуковые/ видео/ сетевые карты, мосты PCI, а также устройства ввода клавиатура/ мышь. Так как KVM не зависит от ядра хоста, она способна виртуализировать широкий диапазон операционных систем, таких как Linux, BSD, Windows, OS X и тому подобные. Одно из основных отличий KVM и виртуальных машин на основе контейнеров заключается в том, что выделяемые для RVM ресурсы изолируются друг от друга, а также от хоста.

Таким образом, плотность числа ВМ KVM на узле намного меньше чем у контейнеров. KVM являются единственным выбором для не- Linux операционных систем и для ориентированных на выполнение определённой задачи операционных систем, таких как ClearOS, FreeNAS, Zentyal и тому подобные. Для получения дополнительной информации по KVM обратитесь к https://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine {Прим. пер.: или к русскоязычной странице https://ru.wikipedia.org/wiki/KVM.}

В Proxmox мы можем создавать ВМ KVM следующими двумя путями:

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

 

Закладка General

Закладка General блока диалога используется в основном для назначения идентификационной информации, такой как:

 

Закладка OS

Закладка OS используется для выбора определённого типа гостевой операционной системы которая будет установлена на создаваемую ВМ. Такой выбор типа позволяет вашей ВМ быть осведомлённой о предполагаемой к установке операционной системе и отрегулировать архитектуру на основе выбранной ОС. В нашем примере ВМ, мы выбрали Linux 4.X/3.X/2.6 Kernel, как это показано на следующем экранном снимке:

 

Закладка CD/DVD

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

Если мы хотим создать свою ВМ без определения какого- либо образа диска, нам понадобится выбрать опцию Do not use any media.

 

Закладка Hard Disk

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

 

Bus/Device

Для данного параметра представлены два ниспадающих меню: одно для выбора типа шины образа диска, а второе для выбора идентификатора устройства.

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

 

Storage

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

 

Disk size

Это текстовый блок для определения размера вашего дискового хранилища в ГБ. Значение может быть только численным. Мы также можем применять стрелки вверх и вниз для определения данного размера.

 

Format

Это ниспадающее меню для выбора типа образа диска. Если мы выбираем хранилище, которое поддерживает только определённые типы дисков, то эти опции меню будут окрашены серым. Например, если мы выбираем хранилище Ceph RBD, то данная опция будет скрыта серым (как показано на следующем рисунке), так как RBD поддерживает только формат .raw.

Если мы выберем не верный формат образа своего диска, или если мы позже решим использовать другой формат, мы можем просто воспользоваться параметром Move disk в закладке Hardware для изменения формата. Это также можно сделать в CLI применив следующую команду:

#qemu-img convert –O <type> <source_image> <destination_image>
 	   

Если мы хотим преобразовать образ диска .qcow2 в образ .raw, команда должна иметь следующий вид:

#qemu-img convert –O raw vm-101-disk-1.qcow2 vm-101-disk-1.raw
 	   

Эта команда хорошо работает для локальных хранилищ, а также для хранилищ NFS, ZFS и Gluster, однако не применима к RBD. Для изменения формата образа диска. хранимого в RBD используйте параметр Move в инструментальной панели Proxmox. Относительно хранимого в RBD образа диска, этот параметр Move может быть применён для перемещения любого образа диска сохранённого в любом хранилище при помощи GUI совсем без какой бы то ни было необходимости применения CLI. Этот параметр также полезен при перемещении образа диска с одного хранилища на другое без выключения данной ВМ. Хранилище может быть любым от локального до совместно используемого и наоборот. Для перемещения или изменения определённого формата диска выберите конкретный образ диска в закладке Hardware и кликните на Move disk для открытия блока диалога, как это показано на следующем рисунке:

Как показано на предыдущем рисунке для нашего примера ВМ, мы перемещаем образ диска в хранилище NFS, одновременно преобразовывая в .qcow2 образ из образа .raw. Если мы выберем параметр Delete source, также автоматически будет удалён файл источника после окончания преобразования или перемещения. Если эта опция не разрешена, тогда мы должны будем вручную удалять файл источника. Файл источника отображается как неиспользуемый образ диска в закладке Hardware данной ВМ.

 

Cache

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

 

No backup

Если данная опция включена, образ данного виртуального диска никогда не будет включаться в резервную копию. По умолчанию эта опция запрещена.

 

Discard

Образ диска в Proxmox разряжён в зависимости от типа образа. Это означает, что образ определённого диска медленно растёт по мере сохранения в нём данных. Со временем данные создаются и удаляются в пределах файловой системы данного образа диска. Однако при разряженном образе диска даже после удаления данных он никогда не восстанавливает свободное пространство. ВМ может сообщать верное доступное пространство, однако хранилище Proxmox будет показывать более высокое использование пространства. Опция сброса (discard) позволяет узлу восстановить свободное пространство, которое не используется какими бы то ни было данными. Это эквивалентно опции TRIM, которая была введена в устройствах SSD в точности для тех же целей. Перед тем как эта опция может быть использована, мы должны убедится, что данная ВМ использует контроллер SCSI VISIO. Мы можем установить тип SCSI в закладке Option данной виртуальной машины, как это отображено на следующем рисунке:

По умолчанию Proxmox настраивает все ВМ с контроллером LSI 53C895A. Опция Discard может не соответствовать всем средам, хранилищам и операционным системам. Выполните достаточное тестирование перед её реализацией в своём окружении.

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

 

Iothread

Существует две опции для образов диска KVM:

По умолчанию Proxmox использует ionative для всех образов диска, в то время как опция iothread помечается специальным образом для нуждающихся в ней образах дисков.

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

 

Закладка CPU

Данная закладка делает возможной настройку вами необходимых виртуальных WGE для создаваемой виртуальной машины. Следующий рисунок отображает блок диалога с доступными опциями ЦПУ:

 

Sockets

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

 

Cores

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

 

Enabling NUMA

NUMA (Non Uniform Memory Access, доступ к неоднородной памяти) не является новым подходом к обработке памяти в окружениях со множеством ЦПУ, хотя это и является новым добавлением в Proxmox VE. Обычно при использовании NUMA, оперативная память может быть полностью распределена по ЦПУ, что увеличивает производительность, поскольку более не существует узких мест обусловленных тем, что все ЦПУ пытаются осуществлять доступ к одной и той же группу блоков памяти. В Proxmox опция NUMA также делает возможным подключение оперативной памяти и ЦПУ в горячем режиме. Без данной опции подключение в горячем режиме ЦПУ и оперативной памяти не работает вовсе.

Любой узел с более чем одним разъёмом ЦПУ обычно осведомлён о NUMA. Поэтому включение NUMA для ВМ на таком узле предоставит преимущество производительности создаваемой ВМ. NUMA всегда будет пытаться оставлять такую ВМ на одном и том же пакете ЦПУ. Мы можем проверить состояние NUMA в кластере Proxmox воспользовавшись командой:

# numastat
 	   

Эта команда отобразит все ваши узлы в кластере, которые осведомлены о NUMA, а также их стсатистики производительности.

 

Type

Это ниспадающее списочное меню для выбора типа пакета ЦПУ. По умолчанию для всех ВМ выбирается тип ЦПУ kvm64.

 

Закладка Memory

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

В Proxmox мы можем устанавливать для ВМ фиксированную или динамично выделяемую оперативную память. Автоматический диапазон также называется надуванием памяти (memory ballooning). При фиксированных опциях вся память выделяется в одно и то же время. При опциях динамичного выделения оперативная память выделяется на основании запросов ВМ в пределах предварительно установленного диапазона. Автоматическое выделение памяти хорошо работает для гостевых ВМ на основе Linux, однако для ВМ Windows надувание памяти потребляет более высокие значения ресурсов ЦПУ, вызывающие замедление такой ВМ. Поэтому для ВМ Windows лучше применять фиксированную память, где это возможно.

 

Закладка Network

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

 

Bridged mode

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

 

Firewall

Чтобы включить Межсетевой экран Proxmox для данного сетевого интерфейса, необходимо отметить эту опцию. без этого параметра никакие правила межсетевого экрана не будут применяться к данному интерфейсу. Мы рассмотрим Межсетевой экран Proxmox максимально подробно в Главе 8, Межсетевой экран Proxmox.

 

NAT mode

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

 

No network device

Эта опция создаёт вашу ВМ без какого бы то ни было настроенного сетевого интерфейса.

 

Model

Это ниспадающее меню служит для выбора типа виртуального сетевого интерфейса. Для максимальной производительности сетевой среды настоятельно рекомендуется применять VIRTIO. Windows не поставляется с драйвером VIRTIO, поэтому если данный интерфейс применяется для ВМ Windows, мы должны вручную загрузить этот драйвер из ISO, который мы скачали в разделе закладки Hard Disk данной главы. Для ВМ Windows мы также можем применять Intel E1000. Начиная с Windows 7 этот драйвер Intel входит в комплект поставки.

 

MAC address

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

 

Rate limit

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

 

Multiqueues

Обычно ВМ KVM имеют единственную очередь в которую попадают отправляемые и получаемые сообщения по одному за раз без какой- либо одновременности. Множественные очереди удаляют это узкое место делая возможными одновременные отсылку и приём путём усиления от виртуальных ядер ЦПУ для параллельных очередей. Множественные очереди в особенности полезны для ВМ, которые проявляют активность для большого числа клиентов, например, для веб- серверов. В закладке Proxmox Network для блока диалога создания ВМ мы можем ввести численное значение для определения числа параллельных очередей, которое должна использовать данная ВМ. Это значение не должно быть больше чем число выделенных данной ВМ vCPU. Например, если данная ВМ имеет 4 виртуальных ядра, мы можем установит значение для множественных очередей равное 4. Множественность очередей серьёзно увеличивает производительность сетевой среды ВМ, так как и отправка, и приём могут осуществляться одновременно.

 

Disconnect

Если данная опция включена, виртуальный сетевой интерфейс будет создан для данной ВМ, однако не будет активирован.

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

В данном примере мы собираемся преобразовать одну из созданных в предыдущем разделе своих ВМ в шаблон. Чтобы преобразовать ВМ в шаблон нам необходимо кликнуть правой кнопкой для открытия меню контекста на данной ВМ, как это отображено на следующем снимке экрана и кликнуть на Convert to template.

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

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

Функции блоков ввода Target node, VM ID, Name и Resource Pool идентичны закладке General блока диалога создания ВМ KVM.

 

Режим

В Proxmox существует два режима клонирования:

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

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

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

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

Чтобы конвертировать ВМ в шаблон, кликните правой кнопкой по ВМ для открытия её меню контекста, а затем выберите Convert to Template, как это показано на следующем рисунке:

Чтобы создать новый клон, кликните правой кнопкой мыши по шаблону, а затем выберите Clone для открытия блока диалога создания клона шаблона, как это показано на следующем снимке экрана:

Параметры в окне диалога идентичны параметрам процесса создания ВМ, клонируемой без какого- либо шаблона.

Теперь мы рассмотрим некоторые расширенные опции настройки, которые мы можем использовать для расширения возможностей виртуальных машин KVM.

В данном разделе мы собираемся рассмотреть как добавлять поддержку звука в ВМ. По умолчанию Proxmox не добавляет аудио оборудование к ВМ. Чтобы операционная система ВМ могла запустить звуковую службу, в файл настройки такой ВМ должны быть добавлены некотороые аргументы при помощи CLI. В Proxmox VE 4.1 нет возможности добавлять звуковой интерфейс через его GUI. Последующие шаги добавят в ВМ звуковое устройство:

В Proxmox присутствует возможность проброса (passthrough) устройств PCI напрямую в ВМ. В данном разделе мы собираемся рассмотреть как настроить и осуществить проверку проброса PCI. Для включения и настройки проброса PCI в Proxmox необходимо выполнить следующие шаги:

В данном разделе мы собираемся рассмотреть как настроить видеоадаптер на применение напрямую в ВМ. Поддержка устройств PCI Express, таких как карты видео адаптеров, была добавлена в Proxmox начиная с версии 3.3. Для включения подобного проброса узел Proxmox должен иметь ядро PVE 3.10. Если вы используете Proxmox VE 4.1, вы, скорее всего, имеете самое последнее ядро. Мы можем добавить PXI Express и выполнить проброс GPU в ВМ из CLI путём добавления параметров в файл настройки ВМ.

Следующие шаги покажут как включать стандартные не-GPU PCI Express устройства, устройства нп основе GPU, а также устройства GPU со встроенными аудио- устройствами в ВМ:

В данном разделе мы собираемся рассмотреть как настраивать подключаемые во время работы опции в виртуальных машинах Proxmox. Применяя функцию подключения во время работы, мы можем добавлять и удалять устройства или ресурсы в ВМ без перезапуска или цикла включения данной ВМ. В Proxmox VE 4.1 мы можем применять опции подключения во время работы (hotplug) для следующих ресурсов:

S Proxmox 4.1 мы можем только увеличивать ЦПУ и оперативную память, но не можем уменьшать их. И диски, и сетевые интерфейсы могут в равной степени подключаться и отключаться во время работы. Следующая таблица отображает какие типы устройств поддерживаются в различных операционных системах:

Устройство	Ядро	Подключаемые/ отключаtvst во время работы	ОС
Disk	Все	Оба	Все версии Linux/ Windows
NIC	Все	Оба	Все версии Linux/ Windows
CPU	>3.10	Для Windows только подключение. Для Linux оба.	Все версии Linux. Windows Server 2008 и выше.
Memory	>3.10	Для Windows только подключение. Для Linux оба.	Все версии Linux. Windows Server 2008 и выше.

В то время как главная настройка разрешения подключения во время работы для Proxmox должна быть выполнена через CLI, мы можем включать отдельные подключаемые во время работы устройства при помощи меню с закладками Proxmox GUI | Option, как это показано на следующем рисунке:

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

# modprobe acpiphp
# modprobe pci_hotplug
 	   

Для загрузки этих модулей в процессе загрузки автоматически мы можем добавить их в /etc/modules.

Нам также нужно создать новый файл правил udev в файле /lib/udev/rules.d/80-hotplugcpu-mem.rules и добавить новые строки:

SUBSYSTEM=="cpu",ACTION=="add",TEST=="online",ATTR{online}=="0", ATTR=={online}="1"
SUBSYSTEM=="memory",ACTION=="add",TEST=="state", ATTR{state}=="offline",ATTR=={state}="online"
 	   

Для активации модулей и правил данный узел Proxmox должен выполнить цикл включения.

Для разрешения подключения во время работы для ВМ в GUI необходимо выполнить следующие шаги:

Чтобы добавить новый ресурс в ВМ, перейдите в закладку Hardware и кликните на Add. В Proxmox VE 4.1 мы можем добавлять только образ Hard Disk, Network Device и CD/DVD Drive при помощи кнопки Hardware | Add, как это показано на следующем изображении:

Чтобы добавить в ВМ vCPU или удалить его из неё, выберите Processor в закладке VM | Hardware и кликните Edit для открытия блока диалога ЦПУ. Мы также можем добавить vCPU выполним следующую команду в CLI узла Proxmox:

# qm set <vm_id> -vcpus 2
 	   

Предыдущая команда добавит в общей сложности два виртуальных ЦПУ к данной ВМ.

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

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

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

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

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

Можно создать виртуальный кластер Proxmoх используя гипервизор Proxmox поверх существующего кластера Proxmox. Из- за падения производительности при встроенном гипервизоре, варианты применения встроенных кластеров очень ограничены. Он может применяться в следующих случаях, не ограничиваясь, тем не менее этими сценариями:

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

Чтобы иметь производительность близкую к естественной для гипервизора, виртуальные машины должны иметь доступ к некоторому оборудованию, которое ускоряет виртуализацию. Такая функциональность называется аппаратно поддерживаемым расширением виртуализации (Hardware Assisted Virtualization Extension). Для получения подробной информации по аппаратной поддержке виртуализации посетите следующую ссылку: https://en.wikipedia.org/wiki/Hardware-assisted_virtualization. {Прим. пер.: также см. ru.wikipedia.org/wiki/Аппаратная_виртуализация.}

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

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

Следующие шаги отображают процесс включения функции встраиваемости в узле Proxmox и его настройку:

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

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

Виртуальная машина KVM является наилучшим практическим способом применения не- Linux операционных систем, а также при обязательной полной изоляции ресурсов между машинами.

В следующей главе мы собираемся в мельчайших подробностях рассмотреть контейнеры LXC. Мы изучим зачем администратор Proxmox должен их выбирать вместо виртуальных машин KVM.

{Прим. пер.: следите за ссылкой Виртуализация KVM, Полное руководство по которой в скором времени (мы надеемся) появится перевод новой книги Mastering KVM Virtualisation, вышедшей в августе 2016.}