Проверка поддержки гипервизора
Проверяем, что сервер поддерживает технологии виртуализации:
cat /proc/cpuinfo | egrep "(vmx|svm)"
В ответ должны получить что-то наподобие:
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
В противном случае, заходим в БИОС, находим опцию для включения технологии виртуализации (имеет разные названия, например, Intel Virtualization Technology или Virtualization) и включаем ее — задаем значение Enable .
Также проверить совместимость можно командой:
* если команда вернет ошибку «kvm-ok command not found» , установите соответствующий пакет: apt-get install cpu-checker .
Если видим:
INFO: /dev/kvm exists
KVM acceleration can be used
значит поддержка со стороны аппаратной части есть.
Подготовка сервера
Для нашего удобства, создадим каталог, в котором будем хранить данные для KVM:
mkdir -p /kvm/{vhdd,iso}
* будет создано два каталога: /kvm/vhdd (для виртуальных жестких дисков) и /kvm/iso (для iso-образов).
Настроим время:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* данная команда задает зону в соответствии с московским временем.
ntpdate ru.pool.ntp.org
* выполняем синхронизацию с сервером времени.
Установка и запуск
Устанавливаем KVM и необходимые утилиты управления.
а) Ubuntu до версии 18.10
apt-get install qemu-kvm libvirt-bin virtinst libosinfo-bin
б) Ubuntu после 18.10:
apt-get install qemu-kvm libvirt-daemon-system libvirt-bin virtinst libosinfo-bin
* где qemu-kvm — гипервизор; libvirt-bin — библиотека управления гипервизором; virtinst — утилита управления виртуальными машинами; libosinfo-bin — утилита для просмотра списка вариантов операционных систем, которые могут быть в качестве гостевых.
Настроим автоматический запуск сервиса:
systemctl enable libvirtd
Запустим libvirtd:
systemctl start libvirtd
Настройка сети
Виртуальные машины могут работать за NAT (в качестве которого выступает сервер KVM) или получать IP-адреса из локальной сети — для этого необходимо настроить сетевой мост. Мы настроим последний.
Используя удаленное подключение, внимательно проверяйте настройки. В случае ошибки соединение будет прервано.
Устанавливаем bridge-utils:
apt-get install bridge-utils
а) настройка сети в старых версиях Ubuntu (/etc/network/interfaces).
Открываем конфигурационный файл для настройки сетевых интерфейсов:
vi /etc/network/interfaces
И приведем его к виду:
#iface eth0 inet static
# address 192.168.1.24
# netmask 255.255.255.0
# gateway 192.168.1.1
# dns-nameservers 192.168.1.1 192.168.1.2
Auto br0
iface br0 inet static
address 192.168.1.24
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1 192.168.1.2
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
* где все, что закомментировано — старые настройки моей сети; br0 — название интерфейса создаваемого моста; eth0 — существующий сетевой интерфейс, через который будет работать мост.
Перезапускаем службу сети:
systemctl restart networking
б) настройка сети в новых версиях Ubuntu (netplan).
vi /etc/netplan/01-netcfg.yaml
* в зависимости от версии системы, конфигурационной файл yaml может иметь другое название.
Приводим его к виду:
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: false
dhcp6: false
wakeonlan: true
Bridges:
br0:
macaddress: 2c:6d:45:c3:55:a7
interfaces:
- eth0
addresses:
- 192.168.1.24/24
gateway4: 192.168.1.1
mtu: 1500
nameservers:
addresses:
- 192.168.1.1
- 192.168.1.2
parameters:
stp: true
forward-delay: 4
dhcp4: false
dhcp6: false
* в данном примере мы создаем виртуальный бридж-интерфейс br0 ; в качестве физического интерфейса используем eth0 .
Применяем сетевые настройки:
Настаиваем перенаправления сетевого трафика (чтобы виртуальные машины с сетевым интерфейсом NAT могли выходить в интернет):
vi /etc/sysctl.d/99-sysctl.conf
Добавляем строку:
net.ipv4.ip_forward=1
Применяем настройки:
sysctl -p /etc/sysctl.d/99-sysctl.conf
Создание виртуальной машины
Для создания первой виртуальной машины вводим следующую команду:
virt-install -n VM1 \
--autostart \
--noautoconsole \
--network=bridge:br0 \
--ram 2048 --arch=x86_64 \
--vcpus=2 --cpu host --check-cpu \
--disk path=/kvm/vhdd/VM1-disk1.img,size=16 \
--cdrom /kvm/iso/ubuntu-18.04.3-server-amd64.iso \
--graphics vnc,listen=0.0.0.0,password=vnc_password \
--os-type linux --os-variant=ubuntu18.04 --boot cdrom,hd,menu=on
- VM1 — имя создаваемой машины;
- autostart — разрешить виртуальной машине автоматически запускаться вместе с сервером KVM;
- noautoconsole — не подключается к консоли виртуальной машины;
- network — тип сети. В данном примере мы создаем виртуальную машину с интерфейсом типа «сетевой мост». Для создания внутреннего интерфейса с типом NAT вводим --network=default,model=virtio ;
- ram — объем оперативной памяти;
- vcpus — количество виртуальных процессоров;
- disk — виртуальный диск: path — путь до диска; size — его объем;
- cdrom — виртуальный привод с образом системы;
- graphics — параметры подключения к виртуальной машины с помощью графической консоли (в данном примере используем vnc); listen — на какой адресе принимает запросы vnc (в нашем примере на всех); password — пароль для подключения при помощи vnc;
- os-variant — гостевая операционная система (весь список мы получали командой osinfo-query os , в данном примере устанавливаем Ubuntu 18.04).
Подключение к виртуальной машине
На компьютер, с которого планируем работать с виртуальными машинами, скачиваем VNC-клиент, например, TightVNC и устанавливаем его.
На сервере вводим:
virsh vncdisplay VM1
команда покажет, на каком порту работает VNC для машины VM1. У меня было:
* :1 значит, что нужно к 5900 прибавить 1 — 5900 + 1 = 5901.
Запускаем TightVNC Viewer, который мы установили и вводим данные для подключения:
Кликаем по Connect . На запрос пароля вводим тот, что указали при создании ВМ, (vnc_password ). Мы подключимся к виртуальной машине удаленной консолью.
Если мы не помним пароль, открываем настройку виртуальной машины командой:
И находим строку:
* в данном примере для доступа к виртуальной машине используется пароль 12345678 .
Управление виртуальной машиной из командной строки
Примеры команд, которые могут пригодиться при работе с виртуальными машинами.
1. Получить список созданных машин:
virsh list --all
2. Включить виртуальную машину:
virsh start VMname
* где VMname — имя созданной машины.
3. Выключить виртуальную машину:
ubuntu-vm-builder — пакет, разработанный компанией Canonical для упрощения создания новых виртуальных машин.
Для его установки вводим:
apt-get install ubuntu-vm-builder
Сегодня сложно представить мир без компьютеризированных устройств. Лет этак 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 устройства).
В жизни сисадмина однажды настает момент, когда приходится с нуля разворачивать инфраструктуру предприятия либо переделывать уже имеющуюся, перешедшую по наследству. В этой статье я расскажу о том, как правильно развернуть гипервизор на основе Linux KVM и libvirt c поддержкой LVM (логических групп).
Мы пройдемся по всем тонкостям управления гипервизором, включая консольные и GUI-утилиты, расширение ресурсов и миграцию виртуальных машин на другой гипервизор.
Для начала разберемся с тем, что такое виртуализация. Официальное определение звучит так: «Виртуализация - это предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе». То есть, если выражаться человеческим языком, имея один мощный сервер, мы можем превратить его в несколько средних серверов, и каждый из них будет выполнять свою задачу, отведенную ему в инфраструктуре, не мешая при этом другим.
Системные администраторы, работающие вплотную с виртуализацией на предприятии, мастера и виртуозы своего дела, поделились на два лагеря. Одни - приверженцы высокотехнологичной, но безумно дорогой VMware для Windows. Другие - любители open source и бесплатных решений на основе Linux VM. Можно долго перечислять преимущества VMware, но здесь мы остановимся на виртуализации, основанной на Linux VM.
Технологии виртуализации и требования к железу
Сейчас есть две популярные технологии виртуализации: Intel VT и AMD-V. В Intel VT (от Intel Virtualization Technology) реализована виртуализация режима реальной адресации; соответствующая аппаратная виртуализация ввода-вывода называется VT-d. Часто эта технология обозначается аббревиатурой VMX (Virtual Machine eXtension). В AMD создали свои расширения виртуализации и первоначально называли их AMD Secure Virtual Machine (SVM). Когда технология добралась до рынка, она стала называться AMD Virtualization (сокращенно AMD-V).
Перед тем как вводить аппаратное обеспечение в эксплуатацию, убедись, что оборудование поддерживает одну из этих двух технологий (посмотреть можно в характеристиках на сайте производителя). Если поддержка виртуализации имеется, ее необходимо включить в BIOS перед развертыванием гипервизора.
Среди других требований гипервизоров - поддержка аппаратного RAID (1, 5, 10), которая повышает отказоустойчивость гипервизора при выходе жестких дисков из строя. Если поддержки аппаратного RAID нет, то можно использовать программный на крайний случай. Но RAID - это мастхэв!
Решение, описанное в этой статье, несет на себе три виртуальные машины и успешно работает на минимальных требованиях: Core 2 Quad Q6600 / 8 Гбайт DDR2 PC6400 / 2 × 250 Гбайт HDD SATA (хардверный RAID 1).
Установка и настройка гипервизора
Я покажу, как настраивать гипервизор, на примере Debian Linux 9.6.0 - Х64-86. Ты можешь использовать любой дистрибутив Linux, который тебе по душе.
Когда ты определишься с выбором железа и его наконец-то привезут, придет время ставить гипервизор. При установке ОС все делаем, как обычно, за исключением разметки дисков. Неопытные администраторы часто выбирают опцию «Автоматически разбить все дисковое пространство без использования LVM». Тогда все данные будут записаны на один том, что нехорошо по нескольким причинам. Во-первых, если жесткий диск выйдет из строя, ты потеряешь все данные. Во-вторых, изменение файловой системы доставит массу хлопот.
В общем, чтобы избежать лишних телодвижений и потери времени, рекомендую использовать разметку диска с LVM.
Logical Volume Manager
Менеджер логических томов (LVM) - это подсистема, доступная в Linux и OS/2, построенная поверх Device Mapper. Ее задача - представление разных областей с одного жесткого диска или областей с нескольких жестких дисков в виде одного логического тома. LVM создает из физических томов (PV - Phisical Volumes) логическую группу томов (VG - Volumes Group). Она, в свою очередь, состоит из логических томов (LV - Logical Volume).
Сейчас во всех дистрибутивах Linux с ядром 2.6 и выше есть поддержка LVM2. Для использования LVM2 на ОС с ядром 2.4 надо устанавливать патч.
После того как система обнаружила жесткие накопители, запустится менеджер разбивки жестких дисков. Выбираем пункт Guided - use entire disk and set up LVM.
Теперь выбираем диск, на который будет установлена наша группа томов.
Система предложит варианты разметки носителя. Выбираем «Записать все файлы на один раздел» и идем дальше.
После сохранения изменений мы получим одну логическую группу и два тома в ней. Первый - это корневой раздел, а второй - это файл подкачки. Тут многие зададут вопрос: а почему не выбрать разметку вручную и не создать LVM самому?
Я отвечу просто: при создании логической группы VG загрузочный раздел boot не пишется в VG, а создается отдельным разделом с файловой системой ext2. Если этого не учесть, то загрузочный том окажется в логической группе. Это обречет тебя на мучения и страдания при восстановлении загрузочного тома. Именно поэтому загрузочный раздел отправляется на том без LVM.
Переходим к конфигурации логической группы для гипервизора. Выбираем пункт «Конфигурация менеджера логических томов».
Система оповестит о том, что все изменения будут записаны на диск. Соглашаемся.
Создадим новую группу - к примеру, назовем ее vg_sata .
INFO
В серверах используются носители SATA, SSD, SAS, SCSI, NVMe. Хорошим тоном при создании логической группы будет указывать не имя хоста, а тип носителей, которые используются в группе. Советую логическую группу назвать так: vg_sata , vg_ssd , vg_nvme и так далее. Это поможет понять, из каких носителей построена логическая группа.
Создаем наш первый логический том. Это будет том для корневого раздела операционной системы. Выбираем пункт «Создать логический том».
Выбираем группу для нового логического тома. У нас она всего одна.
Присваиваем имя логическому тому. Правильнее всего при назначении имени будет использовать префикс в виде названия логической группы - например, vg_sata_root , vg_ssd_root и так далее.
Указываем объем для нового логического тома. Советую выделить под корень 10 Гбайт, но можно и меньше, благо логический том всегда можно расширить.
По аналогии с примером выше создаем следующие логические тома:
- vg_sata_home - 20 Гбайт под каталоги пользователей;
- vg_sata_opt - 10 Гбайт для установки прикладного ПО;
- vg_sata_var - 10 Гбайт для часто меняющихся данных, к примеру логов системы и других программ;
- vg_sata_tmp - 5 Гбайт для временных данных, если объем временных данных велик, можно сделать и больше. В нашем примере этот раздел не создавался за ненадобностью;
- vg_sata_swap - равен объему оперативной памяти. Это раздел для свопа, и создаем мы его для подстраховки - на случай, если закончится оперативная память на гипервизоре.
После создания всех томов завершаем работу менеджера.
Теперь имеем несколько томов для создания разделов операционной системы. Нетрудно догадаться, что для каждого раздела есть свой логический том.
Создаем одноименный раздел под каждый логический том.
Сохраняем и записываем проделанные изменения.
После сохранения изменений разметки диска начнут ставиться базовые компоненты системы, а затем будет предложено выбрать и установить дополнительные компоненты системы. Из всех компонентов нам понадобится ssh-server и стандартные системные утилиты.
После установки будет сформирован и записан на диск загрузчик GRUB. Устанавливаем его на тот физический диск, где сохранен загрузочный раздел, то есть /dev/sda .
Теперь ждем, пока закончится запись загрузчика на диск, и после оповещения перезагружаем гипервизор.
После перезагрузки системы заходим на гипервизор по SSH. Первым делом под рутом устанавливаем нужные для работы утилиты.
$ sudo apt-get install -y sudo htop screen net-tools dnsutils bind9utils sysstat telnet traceroute tcpdump wget curl gcc rsync
Настраиваем SSH по вкусу. Советую сразу сделать авторизацию по ключам. Перезапускаем и проверяем работоспособность службы.
$ sudo nano /etc/ssh/sshd_config $ sudo systemctl restart sshd; sudo systemctl status sshd
Перед установкой софта для виртуализации необходимо проверить физические тома и состояние логический группы.
$ sudo pvscan $ sudo lvs
Устанавливаем компоненты виртуализации и утилиты для создания сетевого моста на интерфейсе гипервизора.
$ sudo apt-get update; apt-get upgrade -y $ sudo apt install qemu-kvm libvirt-bin libvirt-dev libvirt-daemon-system libvirt-clients virtinst bridge-utils
После установки настраиваем сетевой мост на гипервизоре. Комментируем настройки сетевого интерфейса и задаем новые:
$ sudo nano /etc/network/interfaces
Содержимое будет примерно таким:
Auto br0 iface br0 inet static address 192.168.1.61 netmask 255.255.255.192 gateway 192.168.1.1 broadcast 192.168.0.61 dns-nameserver 127.0.0.1 dns-search сайт bridge_ports enp2s0 bridge_stp off bridge_waitport 0 bridge_fd 0
Добавляем нашего пользователя, под которым будем работать с гипервизором, в группы libvirt и kvm (для RHEL группа называется qemu).
$ sudo gpasswd -a iryzhevtsev kvm $ sudo gpasswd -a iryzhevtsev libvirt
Теперь необходимо инициализировать нашу логическую группу для работы с гипервизором, запустить ее и добавить в автозагрузку при запуске системы.
$ sudo virsh pool-list $ sudo virsh pool-define-as vg_sata logical --target /dev/vg_sata $ sudo virsh pool-start vg_sata; sudo virsh pool-autostart vg_sata $ sudo virsh pool-list
INFO
Для нормальной работы группы LVM с QEMU-KVM требуется сначала активировать логическую группу через консоль virsh .
Теперь скачиваем дистрибутив для установки на гостевые системы и кладем его в нужную папку.
$ sudo wget https://mirror.yandex.ru/debian-cd/9.5.0/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso $ sudo mv debian-9.5.0-amd64-netinst.iso /var/lib/libvirt/images/; ls -al /var/lib/libvirt/images/
Чтобы подключаться к виртуальным машинам по VNC, отредактируем файл /etc/libvirt/libvirtd.conf:
$ sudo grep "listen_addr = " /etc/libvirt/libvirtd.conf
Раскомментируем и изменим строчку listen_addr = "0.0.0.0" . Сохраняем файл, перезагружаем гипервизор и проверяем, все ли службы запустились и работают.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «сайт», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Прежде, чем начать наш обзор, стоит разобраться, что представляет из себя гипервизор, и какие функции он выполняет. При выполнении большого количества разнообразных задач очень удобно пользоваться . Это связно с тем, что они дают возможность на одном физическом сервере размещать несколько операционных систем, каждая из которых оснащена собственным программным обеспечением для решения разнообразных задач. Чтобы обеспечить простое взаимодействие с такими виртуальными машинами, используются гипервизоры. Они представляют из себя программное обеспечение, которое и позволяет осуществлять управление виртуальными машинами: устанавливать, включать и выключать их. Одним из самых популярных гипервизоров на сегодняшний день можно назвать KVM.
Гипервизор KVM
Он дает возможность осуществлять виртуализацию на серверах с операционной системой Linux. Однозначным плюсом является то, что данный гипервизор входит в состав ядра Linux, поэтому он постоянно совершенствуется и обновляется. Использовать его можно только в случае аппаратной виртуализации – с помощью процессоров Intel или Amd. Процессорный модуль KVM дает ему возможность осуществлять доступ непосредственно к ядру. Благодаря этому можно напрямую управлять файлами виртуальных машин и образами дисков. Для каждой ВМ предназначено индивидуальное пространство.
Гипервизор Xen
Впервые разработанный еще Кэмбриджскими студентами, данный проект быстро стал коммерческим благодаря своей перспективности. Кроссплатформенность и широкий функционал Xen делает его возможности достаточно обширными для применения в офисах крупных компаний и корпораций. Его ядро обладает режимом паравиртуализации, то есть его можно настроить на одновременное взаимодействие с гипервизором.
Код этого гипервизора не перегружен лишними функциями. Он оснащен возможностями управления ОЗУ, частотой работы процессора, работы c прямым доступом к памяти, а также таймером. Все остальные функции выполняют подключенные к работе в данный момент ВМ. Перечисленные преимущества делают работу с Xen простой и удобной даже для человека, познания которого не очень глубоки в данной сфере.
Исследование
Для того, чтобы сравнить два гипервизора, нужно провести их тестирование. Для этого были взяты два сервера с абсолютно идентичным железом и ПО, за исключением, конечно же, рассматриваемых гипервизоров. Все настройки для созданных виртуальных машин были выставлены по умолчанию в соответствии с базовыми настройками обоих гипервизоров. Каждому варианту было выделено одинаковое количество памяти.
Уточним, что мнения о том, что выбранный нами дистрибутив для ОС – Fedora 20 от Red Hat – лучше подходит для KVM не совсем верны. Мы не рассматриваем борьбу ВМ за ресурсы процессора во время одновременной работы, так как при разной степени конкуренции гипервизоры могут показывать разную производительность. Поэтому мы считаем условия соревнования честными для обеих сторон.
Результаты
Тестирование основывалось на замере результатов тестов для ВМ, расположенных на одном только железе, исключая программное обеспечение. Отклонение в производительности двух серверов без виртуализации получилось меньше половины процента.
Первый кандидат – KVM показал производительность в среднем на полтора процента ниже производительности железа. В тесте на 7-ZIP данный гипервизор оказался почти на 3 процента медленнее, а в тесте на PostMark на целых 4 с лишним процента быстрее железа. Результаты Xen оказались хуже, он не превзошел своего конкурента ни в одном из тестов, отстав от железа на 2.5 процента в трех тестах, а в остальных показал себя еще хуже. Самое сильное отклонение выявилось, как и у KVM – в тесте на PostMark, но Xen не обогнал железо, как его конкурент, а отстал практически на 15 процентов. Повторные результаты теста отклонились от предыдущих не более, чем на 2 процента. Более подробно с результатами тестирования вы можете ознакомиться в таблице:
Итог
KVM всегда показывал себя медленнее железа примерно на 2 процента, но не более того. Xen же уступал железу на 2.5-7 процентов в большинстве из тестов. Хорошие результаты KVM в тесте на PostMark могут быть не совсем точными про причине недостаточного количества проведенных тестов. Чтобы принять правильное решение в выборе теста гипервизора, изучите характер нагрузок своего сайта. При необходимости проведите больше тестов для получения более точных результатов.
Мы в Cloud4Y считаем лидирующим решением для виртуализации продукты VmWare. Тем не менее, мы интересуемся и другими решениями, в том числе, Xen и KVM. И вот что мы заметили: существует не так уж много информации, позволяющей сравнить эти гипервизоры: последние дельные исследования, которые мы нашли в сети, относятся к 2012 году и, конечно, уже не могут считаться актуальными. Сегодня мы представим вашему вниманию тоже не самое новое, но, на наш взгляд, достаточно полезное исследование, посвященное производительности гипервизоров KVM и Xen.
Гипервизор KVM
Да простят нас гуру виртуализации, но для начала мы напомним читателям, что такое гипервизор и для чего он нужен. Для выполнения разных по смыслу задач (разработки программного обеспечения, хостинга и т. п.) проще всего использовать виртуальные машины: они позволят иметь несколько разных ОС с соответствующей программной средой. Для простоты работы с виртуальными машинами применяются гипервизоры — программные средства, позволяющие быстро развертывать, останавливать и запускать ВМ. KVM является одним из наиболее широко распространенных гипервизоров.
KVM — это ПО, позволяющее организовывать виртуализацию на основе ПК под управлением ОС Linux и похожих. С недавнего времени KVM считается составляющей Linux-ядра и развивается параллельно ему. Этот гипервизор может использоваться только в системах, где виртуализация поддерживается аппаратно — с помощью процессоров Intel и AMD.
В процессе работы KVM осуществляет доступ к ядру напрямую посредством процессор-специфичного модуля (kvm-intel или kvm-amd). К тому же, в состав комплекса включено основное ядро — kvm.ko и элементы UI, включая широко распространенный QEMU. KVM дает возможность напрямую работать с файлами ВМ и дисковыми образами. Каждая виртуальная машина обеспечивается своим изолированным пространством.
Гипервизор Xen
Изначально студентами Кембриджа был запущен проект, который в итоге стал коммерческой версией Xen. Первый релиз датирован 2003 годом, а в 2007 исходный код выкупила компания Citrix. Xen — это кроссплатформенный гипервизор с большим функционалом и огромными возможностями, что дает возможность применять его в корпоративной сфере. Xen поддерживает паравиртуализацию — особый режим ядра операционной системы, когда ядро настроено на одновременную работу с гипервизором.
В код Xen добавлен только необходимый комплект функций: управление виртуальной памятью и тактовой частотой процессора, работа с DMA, таймером реального времени и прерываниями. Остальной функционал вынесен в домены, то есть в работающие в это время виртуальные машины. Таким образом, Xen — самый легкий гипервизор.
Суть исследования
Тестирование основано на использовании двух серверов SuperMicro, у каждого из которых четырехядерный процессор Intel Xeon E3-1220 с тактовой частотой 3,10 Гц, 24GB Kingston DDR3 RAM и четырьмя драйверами Western Digital RE-3 160GB (RAID 10). Версии BIOS идентичны.
Для хостинга и виртуальных машин мы взяли Fedora 20 (с SELinux). Вот взятые нами версии ПО:
- Kernel: 3.14.8
- Для KVM: qemu-kvm 1.6.2
- Для Xen: xen 4.3.2
Пояснения
Кто-то из вас может начать возмущаться — мол, владелец Fedora 20, Red Hat, тратит значительное количество усилий на поддержку именно KVM. Уточним: Red Hat не делали значительных продвижений по части Xen долгие годы.
Кроме того, конкуренция между гипервизорами жестко контролируется и сведена к минимуму. На большинстве виртуальных серверов у вас будет несколько виртуальных машин, борющихся за время процессора, устройства ввода/вывода и доступ к сети. Наше тестирование не принимает это во внимание. Один гипервизор может иметь низкую производительность при низкой конкуренции за ресурсы, а затем показать куда большую эффективность, чем конкуренты, когда борьба за ресурсы выше.
Исследование проводилось на процессорах Intel, поэтому его результаты могут отличаться для AMD и ARM.
Результаты
Тесты для виртуальных машин, установленных непосредственно на «железо», то есть, без операционной системы (далее — «железо»), послужили основой для тестирования виртуальных машин. Отклонение в производительности между двумя серверами без виртуализации составило 0.51% или менее.
Производительность KVM упала в пределах 1,5% по сравнению с «железом» практически во всех тестах. Только два теста показали иной результат: один из них — тест 7-Zip , где KVM показал себя на 2,79% медленнее, чем «железо». Странно, что KVM был на 4,11% быстрее в тесте PostMark (который симулировал сильно загруженный почтовый сервер). Производительность Xen сильнее отличалась от производительности «железа», чем в ситуации с KVM. В трех тестах Xen отличался на 2,5% от скорости «железа», в остальных тестах он оказался еще медленнее.
В тесте PostMark Xen был медленнее на 14.41%, чем «железо». При перезапуске результаты теста отличались от первоначальных на 2%. Лучший тест для KVM, MAFFT, оказался вторым в списке худших для Xen.
Вот краткий итог тестирования:
| Best Value | Bare Metal | KVM | Xen | |
|---|---|---|---|---|
| Timed MAFFT Alignment | lower | 7.78 | 7.795 | 8.42 |
| Smallpt | lower | 160 | 162 | 167.5 |
| POV-Ray | lower | 230.02 | 232.44 | 235.89 |
| PostMark | higher | 3667 | 3824 | 3205 |
| OpenSSL | higher | 397.68 | 393.95 | 388.25 |
| John the Ripper (MD5) | higher | 49548 | 48899.5 | 46653.5 |
| John the Ripper (DES) | higher | 7374833.5 | 7271833.5 | 6911167 |
| John the Ripper (Blowfish) | higher | 3026 | 2991.5 | 2856 |
| CLOMP | higher | 3.3 | 3.285 | 3.125 |
| C-Ray | lower | 35.35 | 35.66 | 36.13 |
| 7-Zip | higher | 12467.5 | 12129.5 | 11879 |
Если вы хотите увидеть результаты полностью, пройдите по ссылке .
Вместо заключения
В нашем тестировании KVM был почти всегда на 2% медленнее, чем «железо». Xen оказался на 2,5% медленнее в трех тестах из десяти, а в остальных и того хуже: на 5-7%. Хотя KVM показал себя с лучшей стороны в тесте PostMark, следует отметить, что мы провели всего один I/O тест, и для получения более достоверной картины стоит провести еще несколько.
Для выбора правильного гипервизора необходимо правильно оценить характер своих нагрузок. Если ваши нагрузки предполагают меньший объем для процессора и больший для I/O, то можно провести больше I/O тестов. Если же вы работаете, в основном, с аудио и видео, попробуйте тесты x264 или mp3.
Как справедливо заметил mister_fog , в 2007 Citrix выкупила не исходный код Xen, а компанию XenSource, которая была основана разработчиками Xen и занималась коммерческим развитием этого открытого проекта. .
