Эту заметку я пишу для того, чтобы продемонстрировать пошаговую установку и настройку виртуальной машины в Linux на базе KVM. Ранее я уже писал про виртуализацию, где использовал замечательный .
Сейчас передо мной встал вопрос аренды хорошего сервера с большим объёмом оперативной памяти и объёмным жестким диском. Но запускать проекты прямо на хост-машине не хочется, поэтому буду разграничивать их по отдельным небольшим виртуальным серверам с ОС Linux или docker-контейнерам (о них расскажу в другой статье).
Все современные облачные хостинги работают по такому же принципу, т.е. хостер на хорошем железе поднимает кучу виртуальных серверов, которые мы привыкли называть VPS/VDS, и раздаёт их пользователям, либо автоматизирует этот процесс (привет, DigitalOcean).
KVM (kernel-based virtual machine) это программное обеспечения для Linux, использующее аппаратные средства x86-совместимых процессоров для работы с технологией виртуализации Intel VT/AMD SVM.
Установка KVM
Все махинации по созданию виртуальной машины я буду проводить на ОС Ubuntu 16.04.1 LTS. Чтобы проверить поддерживает ли ваш процессов аппаратную виртуализацию на базе Intel VT/AMD SVM, выполняем:
Grep -E "(vmx|svm)" /proc/cpuinfo
Если терминал непустой, то значит всё в порядке и KVM можно устанавливать. Ubuntu официально поддерживает только гипервизор KVM (входит в состав ядра Linux) и советует использовать библиотеку libvirt в качестве инструмента по управлению им, что мы и будем делать дальше.
Проверить поддержку аппаратной виртуализации в Ubuntu также можно через команду:
В случае успеха, вы увидите что-то вроде этого:
INFO: /dev/kvm exists KVM acceleration can be used
Устанавливаем пакеты для работы с KVM:
Sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Если у вас есть доступ к графической оболочке системы, то можно установить GUI менеджер libvirt:
Sudo apt-get install virt-manager
Пользоваться virt-manager достаточно просто (не сложнее VirtualBox), поэтому в этой заметке речь пойдёт про консольный вариант установки и настройки виртуального сервера.
Установка и настройка виртуального сервера
В консольном варианте установки, настройки и управлением системой, незаменимым инструментом является утилита virsh (надстройка над библиотекой libvirt). У неё большое количество опций и параметров, подробное описание можно получить так:
Man virsh
или вызвать стандартный "help":
Virsh help
Я всегда придерживаюсь следующих правил при работе с виртуальными серверами:
- Храню iso образы ОС в каталоге /var/lib/libvirt/boot
- Храню образы виртуальных машин в каталоге /var/lib/libvirt/images
- Явно задаю каждой новой виртуальной машине свой статичный IP адрес через DHCP сервер гипервизора.
Приступим к установке первой виртуалки (64-битной серверной убунте 16.04 LTS):
Cd /var/lib/libvirt/boot sudo wget http://releases.ubuntu.com/16.04/ubuntu-16.04.1-desktop-amd64.iso
Скачав образ запускаем установку:
Sudo virt-install \ --virt-type=kvm \ --name ubuntu1604\ --ram 1024 \ --vcpus=1 \ --os-variant=ubuntu16.04 \ --hvm \ --cdrom=/var/lib/libvirt/boot/ubuntu-16.04.1-server-amd64.iso \ --network network=default,model=virtio \ --graphics vnc \ --disk path=/var/lib/libvirt/images/ubuntu1604.img,size=20,bus=virtio
Переводя все эти параметры на "человеческий язык", то получается, что мы создаём виртуальную машину с ОС Ubuntu 16.04, 1024 МБ ОЗУ, 1 процессором, стандартной сетевой картой (виртуальная машина будет ходить в интернет как-будто из-за NAT), 20 ГБ HDD.
Стоит обратить внимание на параметр --os-variant
, он указывает гипервизору под какую именно ОС следует адаптировать настройки.
Список доступных вариантов ОС можно получить, выполнив команду:
Osinfo-query os
Если такой утилиты нет в вашей системе, то устанавливаем:
Sudo apt-get install libosinfo-bin
После запуска установки, в консоли появится вот такая надпись:
Domain installation still in progress. You can reconnect to the console to complete the installation process.
Это нормальная ситуация, продолжать установку мы будем через VNC.
Смотрим на каком порту он был поднят у нашей виртуалки (в соседнем терминале, например):
Virsh dumpxml ubuntu1604
...
Порт 5900, на локальном адресе 127.0.0.1. Чтобы подключиться к VNC, необходимо использовать Port Forwarding через ssh. Перед тем как это сделать, убедитесь, что tcp forwarding разрешён у демона ssh. Для этого идём в настройки sshd:
Cat /etc/ssh/sshd_config | grep AllowTcpForwarding
Если ничего не нашлось или вы видите:
AllowTcpForwarding no
То правим конфиг на
AllowTcpForwarding yes
и перезагружаем sshd.
Настройка Port forwarding
Выполняем команду на локальной машине:
Ssh -fN -l login -L 127.0.0.1:5900:localhost:5900 server_ip
Здесь мы настроили ssh port forwarding с локального порта 5900 на серверный порт 5900. Теперь уже можно подключиться к VNC, используя любой VNC-клиент. Я предпочитаю UltraVNC из-за простоты и удобства.
После успешного подключения, на экране отобразится стандартное окно приветствия начала установки Ubuntu:
После завершения установки и привычной перезагрузки, появится окно входа в систему. Авторизовавшись, определяем IP адрес новоиспечённой виртуалки, чтобы позже сделать его статичным:
Ifconfig
Запоминаем и идём на хост машину. Вытаскиваем mac-адрес "сетевой" карты виртуалки:
Virsh dumpxml ubuntu1604 | grep "mac address"
Запоминаем наш mac адрес:
Редактируем сетевые настройки гипервизора:
Sudo virsh net-edit default
Ищем DHCP, и добавляем вот это:
Должно получиться что-то вроде этого:
Для того, чтобы настройки вступили в силу, необходимо перезагрузить DHCP сервер гипервизора:
Sudo virsh net-destroy default sudo virsh net-start default sudo service libvirt-bin restart
После этого перегружаем виртуальную машину, теперь она всегда будет иметь заданный ей IP адрес - 192.168.122.131.
Есть и другие способы задать виртуалке статичный IP, например, напрямую редактируя сетевые настройки внутри гостевой системы, но тут уже как душе вашей будет угодно. Я лишь показал вариант, который сам предпочитаю использовать.
Чтобы подключиться к терминалу виртуальной машины, выполняем:
Ssh 192.168.122.131
Машина готова к бою.
Virsh: список команд
Чтобы посмотреть запущенные виртуальные хосты (все доступные можно получить добавив --all):
Sudo virsh list
Перезагрузить хост можно:
Sudo virsh reboot $VM_NAME
Остановить виртуальную машину:
Sudo virsh stop $VM_NAME
Выполнить halt:
Sudo virsh destroy $VM_NAME
Sudo virsh start $VM_NAME
Отключение:
Sudo virsh shutdown $VM_NAME
Добавить в автозапуск:
Sudo virsh autostart $VM_NAME
Очень часто требуется склонировать систему, чтобы в будущем использовать её как каркас для других виртуальных ОС, для этого используют утилиту virt-clone.
Virt-clone --help
Она клонирует существующую виртуалку и изменяет host-sensitive данные, например, mac address. Пароли, файлы и прочая user-specific информация в клоне остаётся прежней. Если на клонируемой виртуалке IP адрес был прописан вручную, то могут возникнуть проблемы с доступом по SSH на клон из-за конфликта (2 хоста с одинаковым IP).
Помимо установки виртуалки через VNC, также возможен вариант с X11Forwarding через утилиту virt-manager. В Windows, например, для этого можно использовать Xming и PuTTY.
При выборе тарифа, человек выбирает также и способ виртуализации для сервера. Предлагаем на выбор виртуализации на уровне операционной системы OpenVZ и аппаратную виртуализацию KVM.
Сменить тип виртуализации после запуска невозможно, поскольку серверы находятся на разных аппаратных платформах. Вам придётся заказать новый сервер, перенести проект и отказаться от старого сервера.
Сравнение типов виртуализаций
| OpenVZ | KVM |
| ОС из ряда предложенных: Debian, CentOS, Ubuntu | Linux, Windows, FreeBSD, установка собственного дистрибутива |
| Изменение ресурсов без перезагрузки (жёсткий диск, память, процессор) | Память и процессор изменятся после перезагрузки, жёсткий диск - только после обращения в поддержку (на готовых тарифах память изменить нельзя) |
| Смена тарифного плана без перезагрузки | Смена тарифного плана . Сервер будет недоступен 1-2 часа. |
| Мягкие лимиты: максимальная производительность сервера может отклоняться в большую или меньшую сторону | Жёсткие лимиты: каждый сервер получает заявленные ресурсы |
| Ограничение на запуск высоконагруженных проектов. Запрещено запускать Java-приложения, массовые рассылки и проксировать трафик. TUN/TAP выключен. | Возможность запуска любых проектов (кроме систем распределённых вычислений) |
Виртуализация OpenVZ
OpenVZ - виртуализация уровня операционной системы. Технология базируется на ядре ОС Linux и позволяет на одном физическом сервере создавать и запускать изолированные друг от друга копии выбранной операционной системы (Debian, CentOS, Ubuntu). Установка другой ОС невозможна, так как виртуальные серверы используют общее ядро Linux.
Технология отличается легкостью управления сервером: пользователь может в личном кабинете самостоятельно добавить количество ресурсов (память, процессор, жесткий диск) или перейти на другой тариф с той же виртуализацией. Изменения ресурсов применяются автоматически, без перезагрузки сервера.
На серверах с виртуализацией OpenVZ запрещается запускать:
- сервисы для организации проксирования любого вида трафика
- сервисы потокового вещания
- игровые серверы
- системы или элементы систем распределённых вычислений (например, bitcoin mining)
- сервисы массовой рассылки почтовых сообщений, даже если они используются в легальных целях
- Java-приложения
- иные ресурсоёмкие приложения
Такие проекты создают неравномерную нагрузку на родительском сервере и могут мешать соседним виртуальным машинам.
Виртуализация KVM
KVM (Kernel-based Virtual Machine) - технология аппаратной виртуализации, позволяющая создать на хост-машине полный виртуальный аналог физического сервера . KVM позволяет создать полностью изолированный от «соседей» виртуальный сервер с собственным ядром ОС, который пользователь может настраивать и модифицировать под собственные нужды без ограничений. Каждому такому серверу выделяется своя область в оперативной памяти и пространство на жестком диске, что повышает общую надежность работы такого сервера.
Возможна установка любой операционной системы на выбор (Debian, CentOS, Ubuntu, FreeBSD, Windows Server), либо установка собственного дистрибутива (в панели VMmanager в разделе ISO-образы нажмите кнопку Создать и добавьте свой ISO-образ системы).
Смена тарифного плана возможна только в большую сторону и только в рамках базовой линейки тарифов (Старт, Разгон, Отрыв, Улёт). Если ваш проект «вырастет» из тарифа, напишите запрос в поддержку из Личного кабинета - администраторы сменят тариф на требуемый бесплатно. Изменить тариф в меньшую сторону можно только переносом на новый сервер. Закажите новый сервер и перенесите данные самостоятельно, либо специалисты технической поддержки помогут с переносом за 1 обращение по пакету администрирования или 250 руб.
Помните, что на тарифах VDS-Форсаж и VDS-Атлант , вы можете изменять ресурсы вместо смены тарифа : количество доступных ядер процессора и оперативной памяти самостоятельно в панели управления, а размер жёсткого диска - после обращения в поддержку (в рамках администрирования или за 250 руб.).
Учитывая особенности и преимущества, которые дает виртуализация KVM, ее тарифы стоят дороже аналогичных тарифов с виртуализацией OpenVZ.
На серверах с виртуализацией KVM Абоненту запрещается размещать системы или элементы систем распределённых вычислений (например, bitcoin mining ).
Смена виртуализации на сервере
В рамках одного сервера сменить виртуализацию с OpenVZ на KVM и обратно невозможно.
1. Закажите второй сервер с нужной виртуализацией в панели BILLmanager, раздел Виртуальные серверы → Заказать
2. Перенесите на него данные.
3. После переноса и проверки старый сервер можно удалить (Виртуальные серверы → Удалить).
Мне лично проще всего думать о KVM (Kernel-based Virtual Machine), как о таком уровне абстракции над технологиями хардверной виртуализации Intel VT-x и AMD-V. Берем машину с процессором, поддерживающим одну из этих технологий, ставим на эту машину Linux, в Linux’е устанавливаем KVM, в результате получаем возможность создавать виртуалки. Так примерно и работают облачные хостинги, например, Amazon Web Services . Наряду с KVM иногда также используется и Xen, но обсуждение этой технологии уже выходит за рамки данного поста. В отличие от технологий контейнерной виртуализации, например, того же Docker , KVM позволяет запускать в качестве гостевой системы любую ОС, но при этом имеет и бо льшие накладные расходы на виртуализацию.
Примечание: Описанные ниже действия были проверены мной на Ubuntu Linux 14.04, но по идее будут во многом справедливы как для других версий Ubuntu, так и других дистрибутивов Linux. Все должно работать как на десктопе, так и на сервере, доступ к которому осуществляется по SSH.
Установка KVM
Проверяем, поддерживается ли Intel VT-x или AMD-V нашим процессором:
grep -E "(vmx|svm)" / proc/ cpuinfo
Если что-то нагреполось, значит поддерживается, и можно действовать дальше.
Устанавливаем KVM:
sudo
apt-get update
sudo
apt-get install
qemu-kvm libvirt-bin virtinst bridge-utils
Что где принято хранить:
- /var/lib/libvirt/boot/ — ISO-образы для установки гостевых систем;
- /var/lib/libvirt/images/ — образы жестких дисков гостевых систем;
- /var/log/libvirt/ — тут следует искать все логи;
- /etc/libvirt/ — каталог с файлами конфигурации;
Теперь, когда KVM установлен, создадим нашу первую виртуалку.
Создание первой виртуалки
В качестве гостевой системы я выбрал FreeBSD. Качаем ISO-образ системы:
cd
/
var/
lib/
libvirt/
boot/
sudo
wget
http://
ftp.freebsd.org/
path/
to/
some-freebsd-disk.iso
Управление виртуальными машинами в большинстве случаев производится при помощи утилиты virsh:
sudo virsh --help
Перед запуском виртуалки нам понадобится собрать кое-какие дополнительные сведения.
Смотрим список доступных сетей:
sudo virsh net-list
Просмотр информации о конкретной сети (с именем default):
sudo virsh net-info default
Смотрим список доступных оптимизаций для гостевых ОС:
sudo virt-install --os-variant list
Итак, теперь создаем виртуальную машину с 1 CPU, 1 Гб RAM и 32 Гб места на диске, подключенную к сети default:
sudo
virt-install \
--virt-type
=kvm \
--name
freebsd10 \
--ram
1024
\
--vcpus
=1
\
--os-variant
=freebsd8 \
--hvm
\
--cdrom
=/
var/
lib/
libvirt/
boot/
FreeBSD-10.2
-RELEASE-amd64-disc1.iso \
--network
network
=default,model
=virtio \
--graphics
vnc \
--disk
path
=/
var/
lib/
libvirt/
images/
freebsd10.img,size
=32
,bus
=virtio
Вы можете увидеть:
WARNING Unable to connect to graphical console: virt-viewer not
installed. Please install the "virt-viewer" package.
Domain installation still in progress. You can reconnect to the console
to complete the installation process.
Это нормально, так и должно быть.
Затем смотрим свойства виртуалки в формате XML:
sudo virsh dumpxml freebsd10
Тут приводится наиболее полная информация. В том числе есть, к примеру, и MAC-адрес, который понадобятся нам далее. Пока что находим информацию о VNC. В моем случае:
С помощью любимого клиента (я лично пользуюсь Rammina) заходим по VNC , при необходимости используя SSH port forwarding. Попадаем прямо в инстялятор FreeBSD. Дальше все как обычно — Next, Next, Next, получаем установленную систему.
Основные команды
Давайте теперь рассмотрим основные команды для работы с KVM.
Получение списка всех виртуалок:
sudo virsh list --all
Получение информации о конкретной виртуалке:
sudo virsh dominfo freebsd10
Запустить виртуалку:
sudo virsh start freebsd10
Остановить виртуалку:
sudo virsh shutdown freebsd10
Жестко прибить виртуалку (несмотря на название, это не удаление):
sudo virsh destroy freebsd10
Ребутнуть виртуалку:
sudo virsh reboot freebsd10
Склонировать виртуалку:
sudo
virt-clone -o
freebsd10 -n
freebsd10-clone \
--file
/
var/
lib/
libvirt/
images/
freebsd10-clone.img
Включить/выключить автозапуск:
sudo
virsh autostart freebsd10
sudo
virsh autostart --disable
freebsd10
Запуск virsh в диалоговом режиме (все команды в диалоговом режиме — как описано выше):
sudo virsh
Редактирование свойств виртуалки в XML, в том числе здесь можно изменить ограничение на количество памяти и тд:
sudo virsh edit freebsd10
Важно! Комментарии из отредактированного XML, к сожалению, удаляются.
Когда виртуалка остановлена, диск тоже можно ресайзить:
sudo
qemu-img resize /
var/
lib/
libvirt/
images/
freebsd10.img -2G
sudo
qemu-img info /
var/
lib/
libvirt/
images/
freebsd10.img
Важно! Вашей гостевой ОС, скорее всего, не понравится, что диск внезапно стал больше или меньше. В лучшем случае, она загрузится в аварийном режиме с предложением переразбить диск. Скорее всего, вы не должны хотеть так делать. Куда проще может оказаться завести новую виртуалку и смигрировать на нее все данные.
Резервное копирование и восстановление производятся довольно просто. Достаточно сохранить куда-то вывод dumpxml, а также образ диска, а потом восстановить их. На YouTube удалось найти видео с демонстрацией этого процесса, все и вправду несложно.
Настройки сети
Интересный вопрос — как определить, какой IP-адрес получила виртуалка после загрузки? В KVM это делается хитро. Я в итоге написал такой скрипт на Python :
#!/usr/bin/env python3
# virt-ip.py script
# (c) 2016 Aleksander Alekseev
# http://сайт/
import
sys
import
re
import
os
import
subprocess
from
xml
.etree
import
ElementTree
def
eprint(str
)
:
print
(str
,
file
=
sys
.stderr
)
if
len
(sys
.argv
)
<
2
:
eprint("USAGE: "
+ sys
.argv
[
0
]
+ "
eprint("Example: "
+ sys
.argv
[
0
]
+ " freebsd10"
)
sys
.exit
(1
)
if
os
.geteuid
()
!=
0
:
eprint("ERROR: you shold be root"
)
eprint("Hint: run `sudo "
+ sys
.argv
[
0
]
+ " ...`"
)
;
sys
.exit
(1
)
if
subprocess
.call
("which arping 2>&1 >/dev/null"
,
shell =
True
)
!=
0
:
eprint("ERROR: arping not found"
)
eprint("Hint: run `sudo apt-get install arping`"
)
sys
.exit
(1
)
Domain = sys .argv [ 1 ]
if
not
re
.match
("^*$"
,
domain)
:
eprint("ERROR: invalid characters in domain name"
)
sys
.exit
(1
)
Domout =
subprocess
.check_output
("virsh dumpxml "
+domain+" || true"
,
shell =
True
)
domout =
domout.decode
("utf-8"
)
.strip
()
if
domout ==
""
:
# error message already printed by dumpxml
sys
.exit
(1
)
Doc = ElementTree.fromstring (domout)
# 1. list all network interfaces
# 2. run `arping` on every interface in parallel
# 3. grep replies
cmd
=
"(ifconfig | cut -d " " -f 1 | grep -E "." | "
+ \
"xargs -P0 -I IFACE arping -i IFACE -c 1 {} 2>&1 | "
+ \
"grep "bytes from") || true"
for
child in
doc.iter
()
:
if
child.tag
==
"mac"
:
macaddr =
child.attrib
[
"address"
]
macout =
subprocess
.check_output
(cmd
.format
(macaddr)
,
shell =
True
)
print
(macout.decode
("utf-8"
)
)
Скрипт работает как с default сетью, так и с bridged сетью, настройку которой мы рассмотрим далее. Однако на практике куда удобнее настроить KVM так, чтобы он всегда назначал гостевым системам одни и те же IP-адреса. Для этого правим настройки сети:
sudo virsh net-edit default
… примерно таким образом:
После внесения этих правок
>
… и заменяем на что-то вроде:
>
Перезагружаем гостевую систему и проверяем, что она получила IP по DHCP от роутера. Если же вы хотите, чтобы гостевая система имела статический IP-адрес, это настраивается как обычно внутри самой гостевой системы.
Программа virt-manager
Вас также может заинтересовать программа virt-manager:
sudo
apt-get install
virt-manager
sudo
usermod -a
-G
libvirtd USERNAME
Так выглядит ее главное окно:
Как видите, virt-manager представляет собой не только GUI для виртуалок, запущенных локально. С его помощью можно управлять виртуальными машинами, работающими и на других хостах, а также смотреть на красивые графички в реальном времени. Я лично нахожу особенно удобным в virt-manager то, что не нужно искать по конфигам, на каком порту крутится VNC конкретной гостевой системы. Просто находишь виртуалку в списке, делаешь двойной клик, и получаешь доступ к монитору.
Еще при помощи virt-manager очень удобно делать вещи, которые иначе потребовали бы трудоемкого редактирования XML-файлов и в некоторых случаях выполнения дополнительных команд. Например, переименование виртуальных машин, настройку CPU affinity и подобные вещи. Кстати, использование CPU affinity существенно снижает эффект шумных соседей и влияние виртуальных машин на хост-систему. По возможности используйте его всегда.
Если вы решите использовать KVM в качестве замены VirtualBox, примите во внимание, что хардверную виртуализацию они между собой поделить не смогут. Чтобы KVM заработал у вас на десктопе, вам не только придется остановить все виртуалки в VirtualBox и Vagrant , но и перезагрузить систему. Я лично нахожу KVM намного удобнее VirtualBox, как минимум, потому что он не требует выполнять команду sudo / sbin/ rcvboxdrv setup после каждого обновления ядра, адекватно работает c Unity , и вообще позволяет спрятать все окошки.
Гипервизоры, виртуализация и облако
Анализ гипервизора KVM
Серия контента:
Об этом цикле статей
Этот цикл начинается с общих сведений о типах гипервизоров и виртуализации систем, а затем в нем рассматриваются особенности пяти гипервизоров, процессы их установки и проблемы управления, которые могут возникнуть.
Этот цикл статей можно использовать в качестве отправной точки для понимания роли гипервизора при виртуализации в облаке или для изучения отдельных статей, которые помогут вам определить, какой гипервизор наилучшим образом подходит для конкретных задач, решаемых в облаке.
Что нужно знать для начала
Kernel-based Virtual Machine (KVM) – это полное решение платформенно-зависимой виртуализации для Linux на процессорах x86 с расширениями виртуализации (Intel VT или AMD-V). Для гостевых систем доступна также ограниченная поддержка паравиртуализации для Linux и Windows в форме паравиртуального сетевого драйвера.
В настоящее время KVM взаимодействует с ядром через загружаемый модуль ядра. Поддерживаются разнообразные гостевые операционные системы, такие как Linux, BSD, Solaris, Windows, Haiku, ReactOS и AROS Research Operating System. Модифицированная версия KVM (qemu) может работать на Mac OS X.
Примечание: KVM не выполняет никакой самоэмуляции; вместо этого, программа, работающая в пользовательском пространстве, применяет интерфейс /dev/kvm для настройки адресного пространства гостевого виртуального сервера, берет его смоделированные ресурсы ввода/вывода и отображает его образ на образ хоста.
Архитектура KVM показана на рисунке 1.
Рисунок 1. Архитектура KVM
Паравиртуализация
Паравиртуализация ― это метод виртуализации, который предоставляет виртуальным машинам программный интерфейс, подобный, но не идентичный базовым аппаратным средствам. Задачей этого модифицированного интерфейса является сокращение времени, затрачиваемого гостевой операционной системой на выполнение операций, которые в виртуальной среде выполнить значительно труднее, чем в невиртуализированной.
Существуют специальные "крюки" (hooks), позволяющие гостевой и хозяйской системам запрашивать и подтверждать решение этих сложных задач, которые можно было бы выполнить и в виртуальной среде, но значительно медленнее.
В архитектуре KVM, виртуальная машина выполняется как обычный Linux-процесс, запланированный стандартным планировщиком Linux. На самом деле каждый виртуальный процессор представляется как обычный Linux-процесс. Это позволяет KVM пользоваться всеми возможностями ядра Linux.
Эмуляцией устройств управляет модифицированная версия qemu, которая обеспечивает эмуляцию BIOS, шины PCI, шины USB, а также стандартный набор устройств, таких как дисковые контроллеры IDE и SCSI, сетевые карты и т.д.
Функциональные возможности
Ниже перечислены основные функции KVM.
Безопасность
Поскольку виртуальная машина реализована как 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 допускает виртуализацию самых требовательных рабочих нагрузок.
Развертывание виртуализации
Развертывание 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/систем реального времени, масштабируемости виртуальных процессоров, совместимости между поставщиками, портативности ВМ, а также в создании экосистемы облачных сервисов.
В 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 является узким местом виртуальной машины, поэтому при создании высоконагруженной системы к этому вопросу нужно отнестись максимально ответственно.
