Використовуємо KVM для створення віртуальних машин на сервері. RedHat остаточно перемикається з Xen на KVM Системи віртуалізації kvm

При виборі тарифу людина вибирає також і спосіб віртуалізації для сервера. Пропонуємо на вибір віртуалізації на рівні операційної системи 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. Після перенесення та перевірки старий сервер можна видалити (Віртуальні сервери → Видалити).

Перевірка підтримки гіпервізора

Перевіряємо, що сервер підтримує технології віртуалізації:

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

Днями вийшов цікавий звіт компанії Principled Technologies, що спеціалізується, зокрема, на різноманітних тестуванні апаратно-програмних середовищ. У документі " " розповідається про те, що на тому самому обладнанні за допомогою гіпервізора ESXi можна запустити більше віртуальних машин, ніж на гіпервізорі KVM платформи RHEV.

Зрозуміло, що дослідження ангажоване (хоча б, якщо подивитися на заголовок), але оскільки таких документів не так багато, ми вирішили звернути на нього увагу.

Для тестування використовувався стійковий сервер Lenovo x3650 M5, на якому у віртуальних машинах працювала СУБД Microsoft SQL Server 2016 із навантаженням типу OLTP. Як основний показник продуктивності використовувався OPM (orders per minute), що відображає кількісну оцінку виконаних транзакцій.

Якщо не використовувати техніки Memory Overcommit, результат виконання на 15 віртуальних машинах одного хоста в числі OPM приблизно однаковий на обох гіпервізорах:

А ось коли відбувається збільшення числа віртуальних машин, то vSphere показує себе значно краще.

Хрестиками відзначені машини, які на RHV просто не запустилися, консоль продукту видала таку помилку:

Незважаючи на включення техніки оптимізації пам'яті в Red Hat Virtualization Manager (RHV-M), таких як memory ballooning і kernel shared memory, шістнадцята віртуальна машина все одно відмовлялася запускатися на KVM:

Ну а на vSphere продовжували нарощувати число ВМ, поки не вперлися в нестачу ресурсів:

Вийшло, що з техніками overcommit на vSphere вдалося запустити 24 віртуальних машини, а на RHV - всього 15 штук. За підсумками зробили висновок, що на VMware vSphere в 1,6 рази можна запустити більше віртуальних машин:

Не сказати, що це об'єктивне тестування, але очевидно, що ESXi в даному випадку працює краще за KVM з точки зору будь-яких оптимізації пам'яті та інших ресурсів ВМ.

Таги: Red Hat, VMware, Performance, RHV, vSphere, ESXi, KVM
Таги: KVM, oVirt, Open Source, Update

Нагадаємо, що RHEV заснована на гіпервізорі Kernel-based Virtual Machine (KVM) та підтримує відкриту хмарну архітектуру OpenStack. Давайте подивимося, що з'явилося в оновленому RHEV версії 3.4.

Інфраструктура

Сервіс налаштування SNMP для підтримки систем моніторингу.
Збереження налаштувань хмарної інсталяції RHEV для можливості її відновлення при збої або цілей тиражування в інших хмарах.
Переписано та покращено сервіси аутентифікації RHEV.
Можливість гарячого додавання процесора до ВМ (Hot Plug CPU). Тут потрібна підтримка з боку ОС.
Нерутові користувачі тепер мають доступ до логів.
Новий інсталятор, заснований на TUI (textual user interface).
Підтримка IPv6.
Можливість вибору з'єднання з консоллю ВМ у режимі Native Client або noVNC.
Можливість зміни деяких налаштувань запущеної віртуальної машини.
Повна підтримка RHEL 7 як гостьова ОС.
Можливість увімкнення/вимкнення KSM (Kernel Samepage Merging) на рівні кластера.
Можливість перезавантаження ВМ із RHEVM або консольною командою.

Мережева взаємодія

Більш щільна інтеграція з інфраструктурою OpenStack:

Поліпшення безпеки та масштабованості для мереж, розгорнутих за допомогою Neutron.
Підтримка технології Open vSwitch (розширюваний віртуальний комутатор) та можливостей SDN-мереж.

Network Labels - мітки, які можна використовувати під час користування пристроями.
Коректний порядок нумерації віртуальних мережевих адаптерів (vNIC).
Підтримка iproute2.
Єдина точка конфігурації мережних налаштувань безлічі хостів у вказаній мережі.

Можливості сховищ

Змішані домени сховищ (mixed storage domains) – можливість одночасного використання дискових пристроїв із сховищ iSCSI, FCP, NFS, Posix та Gluster для організації зберігання віртуальних машин.
Multiple Storage Domains – можливість розподілити диски однієї віртуальної машини по кількох сховищах у межах датацентру.
Можливість вказівки дисків, які братимуть участь у створенні снапшотів, а також тих, що не будуть.
Покращено механізм відновлення ВМ із резервної копії - тепер є можливість вказати снапшот стану, в який хочеться відкотитися.
Асинхронне керування задачами Gluster-сховищ.
Read-Only Disk for Engine – ця функція дає засобу керування Red Hat Enterprise Virtualization Manager можливість використовувати диски лише для читання.
Доступ за кількома шляхами (multipathing) для сховищ iSCSI.

Засоби віртуалізації

Агенти гостьових ОС (ovirt-guest-agent) для OpenSUSE та Ubuntu.
SPICE Proxy – можливість використовувати проксі-сервери для доступу користувачів до своїх ВМ (якщо вони, наприклад, знаходяться за межами інфраструктурної мережі).
SSO (Single Sign-On) Method Control - можливість перемикатися між різними механізмами наскрізної автентифікації. Поки що є лише два варіанти: guest agent SSO і без SSO.
Підтримка кількох версій одного шаблону віртуальної машини.

Поліпшення планувальника та засобів забезпечення рівня обслуговування

Поліпшення планувальника віртуальних машин.
Групи Affinity/Anti-Affinity (правила існування віртуальних машин на хостах – розміщувати машини разом чи окремо).
Power-Off Capacity – політика електроживлення, що дозволяє вимкнути хост та підготувати його віртуальні машини до міграції в інше місце.
Even Virtual Machine Distribution – можливість розподілу віртуальних машин по хостах на базі кількості ВМ.
High-Availability Virtual Machine Reservation – механізм дозволяє гарантувати відновлення віртуальних машин у разі відмови одного або кількох хост-серверів. Він працює з урахуванням розрахунку доступної ємності обчислювальних ресурсів хостів кластера.

Поліпшення інтерфейсу

Фікси багів, що стосуються того, що інтерфейс не завжди реагував на події, що відбуваються в інфраструктурі.
Підтримка низьких роздільних здатностей екрана (коли не було видно деяких елементів консолі керування на низьких роздільностях).

Завантажити Red Hat Enterprise Virtualization 3.4 можна за цим посиланням. Документація доступна.

Теги: RHEV, Update, Linux, KVM, Red Hat

Нова версія ОС RHEL має безліч нових цікавих можливостей, серед яких чимало стосуються технологій віртуалізації. Деякі основні нові можливості RHEL 7:

Вбудована підтримка упакованих програм у форматі Docker.
Kernel patching utility Technology Preview – патчинг ядра без перезавантаження ОС.
Пряма і непряма інтеграція з Microsoft Active Directory докладніше описано .
Для розділів boot, root та user data дефолтною файловою системою тепер є XFS.
- Для XFS максимальний розмір файлової системи збільшено зі 100 ТБ до 500 ТБ.
- Для ext4 цей розмір збільшено з 16 до 50 ТБ.
Поліпшений процес встановлення ОС (новий візард).
Можливість керування серверами Linux із використанням Open Linux Management Infrastructure (OpenLMI).
Поліпшення файлових систем NFS та GFS2.
Нові можливості технології віртуалізації KVM.
Можливість виконувати RHEL 7 як гостьовий OS.
Поліпшення NetworkManager та нова утиліта командного рядка для виконання мережевих завдань NM-CLI.
Підтримка мережевих з'єднань Ethernet на швидкості до 40 Гбіт/с.
Підтримує бездротову технологію WiGig (IEEE 802.11ad) (на швидкості до 7 Гбіт/с).
Новий механізм Team Driver, який віртуально поєднує мережні пристрої та порти в єдиний інтерфейс на рівні L2.
Новий динамічний сервіс FirewallD, що є гнучкий мережевий екран, що має перевагу перед iptables і підтримує кілька трастових зон (network trust zones).
GNOME 3 у режимі класичного робочого столу.

Докладніше про нові можливості RHEL 7 розказано Red Hat.

У плані віртуалізації Red Hat Enterprise Linux 7 з'явилися такі основні нововведення:

Технологічне превью можливості virtio-blk-data-plane, яка дозволяє виконувати команди вводу-виводу QEMU в окремому оптимізованому потоці.
З'явилося технологічне прев'ю технології PCI Bridge, що дозволяє підтримувати більш ніж 32 PCI пристрої в QEMU.
QEMU Sandboxing – покращена ізоляція між гостьовими ОС хоста RHEL 7.
Підтримка гарячого додавання віртуальних процесорів машинам (vCPU Hot Add).
Multiple Queue NICs – кожен vCPU має власні черги на передачу та отримання, що дозволяє не задіяти інші vCPU (тільки для гостьових ОС Linux).
Технологія стиснення сторінок пам'яті при гарячій міграції дозволяє гіпервізору KVM проводити міграцію швидше.
У KVM з'явилися функції підтримки паравіртуалізованих функцій ОС Microsoft, наприклад Memory Management Unit (MMU) і Virtual Interrupt Controller. Це дозволяє гостьовим ОС Windows працювати швидше (за замовчуванням ці функції вимкнено).
Підтримка технології EOI Acceleration, заснованої на інтерфейсі Advanced Programmable Interrupt Controller (APIC) від Intel та AMD.
Технологічне превью підтримки USB 3.0 у гостьових ОС на KVM.
Підтримка гостьових ОС Windows 8, Windows 8.1, Windows Server 2012 та Windows Server 2012 R2 на гіпервізорі KVM.
Функції I/O Throttling для гостьових ОС QEMU.
Підтримка технологій Ballooning та transparent huge pages.
Новий пристрій virtio-rng доступний як генератор випадкових чисел для гостьових ОС.
Підтримка гарячої міграції гостьових ОС з хоста Red Hat Enterprise Linux 6.5 на Red Hat Enterprise Linux 7.
Підтримка призначення пристроїв NVIDIA GRID і Quadro як другого пристрою на додаток до емульованого VGA.
Технологія Para-Virtualized Ticketlocks, що покращує продуктивність, коли віртуальних vCPU більше ніж фізичних на хості.
Покращена обробка помилок пристроїв PCIe.
Новий драйвер Virtual Function I/O (VFIO) покращує безпеку.
Підтримка технології Intel VT-d Large Pages, коли використовується драйвер VFIO.
Поліпшення віддачі точного часу віртуальним машинам KVM.
Підтримка образів QCOW2 version 3.
Покращені статистики Live Migration - total time, expected downtime і bandwidth.
Виділений потік для Live Migration, що дає змогу гарячій міграції не впливати на продуктивність гостьових ОС.
Емуляція процесорів AMD Opteron G5.
Підтримує нові інструкції процесорів Intel для гостьових ОС на KVM.
Підтримка форматів віртуальних дисків VPC та VHDX у режимі "тільки для читання".
Нові можливості утиліти libguestfs до роботи з віртуальними дисками машин.
Нові драйвери Windows Hardware Quality Labs (WHQL) для гостьових Windows.
Інтеграція з VMware vSphere: Open VM Tools, драйвери 3D-графіки для OpenGL та X11, а також покращений механізм комунікації між гостьовою ОС та гіпервізором ESXi.

Release Notes нової версії ОС доступні за цим посиланням. Про функції віртуалізації в новому релізі RHEL 7 можна почитати (а – російською). Вихідні коди rpm-пакетів Red Hat Enterprise Linux 7 тепер доступні лише через Git-репозиторій.

Таги: Linux, QEMU, KVM, Update, RHEL, Red Hat

Компанія Ravello знайшла цікавий спосіб використовувати вкладену віртуалізацію у своєму продукті Cloud Application Hypervisor, який дозволяє універсалізувати розгортання ВМ різних платформ віртуалізації в публічних хмарах різних провайдерів.

Основним компонентом цієї системи є технологія HVX - власний гіпервізор (на базі Xen), що є частиною ОС Linux і запускає вкладені віртуальні машини без зміни засобів технік бінарної трансляції. Далі ці машини можна розмістити в хмарах Amazon EC2, HP Cloud, Rackspace і навіть приватних хмарах, які керує VMware vCloud Director (підтримка останнього очікується незабаром).

Продукт Ravello - це SaaS-сервіс, а такі матрьошки можна просто завантажувати на будь-який з хостингів, що підтримуються, незалежно від використовуваного ним гіпервізора. Віртуальна мережа між машинами створюється через L2-оверлей над існуючою L3-інфраструктурою хостера з використанням GRE-подібного протоколу (тільки на базі UDP):

Сама механіка пропонованого сервісу Cloud Application Hypervisor така:

Користувач завантажує віртуальні машини у хмару (підтримуються машини, створені на платформах ESXi/KVM/Xen).
За допомогою спеціального GUI або засобами API описує багатомашинні програми.
Публікує свої ВМ в одному або кількох підтримуваних хмарах.
Конфігурація, що вийшла, зберігається у вигляді снапшота в хмарі Ravello (потім у разі чого її можна відновити або вивантажити) - це сховище може бути створене як на базі хмарних сховищ Amazon S3, CloudFiles, так і на базі власних блокових сховищ або NFS-томів.
Після цього кожен користувач може отримати багатомашинну конфігурацію своєї програми на вимогу.

Очевидне питання, яке постає першим: що з продуктивністю? Ну, по-перше, рішення Cloud Application Hypervisor розраховане на команди розробки та тестування, для яких продуктивність не є критичним фактором.

А по-друге, результати тестів продуктивності таких вкладених матрьошок показують не такі вже й погані результати:

Для тих, хто зацікавився технологією HVX, є гарне оглядове відео на рунгліше:

Таги: Rovello, Nested Virtualization, Cloud, HVX, VMware, ESXi, KVM, Xen, VMachines, Amazon, Rackspace

Нова версія відкритої платформи віртуалізації RHEV 3.0 заснована на дистрибутиві Red Ha Enterprise Linux версії 6 і традиційно гіпервізорі KVM.

Нові можливості Red Hat Enterprise Virtualization 3.0:

Засіб керування Red Hat Enterprise Virtualization Manager тепер побудований на базі Java, запущеної на платформі JBoss (раніше використовувався .NET, і, відповідно, була прив'язка до Windows, тепер можна використовувати Linux для керуючого сервера).
Портал самообслуговування користувачів, що дозволяє їм самостійно розгортати віртуальні машини, створювати шаблони та адмініструвати власні оточення.
Новий RESTful API, що дозволяє отримати доступ до всіх компонентів рішення зі сторонніх програм.
Розширений механізм адміністрування, що надає можливість гранульованого призначення пермісій, делегування повноважень на базі ролей користувачів та ієрархічне керування привілеями.
Підтримка локальних дисків серверів як сховища віртуальних машин (але для них не підтримується Live Migration).
Інтегрований механізм звітності, що дозволяє аналізувати історичні дані про продуктивність та будувати прогнози щодо розвитку віртуальної інфраструктури.
Оптимізація для WAN-з'єднань, включаючи технології dynamic compression (стиснення картинки) та автоматичне налаштування ефектів робочого столу та глибини кольоровості. Крім того, нова версія SPICE має розширену підтримку десктопів із гостьовими ОС Linux.
Оновлений гіпервізор KVM на основі останнього Red Hat Enterprise Linux 6.1, що вийшов у травні 2011 року.
Підтримка до 160 логічних CPU та 2 ТБ пам'яті для хост-серверів, 64 vCPU та 512 ГБ пам'яті – для віртуальних машин.
Нові можливості для адміністрування великих інсталяцій RHEV 3.0.
Підтримка великих сторінок пам'яті (Transparant Huge Pages, 2 МБ замість 4 КБ) у гостьових ОС, що збільшує продуктивність завдяки меншій кількості читань.
Оптимізація компонента vhost-net. Тепер мережевий стек KVM переміщений з режиму користувача в режим ядра, що істотно збільшує продуктивність і зменшує затримки в мережі.
Використання функцій бібліотеки sVirt, що забезпечує безпеку гіпервізора.
З'явився паравіртуалізований контролер x2paic, який зменшує overhead на вміст ВМ (особливо ефективний для інтенсивних навантажень).
Технологія Async-IO для оптимізації введення-виведення та підвищення продуктивності.

Завантажити фінальний реліз Red Hat Enterprise Virtualization 3.0 можна за цим посиланням.

Ну і, насамкінець, невеликий відео-огляд Red Hat Enterprise Virtualization Manager 3.0 (RHEV-M):

Теги: Linux, Red Hat, Update, KVM, Linux

Молодці NetApp! Роман, чекаємо перекладу російською мовою)

Теги: Red Hat, KVM, NetApp, Storage, NFS

Продукт ConVirt 2.0 Open Source дозволяє керувати гіпервізорами Xen і KVM, що входять у безкоштовні та комерційні видання дистрибутивів Linux, розгортати віртуальні сервери із шаблонів, здійснювати моніторинг продуктивності, автоматизувати завдання адміністратора та налаштовувати всі аспекти віртуальної інфраструктури. ConVirt 2.0 підтримує функції гарячої міграції віртуальних машин, "тонкі" віртуальні диски (зростають у міру наповнення даними), контроль ресурсів віртуальних машин (в т.ч. запущених), великі функції моніторингу та засоби інтелектуального розміщення віртуальних машин на хост-серверах (ручна балансування навантаження).

ConVirt 2.0 поки існує тільки у виданні Open Source, проте розробники обіцяють незабаром випустити видання ConVirt 2.0 Enteprise, яке відрізнятиметься від безкоштовного такими можливостями:

Feature	ConVirt 2.0 Open Source	ConVirt 2.0 Enterprise
Архітектура
Multi-platform Support
Agent-less Architecture
Universal Web Access
Datacenter-wide Console
Administration
Start, Stop, Pause, Resume
Maintanence Mode
Snapshot
Change Resource Allocation on Running VM
Monitoring
Real-time Data
Historical Information
Server Pools
Storage Pools
Alerts and Notifications
Provisioning
Templates-based Provisioning
Template Library
Integrated Virtual Appliance Catalogues
Thin Provisioning
Scheduled Provisioning
Automation
Intelligent Virtual Machine Placement
Live Migration
Host Private Networking
SAN, NAS Storage Support
Advanced Automation
High Availability
Backup and Recovery
VLAN Setup
Storage Automation
Dynamic Resource Allocation
Power Saving Mode
Security
SSH Access
Multi-user Administration
Auditing
Fine Grained Access Control
Integration
Open Repository
Command Line Interface
Programmatic API

Таги: Xen, KVM, Convirt, Citrix, Red Hat, Безкоштовно, Open Source,

Компанія Convirture, що займалася в 2007 році проектом XenMan, що являла собою GUI для управління гіпервізором XEN, випустила нещодавно реліз безкоштовногопродукту Convirture ConVirt 1.0, який змінив свою назву XenMan.

За допомогою ConVirt можна керувати гіпервізорами Xen та KVM, використовуючи такі можливості:

Управління кількома хост-серверами.
Снапшоти (snapshots).
Гаряча міграція віртуальних машин між хостами (Live Migration).
Резервне копіювання ВМ.
Найпростіший моніторинг хостів та віртуальних машин.
Підтримка віртуальних модулів (Virtual Appliances).

Завантажити Convirture ConVirt 1.0 можна за цим посиланням:

Convirture ConVirt 1.0
Таги: Xen, KVM

В 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 працюватиме без проблем.

Якщо ж на виході отримали повідомлення:

Ваші CPU не підтримуються 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 є вузьким місцем віртуальної машини, тому при створенні високонавантаженої системи до цього питання потрібно поставитися максимально відповідально.

Цю нотатку я пишу для того, щоб продемонструвати покрокову установку та налаштування віртуальної машини в 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. Ви можете reconnect to 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 не

То правимо конфіг на

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.