Используем KVM для создания виртуальных машин на сервере. Работа с виртуальными машинами KVM

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

Почему ? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.

Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.

Мы же, повторюсь, решили использовать Debian Squeeze с набором пакетов из Sid/Experimental и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
В планах имеется публикация репозитория с пакетами.

При выборе технологии виртуализации рассматривались два варианта - Xen и KVM.

Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen - тем интереснее было провести в жизнь решение именно на базе KVM.

Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.

Для управления виртуальными машинами оказалось чрезвычайно удобно использовать и продукты, использующие ее API: virsh , virt-manager , virt-install , пр.

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

Разумеется, решение не идеально. Из минусов следует назвать:

• Абсолютно невменяемые сообщения об ошибках.
• Невозможность изменять часть конфигурации виртуальной машины на лету, хотя QMP (QEMU Monitor Protocol) это вполне позволяет.
• Иногда к libvirtd по непонятной причине невозможно подключиться - он перестаёт реагировать на внешние события.

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

В KVM ничего такого не было до появления механизма распределения ресурсов ядра . Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup , в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.

Профит в том, что всё это реализуется внутри ядра, и использовать это можно не только для сервера, но и для десктопа (что и использовали в известном «The ~200 Line Linux Kernel Patch That Does Wonders »). И на мой взгляд, это одно из самых значительных изменений в ветке 2.6, не считая любимого #12309 , а не запиливание очередной файловой системы. Ну, разве что, кроме POHMELFS (но чисто из-за названия).

Отношение к этой библиотеке-утилите у меня весьма неоднозначное.

С одной стороны это выглядит примерно так:

И ещё эту штуку чертовски сложно собрать из исходников и тем более в пакет: иногда мне кажется, что Linux From Scratch собрать с нуля несколько проще.

С другой стороны - очень мощная штука, которая позволяет создавать образы для виртуальных машин, модифицировать их, ужимать, ставить grub, модифицировать таблицу разделов, управлять конфигурационными файлами, переносить «железные» машины в виртуальную среду, переносить виртуальные машины с одного образа на другой, переносить виртуальные машины из образа на железо и, честно говоря, тут меня фантазия немного подводит. Ах, да: ещё можно запустить демон внутри виртуальной машины Linux и получить доступ к данным виртуальной машины вживую, и всё это делать на shell, python, perl, java, ocaml. Это краткий и далеко не полный список того, что можно сделать с .

Интересно, что большая часть кода в генерируется в момент сборки, равно как и документация к проекту. Очень широко используется ocaml, perl. Сам код пишется на C, который потом оборачивается в OCaml, и повторяющиеся куски кода генерируются сами. Работа с образами осуществляется путём запуска специального сервисного образа (supermin appliance), в который через канал внутрь него отправляются команды. Внутри этого образа содержится некоторый rescue набор утилит, таких как parted, mkfs и прочих полезных в хозяйстве системного администратора.

Я с недавнего времени его даже дома стал использовать, когда выковыривал из образа nandroid нужные мне данные. Но для этого требуется ядро с поддержкой yaffs.

Прочее

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

Сегодня сложно представить мир без компьютеризированных устройств. Лет этак 20 назад почти все бытовые приборы были электро-механические, об использовании компьютерных схем повсеместно не было даже и речи. Самые первые компьютеры занимали значительные объемы пространства, и могли относительно не много. Компьютерно-вычислительные комплексы за последнее время прошли достаточно большой путь развития. Хотя, принципиально компьютеры ничем не изменились, но вычислительные мощности стремительно возросли. Наличие компьютера в простой семье теперь не является чем-то особенным.

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

По своей сути, все ОС это в общем-то и так некоторая виртуальная среда, которая предоставляется разработчику ПО, как средство реализации конечных задач. Уже давно прошло то время, когда программы писались конкретно под аппаратную часть компьютера по средствам аппаратных кодов и запросов. Сегодня же, любое приложение – это в первую очередь приложение, написанное на некотором API, который находится под управлением ОС. Задачи же ОС – предоставить данным API непосредственно доступ к аппаратным ресурсам.

Собственно видов виртуализации существует несколько:

• Программная виртуализация;
• Аппаратная виртуализация;
• Виртуализация уровня операционной системы.

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

Программная виртуализация – вид виртуализации, который задействует различные библиотеки ОС, транслируя вызовы виртуальной машины в вызовы ОС. (DOSBox, Virtualbox, VirtualPC)

Аппаратная виртуализация – такой вид, который предусматривает специализированную инструкцию аппаратной части, а конкретно инструкций процессора. Позволяет исполнять запросы в обход гостевой ОС, и исполнять прямо на аппаратном обеспечении. (виртуализация KVM,виртуализация XEN, Parallels, VMware, Virtualbox)

Виртуализация уровня операционной системы – виртуализация только части платформы, без полной виртуализации аппаратной части. Подразумевает работы нескольких экземпляров среды ОС. (Docker, LXC)

Данная статья будет рассматривать Аппаратную виртуализацию, а конкретно виртуализацию KVM.

Схема 1. – Взаимодействие компонентов виртуальной машины с аппаратной частью

Особенности виртуализации для ядра Linux

Для исполнения прямых аппаратных запросов в ОС должна иметься библиотека, которая направляла бы эти запросы аппаратной части напрямую. На платформах базы Linux долгое время никакой встроенной системы виртуализации (встроенного гипервизора), просто не существовало. Каждый производитель ПО для виртуализации, который поддерживало технологию аппаратной виртуализации, вынуждены были создавать собственные модули для ядра Linux (vboxdrv в Virtualbox, vmware-service в VMWare и пр.) Естественно, это не могло продолжаться вечно, и компания Qumranet, Inc, выкупленая затем Radhat создала ассоциацию Open Virtualization Alliance, которая была признана решить проблему отсутствия базового гипервизора для ядра Linux. Так и был создан гипервизор KVM или Kernel-based Virtual Machine.

Реализация

Гипервизор KVM представляет из себя загружаемый модуль ядра Linux, который предназначен для обеспечения виртуализации на платформе Linux x86. Сам модуль содержит компонент собственно виртуализации(kvm.ko), и процессорно-специфический загружаемый модуль kvm-amd.ko либо kvm-intel.ko.

Необходимым условием для использования KVM является поддержка инструкций виртуализации - Intel VT либо AMD , и ядро Linux версии 2.6.20 и выше. Существует также порт KVM под Free-BSD. Для вызова KVM традиционно используется QEMU, но также ведутся попытки добавить поддержку KVM в Virtualbox.

Сам по себе KVM не выполняет эмуляции. Вместо этого программа, работающая в пространстве пользователя, использует интерфейс /dev/kvm для настройки адресного пространства гостя виртуальной машины, через него же эмулирует устройства ввода-вывода и видеоадаптер.

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

Использование

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

Для наглядности рассматривается виртуализация KVM на базе библиотеку virt-manager.

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

Схема 2. – Взаимодействие компонентов libvirt

QEMU позволяет создать фрейм для вызова гипервизора на клиентской системе. Данная программа настраивается аргументами вызова командной строки, является достаточно легкой и простой.

Существуют кроме того несколько графических оболочек, таких как Gnome-Boxes .

Вывод

Виртуализация – неотъемлемая часть современных корпоративных систем, она позволяет сэкономить колоссальные денежные и энергетические ресурсы. Развитие технологий виртуализации является приоритетным направлением многих организаций. Развиваются такие технологии как как VGAPassthrough (технология "проброса" видеокарты хост-устройства в виртуальную машину) и PCIPassthrough ("проброс" PCI устройства).

Гипервизоры (технологии виртуализации) существуют более 30 лет и за это время сумели стать одним из главных «винтиков» в составе облачной экосистемы. Многие компании, подбирающие решения для виртуализации, останавливают свой выбор на двух популярных гипервизорах - VMware и KVM. Предлагаем разобраться какой же из них лучше. Но для начала немного теории.

Что такое гипервизор?

Гипервизор - это программа, отделяющая операционную систему от железа. Гипервизоры виртуализируют ресурсы сервера (процессор, память, диск, сетевые интерфейсы и др.), позволяя использовать их как свои собственные, и создают на основе одного сервера несколько отдельных виртуальных машин. Каждая созданная виртуальная машина изолируется от соседей, чтобы не влиять на работу других. Для работы гипервизора необходима поддержка виртуализации: для процессоров Intel на процессоре Intel VT, а для процессоров AMD на AMD-V.

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

Гипервизоры второго типа, также известные как размещенные гипервизоры (Hosted Hypervisor), работают с операционной системой, установленной на сервере. А операционные системы для новых пользователей создаются поверх гипервизора.

Настольные гипервизоры, такие как Oracle VirtualBox или VMware Workstation, являются гипервизорами второго типа, а VMware и KVM – первого. VMware и KVM устанавливаются непосредственно на сервер и не требуют установки какой-либо операционной системы.

VMware vSphere

Перед покупкой VMware vSphere можно попробовать поработать в пробной версии (60 дней), после чего необходимо покупать лицензию, либо мириться с ограничениями бесплатной версии.

В бесплатной версии, которая называется VMware Free vSphere Hypervisor, нет ограничений для хоста по процессорам и памяти, зато есть ряд других:

• API продукта доступно только для чтения;
• виртуальная машина не может иметь более 8 ядер;
• ее нельзя использовать вместе с Veeam для создания резервных копий;
• подключение к vCenter Server не поддерживается;
• не поддерживается и высокая доступность, а также технологии VM Host Live Migration и VM Storage Live Migration.

Продукт от VMware отличается от аналогов поддержкой большого количества операционных систем - Windows, Linux, Solaris, FreeBSD, Netware, MacOS и других.

Установка дистрибутива VMware на сервер очень проста: достаточно загрузиться с CD, флешки или через PXE. К тому же поддерживаются сценарии, позволяющие автоматизировать процесс инсталляции программного обеспечения, настройку сети и подключения к vCenter Server.

Немаловажно и наличие специального конвертера VMware vCenter Converter , позволяющего использовать в ESXi образы MS Virtual Server, Virtual PC, Hyper-V, а также физические серверы и образы дисковых разделов, созданных такими программами как Acronis True Image, Norton Ghost и другими.

У VMware vSphere есть встроенная интеграция с Microsoft Active Directory, то есть аутентификацию пользователей в частном или гибридном облаке можно производить при помощи доменных служб Microsoft. Гибкое распределение ресурсов позволяет использовать горячее добавление CPU, ОЗУ и жесткого диска (в том числе изменять размер текущего жесткого диска без перезагрузки).

VMware Fault Tolerate - технология VMware, предназначенная для защиты виртуальных машин с помощью кластеров непрерывной доступности. При отказе хоста (сервера ESXi) с основной (Primary) рабочей копией виртуальной машины, защищенная виртуальная машина мгновенно переключится на «вторичную» (Secondary) или «теневую» копию, работающую на другом сервере ESXi. Для машин, защищенных VMware Fault Tolerance, происходит постоянное (в реальном времени) копирование всего состояния памяти и процессорных инструкций с основной копии на «теневую». При сбое основного хоста ESXi, пользователи даже не заметят процесса переключения на второй узел. Именно этим Fault Tolerance отличается от High Availability. В High Availability при отказе физического сервера виртуальные машины будут перезапущены на других узлах, и пока операционные системы перезагружаются пользователи не смогут получить доступ к виртуальным серверам.

Кроме VMware Foult Tolerate, лицензия VMware vCloud Suite Enterprise обеспечивает высокую доступность, отказоустойчивость и восстановление после аварий с помощью функций vSphere HA, vMotion, Storage vMotion, и vCenter Site Recovery Manager.

Для уменьшения плановых остановок в обслуживании серверов или систем хранения данных (СХД), функции vMotion и Storage vMotion в онлайн-режиме переносят виртуальные машины и их диски без остановки работы приложений и пользователей. Функция vSphere Replication поддерживает разные варианты репликации vCenter Site Recovery Manager (SRM) для защиты от крупных аварий. SRM обеспечивает централизованное планирование послеаварийного восстановления, автоматические Failover и Failback с резервного сайта или из облака vCloud, а также тестирование послеаварийного восстановления без прерывания работы приложений.

К особенностям этого гипервизора стоит отнести избирательность к железу - перед установкой необходимо тщательно проверить имеющееся оборудование на совместимость с нужной версией ESXi. Для этого на сайте VMware есть специальная .

Лицензирование продуктов VMware имеет свои особенности. Дополнительную путаницу добавляют периодические изменения (от версии к версии vSphere) в лицензионной политике VMware. Существует несколько пунктов, которые нужно учесть перед приобретением лицензий VMware vSpere:

• лицензирование гипервизора выполняется по числу физических процессоров (CPU). Каждый CPU сервера требует отдельной лицензии vSphere (ядра не являются физическими процессорами и не учитываются в лицензировании);
• доступный функционал сервера ESXi определяется установленной на нем лицензией vSphere. Подробное руководство по лицензиям есть на ;
• для каждой купленной лицензии vShpere необходимо приобретать пакет сервисной поддержки (минимум на год);
• VMware не накладывает ограничения на количество памяти (RAM), установленной на сервере, и на количество запущенных виртуальных машин.

Управлять множеством хостов с гипервизорами ESXi, СХД и сетевым оборудованием можно с помощью еще одного продукта VMware - Vcenter Server. Подключаемые модули клиента vSphere, предоставляемые партнерами VMware, дают IT-администраторам возможность управлять сторонними элементами в дата-центре непосредственно из этой консоли. Поэтому пользователи vCenter могут выполнять резервное копирование, защищать данные, управлять серверами, сетями и безопасностью непосредственно из интерфейса vCenter. В этой же консоли можно настроить триггеры, которые оповестят о возникших проблемах, и получить данные о работе всей инфраструктуры в виде графиков или таблиц.

KVM

KVM - простой в использовании, легкий, нетребовательный к ресурсам и довольно функциональный гипервизор. Он позволяет за минимальные сроки развернуть площадку виртуализации и организовать виртуализацию под управлением операционной системы Linux. В процессе работы KMV осуществляет доступ к ядру операционной системы через специальный модуль (KVM-Intel или KVM-AMD). Изначально KVM поддерживал только процессоры x86, но современные версии KVM поддерживают самые разные процессоры и гостевые операционные системы, в том числе Linux, BSD, Solaris, Windows и др. Кстати, все Wiki-ресурсы (MediaWiki, Wikimedia Foundation, Wikipedia, Wikivoyage, Wikidata, Wikiversity) используют именно этот гипервизор.

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

KVM позволяет виртуальным машинам использовать немодифицированные образы дисков QEMU, VMware и другие образы, содержащие операционные системы. Каждая виртуальная машина имеет своё собственное виртуальное аппаратное обеспечение: сетевые карты, диск, видеокарту и другое железо.

Благодаря поддержке немодифицированных образов VMware, физический сервер можно легко виртуализовать при помощи все той же утилиты VMware vServer Converter, а затем перенести полученный файл в гипервизор.

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

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сетевым интерфейсам отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС.

Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту Virsh, реализующую все необходимые функции. Для удобного управления виртуальными машинами можно дополнительно установить пакет Virt-Manager.

У KVM нет встроенных инструментов, подобных Fault Tolerate для VMware, поэтому единственный способ создать кластер высокой доступности - использовать сетевую репликацию при помощи DRDB. Кластер DRBD поддерживает только два узла, а узлы синхронизируются без шифрования. То есть для более безопасной связи необходимо использовать VPN-соединение.

Кроме того, для построения кластера высокой доступности понадобится программа Heartbeat, которая позволяет обмениваться служебными сообщениями о своем состоянии узлам в кластере, и Pacemaker - менеджер ресурсов кластера.

Гипервизор KVM распространяется как продукт с открытым исходным кодом, а для корпоративных пользователей существует коммерческое решение Red Hat Virtualization (RHEL), основанное на KVM и платформе управления виртуальной инфраструктурой oVirt.

Несомненным преимуществом этого гипервизора является то, что он способен работать на любом сервере. Гипервизор довольно неприхотлив к ресурсам, что позволяет с легкостью использовать его для задач тестирования.

Следует учесть, что у KVM нет службы поддержки. Если что-то не получится, можно рассчитывать на форумы и помощь сообщества. Или перейти на RHEL.

Так что же выбрать?

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

KVM обычно более масштабируем, чем VMware, в первую очередь потому что vSphere имеет некоторые ограничения на серверы, которыми он может управлять. Кроме того, VMware добавила большое количество сетей хранения данных (SAN) для поддержки различных поставщиков. Эта функция означает, что VMware имеет больше вариантов хранения, чем KVM, но также усложняет поддержку хранилища VMware при расширении.

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

Исследования показали, что совокупная стоимость владения KVM, как правило, на 39 процентов ниже, чем у VMware, хотя фактическая совокупная стоимость владения зависит от специфичных факторов, таких как эксплуатационные параметры и рабочая нагрузка площадки.

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

Облачные провайдеры, предлагающие своим клиентам услуги по модели IaaS, обычно выбирают инфраструктуру, построенную на продуктах VMware. Решения на основе VMware Sphere содержат все важные корпоративные функции по обеспечению высокой и непрерывной доступности, обеспечивают поддержку большего числа гостевых операционных систем и имеют возможность сопряжения инфраструктуры заказчика с облачными сервисами.

Допустим ты молодой, но всё ещё бедный студент, А значит из всех возможных платформ ты имеешь лишь ПК на Windows и PS4. В один прекрасный день ты решаешься взяться за ум и стать программистом, но мудрые люди в интернете сообщили тебе, что нормальным инженером без Linux не стать. Установить Fedora своей основной и единственной системой ты не можешь, потому что Windows всё ещё нужен для игр и вконтактика, а установить Linux второй системой на жёсткий диск тебе мешает страх или отсутствие опыта.

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

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

А, может, ты и вовсе архитектор, который спроектировал новую сложную систему для обработки бизнес аналитики. В систему твою входят такие вещи, как ElasticSearch, Kafka, Spark и много чего ещё, и каждый компонент должен жить отдельно, настраиваться по уму и общаться с другими компонентами. Как хороший инженер, ты понимаешь, что недостаточно просто установить весь этот зоопарк прямо себе на систему. Нужно попробовать развернуть максимально близкое к будущему production окружение, и желательно так, чтобы твои наработки потом бесшовно заработали на production серверах.

И что же делать во всех этих непростых ситуациях? Правильно: использовать виртуализацию.

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

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

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

Подходы к виртуализации

Независимо от подхода и технологии, при использовании виртуализации всегда существует host-машина и установленный на ней гипервизор, управляющий guest-машинами.

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

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

Существует три способа взаимодействия виртуальных машин с железом:

Динамическая трансляция

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

Паравиртуализация

В случае с паравиртуализацией исходный код гостевой ОС специально изменяется так, чтобы все инструкции выполнялись максимально эффективно и безопасно. При этом виртуалка всегда в курсе, что она - виртуалка. Из плюсов - улучшенная производительность. Из минусов - таким образом нельзя виртуализовать, например, MacOS или Windows, или любой другую ОС, к исходникам которой нет доступа. Паравиртуализация в той или иной форме используется, например, в Xen и KVM.

Аппаратная виртуализация

Разработчики процессоров вовремя осознали, что архитектура x86 плохо подходит для виртуализации, так как изначально была заточена под одну ОС за раз. Поэтому, уже после того как появились динамическая трансляция от VMWare и паравиртуализация от Xen, Intel и AMD начали выпускать процессоры с аппаратной поддержкой виртуализации.

Особого прироста производительности это поначалу не дало,так как главным фокусом первых релизов было улучшение архитектуры процессоров. Однако, теперь, спустя больше 10 лет после появления Intel VT-x и AMD-V, аппаратная виртуализация ничем не уступает и даже в чём-то превосходит другие решения.

Аппаратную виртуализацию использует и требует KVM (Kernel-based Virtual Machine), которую мы и будем использовать в дальнейшем.

Kernel-based Virtual Machine

KVM - это решение для виртуализации, встроенное прямо в ядро Linux, не уступающее остальным решениям в функциональности и превосходящее их в удобстве использования. Более того, KVM - open source технология, которую, тем не менее, на всех парах двигает вперёд (как в плане написания кода, так и в плане маркетинга) и внедряет в свои продукты Red Hat.

Это, кстати, одна из многих причин, почему мы настаиваем на Red Hat дистрибутивах.

Создатели KVM изначально сфокусировались на поддержке аппаратной виртуализации и не стали переизобретать многие вещи. Гипервизор, по сути, это маленькая операционная система, которая должна уметь работать с памятью, с сетью и т.п. Linux уже отлично умеет всё это делать, поэтому использование ядра Linux в качестве гипервизора - логичное и красивое техническое решение. Каждая виртуальная машина KVM -это всего лишь отдельный Linux процесс, безопасность обеспечивается при помощи SELinux/sVirt, ресурсы управляются при помощи CGroups.

Мы ещё поговорим о SELinux и CGroups в другой статье, не пугайся, если не знаешь таких слов.

KVM не просто работает как часть ядра Linux: начиная с версии ядра 2.6.20 KVM является основной составляющей Linux. Иными словами, если у вас стоит Linux, то у вас уже есть KVM. Удобно, правда?

Стоит сказать, что в сфере публичных облачных платформ Xen доминирует чуть больше, чем полностью. Например, AWS EC2 и Rackspace используют именно Xen. Обусловлено это тем, что Xen появился раньше всех и первый достиг достаточного уровня производительности. Но есть и хорошие новости: в ноябре 2017 , который постепенно заменит Xen для крупнейшего облачного провайдера.

Несмотря на то, что KVM использует аппаратную виртуализацию, для некоторых драйверов I/O устройств KVM может использовать паравиртуализацию, что обеспечивает прирост производительности для определённых сценариев использования.

libvirt

Мы уже почти дошли до практической части статьи, осталось только рассмотреть ещё один open source инструмент: libvirt.

libvirt - это набор инструментов, предоставляющий единый API к множеству различных технологий виртуализации. Используя libvirt вам впринципе без разницы, что там за “бакенд”: Xen, KVM, VirtualBox или что-то ещё. Более того, можно использовать libvirt внутри Ruby (а ещё Python, C++ и много чего ещё) программ. Ещё можно удалённо по защищённым каналам подключаться к виртуальным машинам.

Разработкой libvirt, кстати, занимается Red Hat. Ты уже установил себе Fedora Workstation основной системой?

Создадим виртуалку

libvirt - это просто API, а вот как с ним взаимодействовать решать пользователю. Вариантов куча . Мы воспользуемся несколькими стандартными утилитами. Напоминаем: мы настаиваем на использовании Red Hat дистрибутивов (CentOS, Fedora, RHEL) и команды ниже были протестированы именно на одной из этих систем. Для других дистрибутивов Linux возможны небольшие отличия.

Сначала проверим, поддерживается ли аппаратная виртуализация. На самом деле, работать будет и без её поддержки, только гораздо медленнее.

egrep --color = auto "vmx|svm|0xc0f" /proc/cpuinfo # если не выведется ничего, значит поддержки нет:(

Так как KVM то модуль ядра Linux, то нужно проверить, загружен ли он уже, и если нет, то загрузить.

lsmod | grep kvm # kvm, kvm_intel, kvm_amd. Если ничего не выводит, значит, нужно загрузить нужные модули # Если модуль не загружен modprobe kvm modprobe kvm_intel # или modprobe kvm_amd

Возможна ситуация, что аппаратная виртуализация выключена в BIOS. Поэтому если модули kvm_intel/kvm_amd не подгружаются, то проверь настройки BIOS.

Теперь установим необходимые пакеты. Проще всего сделать это, установив сразу группу пакетов:

yum group list "Virtual*"

Список групп зависит от используемой ОС. У меня группа называлась Virtualization . Для управления виртуальными машинами из командой строки используется утилита virsh . Проверь, есть ли у тебя хотя бы одна виртуалка командой virsh list . Скорее всего нет.

Если не нравится командная строка, то ещё есть virt-manager - весьма удобный GUI для виртуалок.

virsh умеет создавать виртуалки только из XML файлов, формат которых можно изучить в документации libvirt . К счастью, ещё есть virt-manager и команда virt-install . С GUI ты и сам разберёшься, а вот пример использования virt-install:

sudo virt-install --name mkdev-vm-0 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --memory = 1024 --vcpus = 1 \ --disk size = 8

Вместо указания размера диска, можно создать его заранее через virt-manager, или через virsh и XML файл. Я использовал выше образ с Centos 7 minimal, который легко найти на сайте Centos .

Теперь остаётся один важный вопрос: как подсоединиться к созданной машине? Проще всего это сделать через virt-manager - достаточно дважды кликнуть по созданной машине и откроется окно с SPICE соединением. Там тебя ждёт экран установки ОС.

Кстати, KVM умеет nested virtualization: виртуалки внутри виртуалку. We need to go deeper!

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

Но где взять такой файл? Не писать же его с нуля? Разумеется, нет: так как мы уже установили внутри нашей виртуалки Centos 7, то нам нужно просто подсоединиться к ней и найти файл /root/anaconda-ks.cfg - это Kickstart конфиг для того, чтобы создать копию уже созданной ОС. Нужно просто скопировать его и отредактировать содержимое.

Но просто скопировать файл скучно, поэтому мы добавим в него ещё кое-что. Дело в том, что по умолчанию у нас не получится подсоединиться к консоли созданной виртуалки из командой строки host-машины. Чтобы сделать это, нужно отредактировать конфиг загрузчика GRUB. Поэтому в самый конец Kickstart файла добавим следующую секцию:

%post --log = /root/grubby.log /sbin/grubby --update-kernel = ALL --args = "console=ttyS0" %end

%post , как не сложно догадаться, выполнится после установки ОС. Команда grubby обновит конфиг GRUB, добавив возможность подключаться к консоли.

Кстати, ещё можно указать возможность подключения через консоль прямо во время создания виртуалки. Для этого в команду virt-install нужно передать ещё один аргумент: --extra-args="console=ttyS0" . После этого можно устанавливать саму ОС в интерактивном текстовом режиме из терминала твоей host машины, подключившись к виртуалке через virsh console сразу после её создания. Это особенно удобно, когда создаёшь виртуалки на железном удалённом сервере.

Теперь можно применить созданный конфиг! virt-install позволяет при создании виртуалки передавать дополнительные аргументы, в том числе путь к Kickstart файлу.

sudo virt-install --name mkdev-vm-1 \ --location ~/Downloads/CentOS-7-x86_64-Minimal-1511.iso \ --initrd-inject /path/to/ks.cfg \ --extra-args ks = file:/ks.cfg \ --memory = 1024 --vcpus = 1 --disk size = 8

После того, как вторая виртуалка будет создана (полностью автоматически), ты сможешь подключиться к ней из командой строки командой virsh console vm_id . vm_id можно узнать из списка всех виртуалок командой virsh list .

Одно из преимуществ использования KVM/libvirt - потрясающая документация, в том числе создаваемая компанией Red Hat . Дорогому читателю предлагается с должной любознательностью изучить её.

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

Что дальше?

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

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

Каким бы мощным и богатым на сервисы не был AWS, его основа - это виртуальные машины поверх Xen. Каждый раз, когда ты создаёшь новый дроплет на DigitalOcean , ты создаёшь виртуалку. Практически все сайты, которыми ты пользуешься, размещены на виртуальных машинах. Простота и гибкость виртуалок позволяет не только строить production-системы, но и в десятки раз облегчает локальную разработку и тестирование, особенно когда в системе задействовано множество компонентов.

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

В Ubuntu рекомендуется использовать гипервизор (менеджер виртуальных машин) KVM и библиотеку libvirt в качестве инструментария управления им. Libvirt включает в себя набор программного API и пользовательских приложений управления виртуальными машинами (ВМ) virt-manager (графический интерфейс, GUI) или virsh (командная строка, CLI). В качестве альтернативных менеджеров можно использовать convirt (GUI) или convirt2 (WEB интерфейс).

В настоящее время в Ubuntu офицально поддерживается только гипервизор KVM. Этот гипервизор является частью кода ядра операционной системы Linux. В отличие от Xen, KVM не поддерживает паравиртуализацию, то есть, для того, чтобы его использовать, ваш CPU должен подерживать технологии VT. Вы можете проверить, поддерживает ли ваш процессор эту технологию, выполнив команду в терминале:

Если в результате получили сообщение:

INFO: /dev/kvm exists KVM acceleration can be used

значит KVM будет работать без проблем.

Если же на выходе получили сообщение:

Your CPU does not support KVM extensions KVM acceleration can NOT be used

то вы всё равно сможете использовать виртуальную машину, но работать она будет намного медленнее.

Устанавливать в качестве гостевых 64-битные системы

Выделять гостевым системам более 2 Гбайт ОЗУ

Установка

Sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Это установка на сервер без X-ов, т. е. не включает в себя графический интерфейс. Установить его можно командой

Sudo apt-get install virt-manager

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

Создание гостевой системы

Процедура создания гостевой системы с помощью графического интерфейса достаточно проста.

А вот текстовый режим можно и описать.

qcow2

При создании системы с помощью графического интерфейса в качестве жёсткого диска предлагается либо выбрать уже существующий файл-образ или блочное устройсво, либо создать новый файл с сырыми (RAW) данными. Однако, это далеко не единственный доступный формат файлов. Из всех перечисленных в man qemu-img типов дисков наиболее гибким и современным является qcow2 . Он поддерживает снапшоты, шифрование и сжатие. Его необходимо создавать до того, как создать новую гостевую систему.

Qemu-img create -o preallocation=metadata -f qcow2 qcow2.img 20G

Согласно тому же man qemu-img , предварительное размещение метаданных (-o preallocation=metadata) делает диск изначально немного больше, но обеспечивает лучшую производительность в те моменты, когда образу нужно расти. На самом деле, в данном случае эта опция позволяет избежать неприятного бага. Создаваемый образ изначально занимает меньше мегабайта места и по мере необходимости растёт до указанного размера. Гостевая система сразу должна видеть этот окончательный указанный размер, тем не менее, на этапе установки она может увидеть реальный размер файла. Естественно, устанавливаться на жёсткий диск размером 200 кбайт она откажется. Баг не специфичен для Ubuntu, проявляется ещё в RHEL, как минимум.

Кроме типа образа впоследствии можно будет выбрать способ его подключения - IDE, SCSI или Virtio Disk. От этого выбора будет зависеть производительность дисковой подсистемы. Однозначно правильного ответа нет, выбирать нужно исходя из задачи, которая будет возложена на гостевую систему. Если гостевая система создаётся «на посмотреть», то сойдёт любой способ. Вообще, обычно именно I/O является узким местом виртуальной машины, поэтому при создании высоконагруженной системы к этому вопросу нужно отнестись максимально ответственно.