При выборе тарифа, человек выбирает также и способ виртуализации для сервера. Предлагаем на выбор виртуализации на уровне операционной системы OpenVZ и аппаратную виртуализацию KVM.
Сменить тип виртуализации после запуска невозможно, поскольку серверы находятся на разных аппаратных платформах. Вам придётся заказать новый сервер, перенести проект и отказаться от старого сервера.
Сравнение типов виртуализаций
| OpenVZ | KVM |
ОС из ряда предложенных: Debian, CentOS, Ubuntu | Linux, Windows, FreeBSD, установка собственного дистрибутива |
Изменение ресурсов без перезагрузки (жёсткий диск, память, процессор) | Память и процессор изменятся после перезагрузки, жёсткий диск - только после обращения в поддержку (на готовых тарифах память изменить нельзя) |
Смена тарифного плана без перезагрузки | Смена тарифного плана . Сервер будет недоступен 1-2 часа. |
Мягкие лимиты: максимальная производительность сервера может отклоняться в большую или меньшую сторону | Жёсткие лимиты: каждый сервер получает заявленные ресурсы |
Ограничение на запуск высоконагруженных проектов. Запрещено запускать Java-приложения, массовые рассылки и проксировать трафик. TUN/TAP выключен. | Возможность запуска любых проектов (кроме систем распределённых вычислений) |
Возможность . Для этого типа виртуализации подключение к графическому интерфейсу по VNC невозможно. | Возможность . Если сервер по каким-либо причинам недоступен по SSH или нужно подключиться к графическому интерфейсу, можно получить доступ к серверу по VNC. |
Перейти в панель управления ISPmanager можно:
|
Виртуализация OpenVZ
OpenVZ - виртуализация уровня операционной системы. Технология базируется на ядре ОС Linux и позволяет на одном физическом сервере создавать и запускать изолированные друг от друга копии выбранной операционной системы (Debian, CentOS, Ubuntu). Установка другой ОС невозможна, так как виртуальные серверы используют общее ядро Linux.
Технология отличается легкостью управления сервером : пользователь может в личном кабинете самостоятельно* добавить количество ресурсов (память, процессор, жесткий диск) или перейти на другой тариф с той же виртуализацией. Изменения применяются автоматически, без перезагрузки сервера.
На серверах с виртуализацией OpenVZ запрещается запускать:
- сервисы для организации проксирования любого вида трафика
- сервисы потокового вещания
- игровые серверы
- системы или элементы систем распределённых вычислений (например, bitcoin mining)
- сервисы массовой рассылки почтовых сообщений, даже если они используются в легальных целях
- Java-приложения
- иные ресурсоёмкие приложения
Такие проекты создают неравномерную нагрузку на родительском сервере и могут мешать соседним виртуальным машинам.
* - для прошлых версий тарифов (VDS-2015, VDS-Лето, VDS-2016) смена тарифа в личном кабинете больше не доступна. Самостоятельное изменение тарифного плана возможно только на актуальных тарифах виртуализации OVZ. Если для вас важно иметь доступ к быстрому управлению ресурсами сервера - для перехода на актуальный тарифный план. Если стоимость нового тарифа выше стоимости текущего, смена тарифа происходит бесплатно, в остальных случаях - в рамках . Тариф меняется без перезагрузки сервера.
Виртуализация 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 , и вообще позволяет спрятать все окошки.
В 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 является узким местом виртуальной машины, поэтому при создании высоконагруженной системы к этому вопросу нужно отнестись максимально ответственно.
Проверка поддержки гипервизора
Проверяем, что сервер поддерживает технологии виртуализации:
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
Мы в 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 и занималась коммерческим развитием этого открытого проекта. .
Похожие статьи
