Работа с виртуальными машинами KVM. Введение. Это страшное слово – «виртуализация». Мое решение на базе KVM

KVM (Kernel-based Virtual Machine ) - программное решение, обеспечивающее виртуализацию в среде Linux на платформе x86, которая поддерживает аппаратную виртуализацию на базе Intel VT (Virtualization Technology) либо AMD SVM (Secure Virtual Machine).

Программное обеспечение KVM состоит из загружаемого модуля ядра (называемого kvm.ko), предоставляющего базовый сервис виртуализации, процессорно-специфического загружаемого модуля kvm-amd.ko либо kvm-intel.ko , и компонентов пользовательского режима (модифицированного QEMU). Все компоненты программного обеспечения KVM открыты. Компонент ядра, необходимый для работы KVM, включён в основную ветку ядра Linux начиная с версии 2.6.20 (февраль 2007 года) . KVM был также портирован на FreeBSD как модуль ядра . Ведётся работа по включению модификаций, необходимых для работы с KVM, в основную ветку QEMU.

C KVM работает большое количество гостевых ОС, включаю множество видов и версий Linux, BSD, Solaris, Windows, Haiku, ReactOS, Plan 9, AROS Research Operating System а также OS X. В дополнение, Android 2.2, Minix 3.1.2a, Solaris 10 U3 and Darwin 8.0.1GNU/Hurd (Debian K16), Minix 3.1.2a, Solaris 10 U3 and Darwin 8.0.1, вместе с некоторыми версиями выше укзаных ОС, работают с некоторыми ограничениями.

Паравиртуализациия некоторых устройств доступна на Linux, OpenBSD, FreeBSD, NetBSD, Plan 9 и Windows гостевых ОС использующих VirtIO API. Это поддерживает паравиртуальные Ethernet карты, I/O контроллер диска, устройства для модификации потребляемой гостем памяти, а также графический интерфейс VGA используя драйверы SPICE или VMware.

Окружение

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

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

История

Программное обеспечение KVM было создано, разрабатывается и поддерживается фирмой Qumranet, которая была куплена Red Hat за $107 млн 4 сентября 2008 года. После сделки KVM (наряду с системой управления виртуализацией oVirt) вошла в состав платформы виртуализации RHEV. KVM поддерживается Paolo Bonzini.

Принцип работы

В настоящее время KVM взаимодействует с ядром через загружаемый модуль ядра. Поддерживаются разнообразные гостевые операционные системы, такие как Linux, BSD, Solaris, Windows, Haiku, ReactOS и AROS Research Operating System. Модифицированная версия KVM (qemu) может работать на Mac OS X. Примечание: KVM не выполняет никакой самоэмуляции; вместо этого, программа, работающая в пользовательском пространстве, применяет интерфейс /dev/kvm для настройки адресного пространства гостевого виртуального сервера, берет его смоделированные ресурсы ввода/вывода и отображает его образ на образ хоста.

В архитектуре KVM, виртуальная машина выполняется как обычный Linux-процесс, запланированный стандартным планировщиком Linux. На самом деле каждый виртуальный процессор представляется как обычный Linux-процесс. Это позволяет KVM пользоваться всеми возможностями ядра Linux. Эмуляцией устройств управляет модифицированная версия qemu, которая обеспечивает эмуляцию BIOS, шины PCI, шины USB, а также стандартный набор устройств, таких как дисковые контроллеры IDE и SCSI, сетевые карты и т.д.

Функциональные возможности

Безопасность

Поскольку виртуальная машина реализована как Linux-процесс, она использует стандартную модель безопасности Linux для изоляции и управления ресурсами. С помощью SELinux (Security-Enhanced Linux) ядро Linux добавляет обязательные средства контроля доступа, многоуровневые и разнообразные средства защиты, а также управляет политикой безопасности. SELinux обеспечивает строгую изоляцию ресурсов и ограничивает подвижность процессов, запущенных в ядре Linux.

Проект SVirt – попытка усилиями сообщества интегрировать функции безопасности Mandatory Access Control (MAC) и виртуализацию на базе Linux (KVM) - основывается на SELinux, чтобы обеспечить инфраструктуру, которая позволит администратору определять политику изоляции виртуальных машин. SVirt призван гарантировать, что ресурсы виртуальных машин не будут доступны ни для каких других процессов (или виртуальных машин); администратор может дополнить эту политику, определив детальные разрешения; например, чтобы группа виртуальных машин совместно использовала одни и те же ресурсы.

Управление памятью

KVM наследует мощные функции управления памятью от Linux. Память виртуальной машины хранится так же, как память любого другого Linux-процесса, и может заменяться, копироваться большими страницами для повышения производительности, обобщаться или сохраняться в файле на диске. Поддержка технологии NUMA (Non-Uniform Memory Access, архитектура памяти для многопроцессорных систем) позволяет виртуальным машинам эффективно обращаться к памяти большого объема.

KVM поддерживает новейшие функции виртуализации памяти от производителей процессоров, в частности, Intel Extended Page Table (EPT) и AMD Rapid Virtualization Indexing (RVI), для минимизации загрузки процессора и достижения высокой пропускной способности.

Обобщение страниц памяти поддерживается с помощью функции ядра Kernel Same-page Merging (KSM). KSM сканирует память каждой виртуальной машины, и если какие-то страницы памяти виртуальных машин идентичны, объединяет их в одну страницу, которая становится общей для этих виртуальных машин и хранится в единственной копии. Если гостевая система пытается изменить эту общую страницу, ей предоставляется собственная копия.

Хранение данных

KVM может использовать любой носитель, поддерживаемый Linux, для хранения образов виртуальных машин, в том числе локальные диски с интерфейсами IDE, SCSI и SATA, Network Attached Storage (NAS), включая NFS и SAMBA/CIFS, или SAN с поддержкой iSCSI и Fibre Channel. Для улучшения пропускной способности системы хранения данных и резервирования может использоваться многопоточный ввод/вывод.

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

KVM поддерживает образы виртуальных машин в распределенных файловых системах, таких как Global File System (GFS2), так что они могут разделяться несколькими хостами или обобщаться с использованием логических томов. Поддержка тонкой настройки (thin provisioning) образов дисков позволяет оптимизировать использование ресурсов хранения данных, выделяя их не сразу все наперед, а только тогда, когда этого требует виртуальная машина. Собственный формат дисков для KVM ― QCOW2 ― обеспечивает поддержку снимков текущего состояния и обеспечивает несколько уровней таких снимков, а также сжатие и шифрование.

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

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

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

Драйверы устройств

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

Гипервизор KVM использует стандарт VirtIO, разработанный IBM и Red Hat совместно с Linux-сообществом для паравиртуализированных драйверов; это независимый от гипервизора интерфейс для создания драйверов устройств, позволяющий нескольким гипервизорам использовать один и тот же набор драйверов устройств, что улучшает взаимодействие между гостевыми системами.

Драйверы VirtIO входят в современные версии Linux-ядра (наиболее поздняя ― 2.6.25), включены в Red Hat Enterprise Linux 4.8+ и 5.3+, а также доступны для Red Hat Enterprise Linux 3. Red Hat разработала драйверы VirtIO для гостевых ОС Microsoft Windows, оптимизирующие сетевые и дисковые операции ввода/вывода; эти драйверы сертифицированы по программе сертификации Microsoft Windows Hardware Quality Labs (WHQL).

Производительность и масштабируемость

KVM унаследовал производительность и масштабируемость Linux, поддерживая виртуальные машины с 16 виртуальными процессорами и 256 ГБ оперативной памяти, а также хост-системы с 256 ядрами и более 1 ТБ ОЗУ. Он может обеспечить:

производительность в 95-135% по сравнению с "голым железом" в реальных корпоративных приложениях, таких как SAP, Oracle, LAMP и Microsoft Exchange;
свыше миллиона сообщений в секунду и менее чем 200-мкс задержку в виртуальных машинах, работающих на стандартном сервере;
максимальные уровни консолидации более чем с 600 виртуальными машинами, выполняющими корпоративные приложения, на одном сервере.

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

Настройка

Настройка Virtual Machine Manager (VMM)

При первом запуске программы вы увидите две категории, обе не подключенные. Это ссылки на стандартные модули KVM, пока не работающие. Для их использования щелкните правой кнопкой мыши и выберите "connect".

Чтобы добавить новое соединение, выберите в меню File > Add Connection. При этом откроется окно, в котором можно будет задать тип гипервизора и тип соединения. VMM может использовать как локальные, так и удаленные соединения, включая QUEMU/KVM и Xen. Кроме того, поддерживаются все методы аутентификации.

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

Кратко рассмотрим остальные функции программы.
Сетевую функциональность можно просмотреть или изменить, открыв пункт Host Details. Там же мы установим утилиты для работы сетевого моста.

Аналогично можно изменить параметры дисковой подсистемы:

Создание виртуальной машины

Создать виртуальную машину можно и из командной строки, но мы воспользуемся VMM. Первый шаг должен быть интуитивно понятен. Введите название и задайте расположение инсталляционного диска. Это может быть как локальное устройство в виде диска CD/DVD или образа ISO, так и HTTP или FTP сервер, NFS или PXE.

Мы используем локальный носитель. Теперь необходимо задать, будет ли это физическое устройство или образ. В нашем случае используется ISO. Далее нужно выбрать тип и версию ISO. Здесь не требуется такая уж высокая точность, но правильный выбор позволит повысить производительность виртуальной машины.

Задаем количество процессоров и размер оперативной памяти:

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

Далее мы еще уделим внимание дисковой подсистеме. Однако обратите внимание, что при работе в режиме Usermode у вас не будет прав записи в /var, где по умолчанию хранятся образы виртуальных дисков. Поэтому необходимо будет задать другое расположение для образов.

Этап 5 - это вывод сводных данных с возможностью настройки некоторых продвинутых опций. Здесь вы можете изменить тип сети, задать фиксированные MAC-адреса, выбрать тип виртуализации и целевую архитектуру. Если вы работаете в режиме Usermode, возможности настройки сети будут ограничены, например невозможно будет создать мосты между сетевыми интерфейсами. И последнее: если ваш процессор не поддерживает аппаратной виртуализации, поле Virt Type будет иметь значение QUEMU и сменить его на KVM будет невозможно. Вы можете посмотреть, как выглядят типовые настройки для виртуальной машины Ubuntu:

KVM модуль ядра: GPL v2.
KVM модуль пользовательского окружения: LGPL v2.
QEMU библиотека виртуального процессора (libqemu.a) и эмулятор системы QEMU PC: LGPL.
Эмулятор пользовательского режима Linux QEMU: GPL.
Файлы BIOS (bios.bin , vgabios.bin и vgabios-cirrus.bin): SeaBIOS (LGPL v2 или более поздняя).

Графические инструменты

libvirt supports KVM

Kimchi веб инструмент менеджмента для KVM
Virtual Machine Manager поддерживает создание, редакцию, старт и остановку KVM-машин, также как холодную миграцию ВМ между хостами
Proxmox Virtual Environment свободный пакет менеджмента виртуализации, включая KVM и OpenVZ. Имеет установщик на голую машину, удаленный веб-интерфейс для менеджмента, и опционально коммерческую поддержку.
OpenQRM платформа менеджмента для управления гетерогенными дата центрами.
GNOME Boxes интерфейс Gnome для управления libvirt гостями на Linux.
oVirt свободный иснструмент менеджмента виртуализации для KVM на основе libvirt

Реализации

Debian 5.0 и выше
Gentoo Linux
illumos-based дистрибутивы
OpenIndiana
Red Hat Enterprise Linux (RHEL) 5.4 и выше
SmartOS
SUSE Linux Enterprise Server (SLES) 11 SP1 и выше
Ubuntu 10.04 LTS и выше
Univention Corporate Server

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

Почему ? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед 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.

Прочее

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

Гипервизоры, виртуализация и облако

Анализ гипервизора KVM

Серия контента:

Об этом цикле статей

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

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

Что нужно знать для начала

Kernel-based Virtual Machine (KVM) – это полное решение платформенно-зависимой виртуализации для Linux на процессорах x86 с расширениями виртуализации (Intel VT или AMD-V). Для гостевых систем доступна также ограниченная поддержка паравиртуализации для Linux и Windows в форме паравиртуального сетевого драйвера.

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

Архитектура KVM показана на рисунке 1.

Рисунок 1. Архитектура KVM

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

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

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

Эмуляцией устройств управляет модифицированная версия qemu, которая обеспечивает эмуляцию BIOS, шины PCI, шины USB, а также стандартный набор устройств, таких как дисковые контроллеры IDE и SCSI, сетевые карты и т.д.

Функциональные возможности

Ниже перечислены основные функции KVM.

Безопасность

Управление памятью

Хранение данных

KVM поддерживает образы виртуальных машин в распределенных файловых системах, таких как Global File System (GFS2), так что они могут разделяться несколькими хостами или обобщаться с использованием логических томов. Поддержка тонкой настройки (thin provisioning) образов дисков позволяет оптимизировать использование ресурсов хранения данных, выделяя их не сразу все наперед, а только тогда, когда этого требует виртуальная машина. Собственный формат дисков для KVM ― QCOW2 ― обеспечивает поддержку снимков текущего состояния и обеспечивает несколько уровней таких снимков, а также сжатие и шифрование.

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

Драйверы устройств

Производительность и масштабируемость

производительность в 95-135% по сравнению с "голым железом" в реальных корпоративных приложениях, таких как SAP, Oracle, LAMP и Microsoft Exchange;
свыше миллиона сообщений в секунду и менее чем 200-мкс задержку в виртуальных машинах, работающих на стандартном сервере;
максимальные уровни консолидации более чем с 600 виртуальными машинами, выполняющими корпоративные приложения, на одном сервере.

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

Развертывание виртуализации

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

Управление виртуальными машинами

Существует несколько менеджеров виртуальных машин. Среди них:

Univention Virtual Manager;
qemu/KVM: запускается прямо из командной строки в машине KVM;
Virsh: минимальная оболочка для управления виртуальными машинами;
Virtual Machine Manager: иначе - virt-manager, пользовательский интерфейс для управления виртуальными машинами.

Выбор KVM

Доводы "за":

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

Доводы "против":

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

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

Первый материал, из серии «технологии VPS/VDS», посвящен программному продукту KVM (Kernel-based Virtual Machine). Начинаем с него, так как именно этот гипервизор мы используем в облаке Tucha и, конечно же, наше отношение к нему особенное.

Гипервизор KVM: особенности и принцип работы

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

Гипервизор KVM: архитектура

KVM (аббревиатура от Kernel-based Virtual Machine) – это программное обеспечение, которое дает возможность реализовать виртуализацию на базе компьютеров под управлением ОС Linux и подобных. С некоторых пор KVM является частью Linux-ядра, потому развивается вместе с ним. Работает только в системах с аппаратной поддержкой виртуализации – на процессорах Intel и AMD.

Для организации работы KVM использует прямой доступ к ядру с помощью процессор-специфичного модуля (kvm-intel или kvm-amd). Кроме того, в состав комплекса входит главное ядро – kvm.ko и элементы UI, в том числе и популярный QEMU. Гипервизор позволяет работать напрямую с файлами виртуальных машин и образами дисков из других программ. Для каждой машины создается изолированное пространство со своей памятью, диском, сетевым доступом, видеокартой и другими устройствами.

Преимущества и недостатки KVM

Как и любое программное решение, KVM имеет как плюсы, так и минусы, исходя из которых, хостеры и конечные потребители принимают решение об использовании этого ПО.

Основные преимущества гипервизора таковы:

независимо распределяемые ресурсы . Каждая работающая под управлением KVM виртуальная машина получает свой объем оперативной и постоянной памяти и не может «залезть» в другие области, что повышает стабильность работы;
широкая поддержка гостевых ОС . Кроме полной поддержки UNIX-дистрибутивов, в том числе *BSD, Solaris, Linux, есть возможность устанавливать Windows и даже MacOS;
взаимодействие с ядром позволяет напрямую обращаться к оборудованию рабочей станции, что делает работу более быстрой ;
поддержка грандов софтверного рынка (RedHat Linux, HP, Intel, IBM) позволяет проекту быстро развиваться, охватывая все большее количество оборудования и OS, в том числе новейших;
простое администрирование – возможность удаленного управления через VNC и большое количество стороннего ПО и надстроек.

Без недостатков также не обошлось:

относительная молодость гипервизора (например, по сравнению с Xen) и соответственно взрывной рост приводят к различным проблемам, особенно при добавлении поддержки нового оборудования и программного окружения;
сложность настроек, особенно для неискушенного пользователя. Правда, большинство опций можно не менять – они настроены оптимально «из коробки».

Функциональные возможности и свойства гипервизора

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

Безопасность

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

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

Хранение данных

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

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

Производительность и масштабируемость

Масштабируемость и производительности комплекса благодаря плотной интеграции с Linux, полностью унаследованы от этой ОС. Таким образом, гипервизор поддерживает до 16 процессоров (виртуальных или физических) и до 256 ГБ ОЗУ в каждой виртуальной машине. Это позволяет использовать гипервизор даже в наиболее высоконагруженных системах.

Стабильность

Программный комплекс постоянно совершенствуется - если изначально он поддерживал только платформу Linux x86, то сегодня количество различных платформ исчисляется десятками, включая все популярные серверные ОС. Кроме того, вы без труда сможете развернуть виртуальную машину с модифицированной сборкой операционной системы, если она совместима с родительской платформой. А благодаря сотрудничеству с ведущими производителями ПО гипервизор KVM можно назвать самым стабильным и надежным на рынке.

Заметка пригодится всем, кому интересно использовать виртуализацию в своей работе. Мое решение вполне может претендовать на промышленное применение и пригодится тем, кто захочет сократить расходы на аппаратную часть при необходимости иметь в наличии разветвленную сетевую инфраструктуру. На подобном варианте базируется некоторые решения от IBM, к примеру. Но эти решения далеко не бюджетные и востребованы лишь в исключительных случаях.
Итак, однажды мне понадобилось в домашних условиях воспроизвести разветвленную сетевую инфраструктуру, состоящую из различных программных платформ. Путь начинался от VMWare Workstation и завершился KVM… Почему именно KVM и как все было, читайте ниже.

1. Немного истории или с чего все началось.
Работая в банке, я вживую столкнулся с виртуализацией. Это была операционная система AIX от IBM, работающая на майнфреймах. С самого начала меня поразила мощь и гибкость подобного подхода. И когда мне понадобилось воспроизвести в тестовых целях дома разветвленную программную инфраструктуру, то сразу базировал все это на принципах виртуализации. Это позволило избежать как значительных затрат на аппаратную часть, так и уместить все весьма компактно в плане пространства.
Для читателя следует учесть, что на самом деле инструментов виртуализации великое множество. Каждый из них имеет свои тонкости и нюансы. Я же ставлю цель рассказать об одном варианте, с которыми работаю лично, описывая по возможности недостатки и особенности остальных.
2. Мой выбор называется KVM (или Kernel-based Virtual Machine).
Подробнее об этом варианте можно почитать .
Но лучше все по порядку излагать. Начну с условий отбора и какие из известных мне вариантов этим условиям неудовлетворяют:
— основная система должна быть бюджетной и мощной.

В аппаратном плане я выбрал вариант AMD Phenom X4 9550 / Asus M3A78 / 2x2Gb DDR-II / 1x160Gb IDE + 2x1Tb SATA-II. Видео здесь совершенно не приципиально, кроме того, что в случае встроенной придется учитывать, что она под себя забирает часть оперативной памяти, соответственно для виртуальных машин ее останется меньше. Скажу сразу — выбор материнки с встроенным RAID-контроллером был не совсем корректным. Как выяснилось, RAID этот работает только в программном режиме, т.е. нужны драйвера для Windows систем, ну а в Linux такого же эффекта можно было достичь гораздо проще, используя стандартные средства.
Использование программной платформы для основной системы было однозначно в пользу GNU/Linux, т.к. позволяло получить среду виртуализации без лишних затрат на лицензирование, а также более облегченную в плане нагрузки (вот никогда я не пойму, почему в Windows Server без графики ничего нельзя поставить и сделать…. бессмысленная нагрузка, ИМХО). Изначально планировалось использовать вариант Ubuntu Server Hardy LTS, но почти сразу была произведена миграция на Debian Lenny (он к тому времени как раз вышел).Ни в коем случае не принижаю достоинства Ubuntu, но субьективно Debian стабильнее и быстрее работает.

— система виртуализации должна быть стабильной, общедоступной и нетребовательной к ресурсам.

От выбора разбегаются глаза, но после изучения отзывов в интернете и попыток использования сложилось субьективное мнение.
Продукты VMWare не подходят. Workstation платная, ESXi не удалось поставить на мою систему из-за неподдерживаемого чипсета (он у меня оказался более современным). Неплохим выбором был бы VMWare Server, но судя по отзывав она тяжеловата и периодически падает, сам я не стал пробовать после неудачи с ESXi. Не подошли они еще по одной причине — компания все таки продает свои продукты и только часть из них доступна в свободном доступе.
VirtualBox оказался весьма удачным вариантом. Существует в двух вариантах — OSE и Freeware. В открытом доступе исходников Freeware-версии нет, зато компенсируется это функциональностью. Из известных мне различий — это отсутствие в OSE версии поддержки USB, ограничения при работе с сетью, неподдерживается графическая акселерация (кстати, дающая весьма приличный прирост скорости работы виртуальной машины). VirtualBox идеально подходит для простейшей реализации, т.к. позволяет быстро получить работоспособную виртуальную машину без лишних телодвижений и внимательного изучения руководства. Приятной особенностью оказалась поддержка работы из консоли, что позволяет не использовать графических надстроек и соответственно снимается дополнительная нагрузка на хост-машину. Для начинающих «домашних виртуализаторов» я бы посоветовал именно такой вариант. Лично я до сих пор его использую на личном ноутбуке для быстрого поднимания тестовой среды, а также для работы в Windows (там уже давно и стабильно обосновалась Ubuntu в качестве основной системы). По субьективным ощущениям работает VirtualBox гораздо шустрее VMWare Workstation, занимает меньше места как на диске, так и в памяти. Для каждой машины выделяется отдельное окно, а также при установленных драйвера в гостевой системе (есть «из коробки») есть возможность интегрировать в рабочий стол хоста, что очень удобно и позволяет разнести задачи на разные виртуальные столы.
QEMU — очень мощная штука. Но когда вспомнил про нее, уже обратил внимание на виртуализацию на базе ядра и информацию про Xen и KVM, потому близко знакомится с чистым QEMU не стал.
Xen — идеальная система для виртуализации. Но имеет весьма существенный недостаток — гостевая система должна быть заранее подготовленна.
KVM, базируется на QEMU, по скорости почти не уступает Xen, зато обладает более гибкой функциональностью, всей мощью настроек QEMU (хотя основная часть необходимых мне была и в VirtualBOX). Оба варианта, Xen и KVM реализованы во всех современных дистрибутивах и для использования не надо прилагать серьезных усилий. Но есть между ними принципиальное отличие, о котором пойдет речь дальше.

— необходимо иметь возможность воспроизвести на виртуальных машинах различные программные платформы.

Несмотря на доступность в этом плане продуктов VMWare и VirtualBOX, от их использования я отказался еще ранее, так что рассматривать не буду… А вот применительно к Xen и KVM опишу чуток подробнее, т.к. сам искал информацию весьма долго.
Xen не позволяет запускать системы отличные от хостовой!!!, а точнее не подготовленные заранее для работы в виртуальной среде. И к сожалению (а может к счастью), подобной обработке не поддаются дистрибутивы Windows. Что меня не устраивало, потому в итоге выбор пал на варианте использования KVM, для которого заранее подготавливать гостевую систему не надо.

Итак причины выбора KVM кратко:

1. Реализация доступна из коробки в любом большом дистрибутиве;
2. Реализовано на базе ядра Linux, соответственно обладает большой скоростью;
3. Используется такими гигантами, как RedHat и Ubuntu, что говорит о высокой стабильности и гибкости;
4. Не требуется дополнительных махинаций с гостевой системой для установки в виртуальную машину.

3. Как я сделал это на Debian.
Дальше пойдет больше техническое описание, описывающее по шагам, как я сделал свой сервер, свободно тянущий с десяток виртуальных серверов.
Несмотря на то, что мой любимый дистрибутив Ubuntu, в итоге под базовую системы был выбран Debian. В рамках статьи объяснять тонкостей не буду, что да как, но на десктопе я все также предпочитаю использовать Ubuntu. Большинство инструкций для Ubuntu и Debian актуальны для обоих вариантов, потому при настройке я использовал и это и то и другое .
Итак, начнем ставить сервер.
Берем дистрибутив Debian. Чтобы не качать лишнего потом и сразу получить свежую систему, я брал вариант netinstall, при помощи которого устанавливал только вариант «Стандартная система», большего нам и не надо. Кстати, я использую 64-битный выпуск, чтобы получить поддержку большего количества оперативной памяти (>3Гб) без обходных путей и выкрутасов (к примеру, 32-битное серверное ядро дистрибутива Ubuntu поддерживает больше, чем 3Гб, но только при наличии такой возможности в чипсете).
Я использую под системные разделы («/», «/home», swap) жесткий диск IDE, дабы не иметь проблем при работе системы при установке на RAID-массив (а они есть). При установке сразу создаю RAID-1 на основе двух жестких дисков SATA для достижения большей сохранности данных (основная информация будет храниться на нем). В дальнейшем для работы с софтовым RAID-массивом следует использовать утилиту mdadm .
Свежеустановленную систему я немного ретуширую. Для начала устанавливаю ssh, чтобы можно было сразу засунуть системник подальше и отключить от него уже ненужный монитор: sudo apt-get install ssh Многие советуют переключить порт с стандартного 22 на другой. Но это следует делать только в том случае, если вы уверены в своих действиях и ваш сервер подключен напрямую к интернету. Кстати, следует упомянуть, что если будет использоватся нестандартный порт, то потом возникнут сложности с удаленным управлением KVM-виртуализацией. Поэтому я оставил стандартный порт, но через аппаратный маршрутизатор сделал переброску на нестандартный, доступный снаружи.

Затем включаем синхронизацию времени через интернет (настоятельно советую, пригодится).
sudo apt-get install ntp ntpdate
Для контроля температуры чипсетов, процессора и жестких дисков:
sudo apt-get install lm-sensors hddtemp
Утилита hddtemp работает сразу, для настройки lm-sensors запускаем после установки: sudo sensors-detect отвечаем на все вопросы утвердительно.
Использовать очень просто:
— узнать температуру процессора, чипсета и других характеристик sudo sensors получаем что-то вроде:

it8712-isa-0290
Adapter: ISA adapter
VCore 1: +1.33 V (min = +3.54 V, max = +3.30 V) ALARM
VCore 2: +3.76 V (min = +1.39 V, max = +1.01 V) ALARM
+3.3V: +3.28 V (min = +4.00 V, max = +0.91 V) ALARM
+5V: +6.69 V (min = +3.04 V, max = +6.10 V) ALARM
+12V: +12.67 V (min = +15.23 V, max = +5.57 V) ALARM
-12V: -15.33 V (min = -0.85 V, max = -12.39 V) ALARM
-5V: +2.85 V (min = +3.06 V, max = +3.47 V) ALARM
Stdby: +5.99 V (min = +0.11 V, max = +6.37 V)
VBat: +3.31 V
fan1: 2922 RPM (min = 3260 RPM, div = 2)
fan2: 0 RPM (min = 5400 RPM, div = 2) ALARM
fan3: 0 RPM (min = 2732 RPM, div = 2) ALARM
M/B Temp: +44.0°C (low = -73.0°C, high = -49.0°C) sensor = transistor
CPU Temp: +32.0°C (low = -65.0°C, high = -9.0°C) sensor = transistor
Temp3: +128.0°C (low = +23.0°C, high = -66.0°C) sensor = disabled
cpu0_vid: +0.000 V

— узнать температуру 1 жесткого диска SATA — sudo hddtemp /dev/sda получаем что-то вроде:

/dev/sda: WDC WD1001FALS-00J7B0: 33°C

Для дальнейшей работы рекомендую обзавестись сторонним DHCP-сервером и на нашем сервере виртуализации настроить bridge-интерфейс.
Установим нужные утилиты: sudo apt-get install bridge-utils
Я использую в качестве DHCP-сервера свой роутер, а bridge-интерфейс создавал по инструкции . По той же инструкции рассказано, как сделать, чтобы виртуальная машина в KVM создавалась по умолчанию с использованием этого способа подключения. Для ускорения перезагрузки (совершенно не критичная ситуация, если сервер будет включен круглосуточно) советую заранее указать статический адрес на интерфейс даже при условии доступности DHCP.

И самое вкусное, устанавливаем KVM модули и полезные утилиты. Сразу добавим текущего пользователя в соответствующую группу для доступности использования KVM. Описание использования утилит можно найти по уже указанным руководствам. sudo aptitude install kvm libvirt-bin virtinst virt-top python-virtinst
sudo adduser softovick libvirt Фактически сразу можно использовать. Описывать все команды смысла не вижу, для этого есть man. Но покажу, как я создаю виртуальную машину:
для Linux virt-install -n linux -r 512 -f linux.img -s 15 -c образ.iso --accelerate --vnc --vncport=5900 --noautoconsole --os-type=linux --os-variant=generic26
для Windows virt-install -n windows -r 512 -f windows.img -s 15 -c образ.iso --accelerate --vnc --vncport=5901 --noautoconsole --os-type=windows --os-variant=win2k3 --noacpi После этого дальнейший ход установки и экран гостевой машины можно контролировать, подключившись при помощи VNC-клиента к серверу по порту 5900 и 5901(рекомендую для каждой машины заранее определять порт VNC, чтобы было удобно подключаться). Есть еще несколько полезных опций, я их не использую лишь потому, что не столкнулся с их необходимостью.

И еще один штрих, но не последний. Как подключить к гостевой системе возможность что-то писать напрямую на физический раздел или папку на рейде, я пока не понял, хотя и старался. Поэтому в случае Linux я подключаюсь к данным на сервере при помощи nfs, а в случае Windows — при помощи Samba. Настройка Samba достаточно тривиальна, устанавливаем sudo aptitude install samba и правим конфигурационный файл /etc/samba/smb.conf под свои задачи. А вот установка и настройка nfs не совсем тривиальна. Я использую такой вариант установки, позволяющий подключаться к нужным папкам с любого ip-адреса локальной сети (вида 192.168.10.*): sudo aptitude install nfs-kernel-server portmap
perl -pi -e "s/^OPTIONS/#OPTIONS/" /etc/default/portmap
echo "portmap: 192.168.10." >> /etc/hosts.allow
/etc/init.d/portmap restart
echo "/media/raid 192.168.10.0/255.255.255.0(rw,no_root_squash,subtree_check)" >> /etc/exports
/etc/init.d/nfs-kernel-server reload
После приведенных действий достаточно на гостевой системе сделать так:
sudo mount сервер:/media/raid локальная_папка
При необходимости можно включить автоматическое монтирование при загрузке, поправив конфигурационный файл /etc/fstab, добавив туда строку типа:
virtual:/media/raid /media/raid nfs defaults 0 2
Ну вот, в целом настройка нашего сервера виртуализации завершена. Управлять им можно как в консоли, так и при помощи графических инструментов virsh или virtual manager .

P.S.:
Некоторые полезные советы:
1. Если вы указали конкретный порт VNC для гостевой машины, то через Virtual Manager вы не сможете автоматически запустить графическую консоль.
2. Virtual Manager не сможет подключиться, если у вас переопределен порт ssh. Точнее для этого придется долго и нудно разбираться.
3. Обязательно используйте для гостевой Windows Server режим —noacpi, чтобы она нормально установилась.
4. Аккуратно настраивайте режим сбережения энергии на гостевых системах, ни в коем случае не отключайте экран, иначе не сможете потом подключится по VNC.
5. Если вы хотите удаленно выключать и перезагружать машины через Virtual Manager, то отключайте хранитель экрана, т.к. он блокирует управление питанием.