1. 12.2.2.1. попередні кроки
2. 12.2.2.2. Мережеві налаштування
3. 12.2.2.3. установка системи
4. 12.2.2.4. запуск контейнера
5. 12.2.3. Віртуалізація за допомогою KVM
6. 12.2.3.1. попередні кроки
7. 12.2.3.2. Мережеві налаштування
8. 12.2.3.3. Установка за допомогою virt-install
9. 12.2.3.4. Управління машинами за допомогою virsh
10. 12.2.3.5. Установка RPM-системи в Debian за допомогою yum

Віртуалізація - це одне з найбільших досягнень обчислювальної техніки останніх років. Цей термін включає в себе різні абстракції і технології імітації віртуальних комп'ютерів з різним ступенем незалежності від реального обладнання. На одному фізичному сервері можуть розміщуватися декілька систем, що працюють одночасно і ізольованих один від одного. Додатків багато, і часто вони були б неможливі без такої ізоляції: наприклад, тестові оточення з різними конфігураціями або поділ сервісів по різним віртуальним машинам для безпеки.

Існує безліч рішень для віртуалізації, кожне зі своїми достоїнствами і недоліками. Ця книга сфокусується на Xen, LXC і KVM, але є й інші реалізації, гідні згадки:

Xen - це рішення для «паравіртуалізаціі». Воно вводить тонкий шар абстракції, званий «гіпервізором», між обладнанням і встановленими вище системами; він грає роль арбітра, який контролює доступ до обладнання з віртуальних машин. Однак він обробляє лише деякі інструкції, інші безпосередньо виконуються обладнанням від імені систем. Головна перевага полягає в тому, що продуктивність не потерпає, і системи працюють зі швидкістю, близькою до нативної; мінусом є те, що ядра операційних систем, які потрібно запускати на гіпервізора Xen, повинні бути адаптовані для цього.

Приділимо трохи часу термінології. Гипервизор є нижнім шаром, що виконуються безпосередньо на обладнанні, навіть нижче ядра. Гипервизор може розділяти інше програмне забезпечення з кількох доменах, які можуть виглядати як безліч віртуальних машин. Один з цих доменів (перший, який запускається) відомий як dom0 і має особливу роль, оскільки тільки цей домен може управляти гіпервізором і виконанням інших доменів. Ці інші домени відомі як domU. Іншими словами, з точки зору користувача dom0 відповідає «хосту» в інших системах віртуалізації, а domU - «гостю».

Щоб використовувати Xen в Debian, потрібні три компоненти:

• Сам гипервизор. Відповідно до доступним обладнанням пакет буде називатися xen-hypervisor-4.4-amd64, xen-hypervisor-4.4-armhf або xen-hypervisor-4.4-arm64.

• Ядро, що працює на цьому гіпервізора. Будь-яке ядро, новіше 3.0, включаючи версію 3.16 зі складу Jessie.

• Для архітектури i386 також потрібно стандартна бібліотека з латками, які використовують Xen; вона знаходиться в пакеті libc6-xen.

Щоб уникнути мороки з вибором цих компонентів вручну, для зручності створене кілька пакетів (таких як xen-linux-system-amd64); вони тягнуть за собою завідомо працездатний набір відповідних пакетів гипервизора і ядра. З гіпервізором також поставляється пакет xen-utils-4.4, що містить інструменти для управління гіпервізором з dom0. Він в свою чергу залежить від відповідної стандартної бібліотеки. Під час установки всього цього конфігураційні сценарії також створюють новий запис в меню завантажувача Grub, щоб запустити вбрання ядро ​​в Xen dom0. Зауважте однак, що цей запис зазвичай встановлюється не першою в списку, і тому не вибирається за замовчуванням. Якщо це не те поведінка, якого ви хотіли, такі команди змінять його:

# Mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen # update-grub

Коли все необхідне встановлено, наступним кроком буде тестування поведінки самого dom0; воно включає перезавантаження в гипервизор і ядро ​​Xen. Система повинна завантажитися звичайним чином, з кількома додатковими повідомленнями в консолі на ранніх стадіях ініціалізації.

Тепер час власне встановити відповідні системи в domU за допомогою інструментів з xen-tools. Цей пакет надає команду xen-create-image, яка в значній мірі автоматизує задачу. Єдиний обов'язковий параметр - --hostname, передає ім'я domU; інші опції важливі, але вони можуть бути збережені в файлі конфігурації /etc/xen-tools/xen-tools.conf, і їх відсутність в командному рядку не викличе помилки. Тому слід перевірити вміст цього файлу перед створенням образів, або ж використовувати додаткові параметри у виклику xen-create-image. Відзначимо наступні важливі параметри:

• --memory для вказівки кількості ОЗУ, виділеного новостворюваної системі;

• --size і --swap, щоб задати розмір «віртуальних дисків», доступних для domU;

• --debootstrap, щоб нова система встановлювалася за допомогою debootstrap; в цьому випадку також найчастіше використовується опція --dist (із зазначенням імені дистрибутива, наприклад jessie).

• --dhcp оголошує, що конфігурація мережі domU повинна бути отримана по DHCP, у той час як --ip дозволяє задати статичний IP-адресу.

• Нарешті, слід вибрати метод зберігання для створюваних образів (тих, які будуть видні як жорсткі диски з domU). Найпростіший метод, відповідний опції --dir, полягає в створенні одного файлу на dom0 для кожного пристрою, який буде передано domU. Для систем, що використовують LVM, альтернативою є використання опції --lvm, за якої вказується ім'я групи томів; в такому випадку xen-create-image створить новий логічний тому в цій групі, і цей логічний тому стане доступним для domU як жорсткий диск.

Коли вибори зроблені, ми можемо створити образ для нашого майбутнього Xen domU:

# Xen-create-image --hostname testxen --dhcp --dir / srv / testxen --size = 2G --dist = jessie --role = udev [...] General Information -------- ------------ Hostname: testxen Distribution: jessie Mirror: http://ftp.debian.org/debian/ Partitions: swap 128Mb (swap) / 2G (ext3) Image type: sparse Memory size : 128Mb Kernel path: /boot/vmlinuz-3.16.0-4-amd64 Initrd path: /boot/initrd.img-3.16.0-4-amd64 [....] Logfile produced at: / var / log / xen -tools / testxen.log Installation Summary --------------------- Hostname: testxen Distribution: jessie MAC Address: 00: 16: 3E: 8E: 67: 5C IP -Address (es): dynamic RSA Fingerprint: 0a: 6e: 71: 98: 95: 46: 64: ec: 80: 37: 63: 18: 73: 04: dd: 2b Root Password: adaX2jyRHNuWm8BDJS7PcEJ

Тепер у нас є віртуальна машина, але вона ще не запущена (і тому тільки займає місце на жорсткому диску dom0). Зрозуміло, ми можемо створити більше образів, можливо з різними параметрами.

До включення цих віртуальних машин нам потрібно визначити, як буде виходити доступ до них. Зрозуміло, вони можуть бути призначені ізольованими машинами, доступними тільки через системну консоль, але це рідко відповідає сценарію роботи. Велику частину часу domU буде вважатися віддаленим сервером, і доступ до нього буде здійснюватися тільки через мережу. Однак було б дуже незручним додавати мережеву карту для кожного domU; з цієї причини Xen дозволяє створювати віртуальні інтерфейси, які кожен домен може бачити і використовувати звичайним чином. Зауважте, що ці карти, хоч вони і віртуальні, будуть корисними тільки коли вони підключені до мережі, хоча б віртуальної. У Xen є кілька мережевих моделей для цього:

• Найпростішою є модель моста; всі мережеві карти eth0 (як в dom0, так і в domU-системах) поводяться, як якщо б вони були безпосередньо підключені до Ethernet-комутатора.

• Наступна модель - маршрутизациї, коли dom0 поводиться як маршрутизатор, що знаходиться між domU-системами і (фізичної) зовнішньою мережею.

• Нарешті, в моделі NAT dom0 знову знаходиться між domU-системами та іншою мережею, але domU-системи не доступні ззовні безпосередньо, і трафік проходить через перетворення адрес на dom0.

Ці три мережевих режиму включають різні інтерфейси з незвичайними іменами, такими як vif *, veth *, peth * і xenbr0. Гипервизор Xen комбінує їх відповідно до заданої схемою під контролем інструментів простору користувача. Оскільки NAT і маршрутизациї модель пристосовані лише для окремих випадків, ми розглянемо тільки модель моста.

Стандартна конфігурація пакетів Xen не змінює загальносистемних параметрів мережі. Однак демон xend налаштований на підключення віртуальних мережевих інтерфейсів до будь-якого вже існуючому мережному мосту (при наявності декількох таких мостів перевага віддається xenbr0). Тому нам треба налаштувати міст в / etc / network / interfaces (для цього потрібно встановити пакет bridge-utils, тому він рекомендується пакетом xen-utils-4.4), замінивши існуючу запис eth0:

auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0

Перезавантажити для перевірки, що міст створюється автоматично, ми можемо запустити domU за допомогою інструментів управління Xen, а саме команди xl. Ця команда дозволяє виробляти різні маніпуляції з доменами, зокрема виводити їх список, запускати їх і зупиняти.

# Xl list Name ID Mem VCPUs State Time (s) Domain-0 0 463 1 r ----- 9.8 # xl create /etc/xen/testxen.cfg Parsing config from /etc/xen/testxen.cfg # xl list Name ID Mem VCPUs State Time (s) Domain-0 0 366 1 r ----- 11.4 testxen 1 128 1 -b ---- 1.1

Зауважте, що domU testxen використовує реальну пам'ять, взяту з ОЗУ, яка інакше була б доступна dom0, а не віртуальну. Тому при складанні сервера для розміщення машин Xen слід потурбуватися про забезпечення достатнього обсягу фізичного ОЗУ.

Voilà! Наша віртуальна машина запускається. Ми можемо отримати доступ до неї в одному з двох режимів. Звичайний шлях - підключатися до неї «віддалено» через мережу, як ми підключалися б до реальної машині; для цього зазвичай потрібно налаштування або DHCP-сервера, або DNS. Інший шлях, який може стати єдино можливим в разі неправильної настройки мережі, - використання консолі hvc0 за допомогою команди xl console:

# Xl console testxen [...] Debian GNU / Linux 8 testxen hvc0 testxen login:

Після цього можна почати сесію, як якщо б ви сиділи за клавіатурою віртуальної машини. Для відключення від цієї консолі є поєднання клавіш Control +].

Коли domU запущений, він може використовуватися як будь-який інший сервер (адже це, крім іншого, система GNU / Linux). Однак завдяки тому, що це віртуальна машина, доступні і деякі додаткові можливості. Наприклад, domU може бути тимчасово призупинено, а потім знову запущений за допомогою команд xl pause і xl unpause. Зауважте, що хоча призупинений domU не використовує ресурси процесора, виділена йому пам'ять і раніше зайнята. Може мати сенс використовувати команди xl save і xl restore: збереження domU звільняє ресурси, що раніше використовувалися цим domU, в тому числі і ОЗУ. Після відновлення (або зняття з паузи) domU не помічає нічого крім того, що минув певний час. Якщо domU був запущений, коли dom0 вимикається, сценарії з пакетів автоматично зберігають domU і відновлюють його при наступному завантаженні. Звідси, звичайно, виникає звичайне незручність, що виявляється, наприклад, при перекладі ноутбука в сплячий режим; зокрема, якщо domU припинений занадто надовго, мережеві підключення можуть завершитися. Зауважте також, що Xen на даний момент несумісний з більшою частиною системи керування живленням ACPI, що заважає припинення dom0-системи.

Вимкнення або перезавантаження domU можуть бути виконані як зсередини domU (за допомогою команди shutdown), так і з dom0, за допомогою xl shutdown або xl reboot.

Хоча вона і використовується для створення «віртуальних машин», LXC є, строго кажучи, не системою віртуалізації, а системою для ізоляції груп процесів один від одного, навіть якщо вони все виконуються на одному вузлі. Вона використовує набір недавніх змін в ядрі Linux, відомих під загальною назвою control groups, завдяки якому різні набори процесів, звані «групами», мають різні уявлення про деякі аспекти системи. Найбільш примітні з цих аспектів - ідентифікатори процесів, конфігурація мережі та точки монтування. Така група ізольованих процесів не матиме доступу до інших процесів в системі, і її доступ до файлової системи може бути обмежений певним підмножиною. У неї також можуть бути свої власні мережевий інтерфейс і таблиця маршрутизації, і вона може бути налаштована так, щоб бачити тільки підмножина пристроїв, присутніх в системі.

За допомогою комбінації цих можливостей можна ізолювати ціле сімейство процесів починаючи з процесу init, і вийшов набір буде виглядати надзвичайно схоже на віртуальну машину. Офіційна назва для такої схеми «контейнер» (звідси і неофіційну назву LXC: LinuX Containers), але вельми значною відмінністю від «справжніх» віртуальних машин, таких як надаються Xen або KVM, полягає у відсутності другого ядра; контейнер використовує те ж саме ядро, що і хост-система. У цього є як переваги, так і недоліки: до переваг відноситься чудова продуктивність завдяки повній відсутності накладних витрат, а також те, що ядро ​​бачить всі процеси в системі, тому планувальник може працювати більш ефективно, ніж якби два незалежних ядра займалися плануванням виконання різних наборів завдань. Основне з незручностей - неможливість запустити інше ядро ​​в контейнері (як іншу версію Linux, так і іншу операційну систему).

Оскільки ми маємо справу з ізоляцією, а не звичайною виртуализацией, настройка контейнерів LXC складніша, ніж простий запуск debian-installer на віртуальній машині. Ми опишемо деякі попередні вимоги, потім перейдемо до конфігурації мережі; після цього ми зможемо власне створити систему для запуску в контейнері.

12.2.2.1. попередні кроки

Пакет lxc містить інструменти, необхідні для запуску LXC, тому його необхідно встановити.

LXC також вимагає систему конфігурації control groups, що представляє собою віртуальну файлову систему, яка повинна бути змонтована в / sys / fs / cgroup. Так як Debian 8 перейшов на systemd, який також залежить від control groups, це робиться автоматично під час завантаження без додаткової настройки.

12.2.2.2. Мережеві налаштування

Мета установки LXC - в запуску віртуальних машин; хоча ми, зрозуміло, можемо тримати їх ізольованими від мережі і взаємодіяти з ними тільки через файлову систему, для більшості завдань потрібно хоча б мінімальний мережевий доступ до контейнерів. У типовому випадку кожен контейнер отримає віртуальний мережевий інтерфейс приєднаний до реальної мережі через міст. Цей віртуальний інтерфейс може бути підключений або безпосередньо до фізичного мережному інтерфейсу хост-системи (в такому випадку контейнер безпосередньо в мережі), або до іншого віртуального інтерфейсу, визначеному в хост-системі (тоді хост зможе фільтрувати або маршрутизировать трафік). В обох випадках потрібно пакет bridge-utils.

У найпростішому випадку це всього лише питання правки / etc / network / interfaces, перенесення конфігурації фізичного інтерфейсу (наприклад eth0) на інтерфейс моста (зазвичай br0) і налаштування зв'язку між ними. Наприклад, якщо конфігураційний файл мережевих інтерфейсів спочатку містить записи на зразок таких:

auto eth0 iface eth0 inet dhcp

Їх слід відключити і замінити на наступні:

#auto eth0 #iface eth0 inet dhcp auto br0 iface br0 inet dhcp bridge-ports eth0

Результат такого налаштування буде схожий на той, який ми отримали б, якби контейнери були машинами, підключеними до тієї ж фізичної мережі, що і хост-машина. Конфігурація «міст» управляє проходженням кадрів Ethernet між усіма пов'язаними інтерфейсами, включаючи і фізичний eth0, і інтерфейси, задані для контейнерів.

У випадках, коли таку конфігурацію використовувати неможливо (наприклад якщо контейнерів можна виділити публічні IP-адреси), чи буде створено і підключений до мосту віртуальний tap-інтерфейс. Це буде еквівалентна мережевої топології, при якій друга мережева карта підключена до окремого комутатора, і до нього ж підключені контейнери. Хост тоді повинен виступати як шлюз для контейнерів, якщо їм потрібно з'єднуватися з рештою світу.

На додаток до bridge-utils для «просунутої» конфігурації буде потрібно пакет vde2; файл / etc / network / interfaces тоді прийме наступний вигляд:

# Інтерфейс eth0 без змін auto eth0 iface eth0 inet dhcp # Віртуальний інтерфейс auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Міст для контейнерів auto br0 iface br0 inet static bridge-ports tap0 address 10.0.0.1 netmask 255.255.255.0

Мережа може бути налаштована як статично в контейнерах, так і динамічно і допомогою DHCP-сервера, запущеного на хост-системі. Такий DHCP-сервер повинен бути налаштований для відповіді на запити на інтерфейсі br0.

12.2.2.3. установка системи

Давайте тепер налаштуємо файлову систему для використання контейнером. Оскільки ця «віртуальна машина» не запускатися безпосередньо на обладнанні, будуть потрібні деякі додаткові маніпуляції в порівнянні зі звичайною файлової системою, особливо коли справа стосується ядра, пристроїв і консолей. На щастя, пакет lxc включає сценарії, які в значній мірі автоматизують цю настройку. Зокрема, такі команди (для яких потрібні пакети debootstrap і rsync) встановлять контейнер з Debian:

root @ mirwiz: ~ # lxc-create -n testlxc -t debian debootstrap is / usr / sbin / debootstrap Перевіряю кеш, що скачав в / var / cache / lxc / debian / rootfs-jessie-amd64 ... Завантажую debian minimal .. . I: перезапитує Release I: перезапитує Release.gpg [...] скачемо комплект. Копіюю rootfs в / var / lib / lxc / testlxc / rootfs ... [....] Пароль адміністратора є 'sSiKhMzI', будь ласка зміни! root @ mirwiz: ~ #

Зауважте, що файлова система спочатку створена в / var / cache / lxc, а потім переміщена у каталог призначення. Це дозволяє створювати ідентичні контейнери набагато швидше, оскільки потрібно лише скопіювати їх.

Зауважте, що сценарій створення шаблону debian приймає опцію --arch із вказівкою архітектури системи для установки і опцію --release, якщо Ви ви хочете встановити щось відмінне від поточного стабільного релізу Debian. Ви можете також встановити змінну оточення MIRROR, щоб вказати на локальне дзеркало Debian.

Щойно створена файлова система тепер містить мінімальну систему Debian, і за замовчуванням у контейнера немає мережевого інтерфейсу (за винятком loopback). Оскільки це не те, чого ми хотіли, ми відредагуємо файл конфігурації контейнера (/ var / lib / lxc / testlxc / config) і додамо кілька записів lxc.network. *:

lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.hwaddr = 4a: 49: 43: 49: 79: 20

Ці записи означають, відповідно, що в контейнері буде створений віртуальний інтерфейс, що він буде автоматично підніматися при запуску цього контейнера, що він буде автоматично з'єднуватися з мостом br0 на хост-системі і що його MAC-адресу буде відповідати зазначеному. Якби ця остання запис була відсутня або була відключена, генерувався б випадковий MAC-адресу.

Інша корисна запис в цьому файлі - ім'я вузла:

lxc.utsname = testlxc

12.2.2.4. запуск контейнера

Тепер, коли наша віртуальна машина готова, давайте запустимо контейнер:

root @ mirwiz: ~ # lxc-start --daemon --name = testlxc root @ mirwiz: ~ # lxc-console -n testlxc Debian GNU / Linux 8 testlxc tty1 testlxc login: root Password: Linux testlxc 3.16.0-4- amd64 # 1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 The programs included with the Debian GNU / Linux system are free software; the exact distribution terms for each program are described in the individual files in / usr / share / doc / * / copyright. Debian GNU / Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root @ testlxc: ~ # ps auxwf USER PID% CPU% MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 28164 4432? Ss 17:33 0:00 / sbin / init root 20 0.0 0.1 32960 3160? Ss 17:33 0:00 / lib / systemd / systemd-journald root 82 0.0 0.3 55164 5456? Ss 17:34 0:00 / usr / sbin / sshd -D root 87 0.0 0.1 12656 1924 tty2 Ss + 17:34 0:00 / sbin / agetty --noclear tty2 linux root 88 0.0 0.1 12656 1764 tty3 Ss + 17:34 0 : 00 / sbin / agetty --noclear tty3 linux root 89 0.0 0.1 12656 1908 tty4 Ss + 17:34 0:00 / sbin / agetty --noclear tty4 linux root 90 0.0 0.1 63300 2944 tty1 Ss 17:34 0:00 / bin / login - root 117 0.0 0.2 21828 3668 tty1 S 17:35 0:00 \ _ -bash root 268 0.0 0.1 19088 2572 tty1 R + 17:39 0:00 \ _ ps auxfw root 91 0.0 0.1 14228 2356 console Ss + 17: 34 0:00 / sbin / agetty --noclear --keep-baud console 115200 38400 9600 vt102 root 197 0.0 0.4 25384 7640? Ss 17:38 0:00 dhclient -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.e root 266 0.0 0.1 12656 1840 Ss 17:39 0:00 / sbin / agetty --noclear tty5 linux root 267 0.0 0.1 12656 1928? Ss 17:39 0:00 / sbin / agetty --noclear tty6 linux root @ testlxc: ~ #

Тепер ми в контейнері; наш доступ до процесів обмежений тільки тими, які запущені зсередини самого контейнера, і наш доступ до файлової системи також обмежений до виділеного підмножини повної файлової системи (/ var / lib / lxc / testlxc / rootfs). Ми можемо вийти з консолі за допомогою Control + a q.

Зауважте, що ми запустили контейнер як фоновий процес завдяки опції --daemon команди lxc-start. Контейнер можна перервати згодом за допомогою такої команди як lxc-stop --name = testlxc.

Пакет lxc містить сценарій ініціалізації, який може автоматично запускати один або кілька контейнерів при завантаженні хост-системи (він використовує lxc-autostart, яка запускає контейнери, параметр lxc.start.auto яких встановлено в значення 1). Більш тонкий контроль порядку запуску можливий за допомогою lxc.start.order і lxc.group: за замовчуванням сценарій ініціалізації спочатку запускає контейнери, що входять в групу onboot, а потім - контейнери, що не входять ні в які групи. В обох випадках порядок всередині групи визначається параметром lxc.start.order.

12.2.3. Віртуалізація за допомогою KVM

KVM, що розшифровується як Kernel-based Virtual Machine, є першим і головним модулем ядра, які надають більшу частину інфраструктури, яка може використовуватися віртуалізатор, але не є самим віртуалізатор. Власне контроль за виртуализацией здійснюється додатком, заснованим на QEMU. Не переживайте, якщо в цьому розділі будуть згадуватися команди qemu- *: мова все одно про KVM.

На відміну від інших систем віртуалізації, KVM був влитий в ядро ​​Linux з самого початку. Його розробники вирішили використовувати наборів інструкцій процесора, виділених для віртуалізації (Intel-VT і AMD-V), завдяки чому KVM вийшов легковажним, елегантним і не ненажерливим до ресурсів. Зворотною стороною медалі є, природно, те, що KVM працює не на будь-якому комп'ютері, а тільки на такому, в якому встановлений належний процесор. Для x86-машин можна переконатися, чи такий у вас процесор, перевіривши наявність прапора «vmx» або «svm» в файлі / proc / cpuinfo.

Оскільки його розробка активно підтримується Red Hat, KVM став в тій чи іншій мірі еталоном віртуалізації в Linux.

12.2.3.1. попередні кроки

На відміну від таких інструментів, як VirtualBox, сам по собі KVM не включає ніякого призначеного для користувача інтерфейсу для створення віртуальних машин і управління ними. Пакет qemu-kvm надає лише виконуваний файл, здатний запустити віртуальну машину, а також ініціалізації скрипт, що завантажує відповідні модулі ядра.

На щастя, Red Hat також надає набір інструментів для вирішення цієї проблеми, розробляючи бібліотеку libvirt і пов'язані з нею інструменти менеджера віртуальних машин. libvirt дозволяє управляти віртуальними машинами уніфікованим чином, незалежно від що стоїть за нею системою віртуалізації (на даний момент вона підтримує QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare і UML). virtual-manager - це графічний інтерфейс, який використовує libvirt для створення віртуальних машин і управління ними.

Насамперед ми встановимо необхідні пакети за допомогою команди apt-get install qemu-kvm libvirt-bin virtinst virt-manager virt-viewer. libvirt-bin надає демон libvirtd, що дозволяє (можливо віддалено) керувати віртуальними машинами, запущеними на хості, і запускає необхідні віртуальні машини при завантаженні хоста. Крім того, цей пакет надає утиліту virsh з інтерфейсом командного рядка, яка дозволяє контролювати віртуальні машини, керовані libvirt.

Пакет virtinst надає virt-install, яка дозволяє створювати віртуальні машини з командного рядка. Нарешті, virt-viewer дозволяє отримувати доступ до графічної консолі віртуальної машини.

12.2.3.2. Мережеві налаштування

Як і у випадках Xen і LXC, найбільш поширена мережева конфігурація включає міст, группирующий мережеві інтерфейси віртуальних машин (див. Розділ 12.2.2.2, «Мережеві настройки» ).

В якості альтернативи, в конфігурації KVM за замовчуванням, віртуальній машині видається адреса з приватного діапазону (192.168.122.0/24), і NAT налаштовується таким чином, щоб віртуальна машина могла отримати доступ в зовнішню мережу.

Нижче в цьому розділі вважається, що на хост-системі є фізичний інтерфейс eth0 і міст br0, і що перший приєднаний до останнього.

12.2.3.3. Установка за допомогою virt-install

Створення віртуальної машини дуже схоже на установку звичайної системи з тією різницею, що характеристики віртуальної машини описуються в командному рядку, що здається нескінченною.

З практичної точки зору це означає, що ми будемо використовувати установник Debian, завантажуючи віртуальну машину з віртуального приводу DVD-ROM, відповідного образу DVD Debian, що зберігається на хост-системі. Віртуальна машина експортує свій графічний інтерфейс за протоколом VNC (див. Подробиці в Розділ 9.2.2, «Використання віддалених графічних робочих столів» ), Що дозволить нам контролювати процес установки.

Для початку потрібно сказати libvirtd, де зберігати образи дисків, якщо тільки нас не влаштовує розташування за замовчуванням (/ var / lib / libvirt / images /).

root @ mirwiz: ~ # mkdir / srv / kvm root @ mirwiz: ~ # virsh pool-create-as srv-kvm dir --target / srv / kvm Pool srv-kvm created root @ mirwiz: ~ #

Давайте запустимо процес установки на віртуальній машині і ближче глянемо на найбільш важливі опції virt-install. Ця команда реєструє віртуальну машину і її параметри в libvirtd, а потім запускає її, щоб приступити до установки.

# Virt-install --connect qemu: /// system --virt-type kvm --name testkvm --ram тисяча двадцять чотири --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 --cdrom /srv/isos/debian-8.1.0-amd64-netinst.iso --network bridge = br0 --vnc --os-type linux --os-variant debianwheezy Starting install ... Allocating 'testkvm.qcow' | 10 GB 00:00 Creating domain ... | 0 B 00:00 Guest installation complete ... restarting guest.

Опція --connect вказує, який «гипервизор» використовувати. Він вказується в вигляді URL, що містить систему віртуалізації (xen: //, qemu: //, lxc: //, openvz: //, vbox: // і т. П.) І машину, на якій повинні розміщуватися віртуальні машини ( це поле можна залишити порожнім у разі локального вузла). На додаток до цього, в разі QEMU / KVM кожен користувач може управляти віртуальними машинами, які працюють з обмеженими правами, і шлях URL дозволяє диференціювати «системні» машини (/ system) від інших (/ session).

Так як KVM управляється тим же чином, що і QEMU, в --virt-type kvm можна вказати використання KVM, хоча URL і виглядає так само, як для QEMU.

Опція --name задає (унікальне) ім'я віртуальної машини.

Опція --ram дозволяє вказати обсяг ОЗУ (в МБ), який буде виділений віртуальній машині.

--disk служить для вказівки місця розташування файлу образу, який буде представлятися жорстким диском віртуальної машини; цей файл створюється, якщо тільки ще не існує, а його розмір (в ГБ) вказується параметром size. Параметр format дозволяє вибрати з декількох способів зберігання образу файлу. Формат за замовчуванням (raw) - це окремий файл, в точності відповідний диску за розміром і вмісту. Ми вибрали тут більш передової формат, специфічний для QEMU і дозволяє почати з невеликого файлу, що збільшується тільки в міру того, як віртуальна машина використовує простір.

Опція --cdrom використовується, щоб вказати, де шукати оптичний диск для установки. Шлях може бути або локальним шляхом до ISO-файлу, або URL, за яким можна отримати файл, або файлом пристрою фізичного приводу CD-ROM (тобто / dev / cdrom).

За допомогою опції --network вказується, яким чином віртуальна мережева карта інтегрується в мережеву конфігурацію хоста. Поведінкою за замовчуванням (яке ми поставили явно в цьому прикладі) є інтеграція в будь-який існуючий мережевий міст. Якщо жодного моста немає, віртуальна машина зможе отримати доступ до фізичної мережі тільки через NAT, тому вона отримує адресу в підмережі з приватного діапазону (192.168.122.0/24).

--vnc означає, що підключення до графічної консолі потрібно зробити доступним через VNC. За замовчуванням відповідний VNC-сервер слухає тільки на локальному інтерфейсі; якщо VNC-клієнт повинен запускатися на іншій системі, для підключення потрібно використовувати SSH-тунель (див. Розділ 9.2.1.3, «Створення шифрованих тунелів» ). Як варіант, можна використовувати опцію --vnclisten = 0.0.0.0, щоб VNC-сервер став доступний на всіх інтерфейсах; зауважте, що якщо ви зробите так, вам серйозно варто зайнятися налаштуванням брандмауера.

Опції --os-type і --os-variant дозволяють оптимізувати деякі параметри віртуальної машини, виходячи з відомих особливостей зазначеної операційної системи.

Зараз віртуальна машина запущена, і нам треба підключитися до графічної консолі, щоб зробити установку. Якщо попередній крок виконувався в графічному оточенні, це підключення встановиться автоматично. В іншому випадку, або ж при віддаленій роботі, щоб відкрити графічну консоль, можна запустити virt-viewer в будь-якому графічному оточенні (пароль root на віддаленій машині запитується двічі, оскільки для роботи потрібно два SSH-з'єднання):

$ Virt-viewer --connect qemu + ssh: // root @ server / system testkvm root @ server's password: root @ server's password:

Коли процес установки завершиться, віртуальна машина перезавантажиться і буде готова до роботи.

12.2.3.4. Управління машинами за допомогою virsh

Тепер, коли установка виконана, давайте подивимося, як поводитися з наявними віртуальними машинами. Насамперед спробуємо попросити у libvirtd список керованих їм віртуальних машин:

# Virsh -c qemu: /// system list --all Id Name State --------------------------------- - - testkvm shut off

Давайте запустимо нашу тестову віртуальну машину:

# Virsh -c qemu: /// system start testkvm Domain testkvm стартує

Тепер можна отримати інструкції для підключення до графічної консолі (повернутий VNC-дисплей можна передати в якості параметра команді vncviewer):

# Virsh -c qemu: /// system vncdisplay testkvm: 0

До числа інших підкоманду virsh входять:

• reboot для перезапуску віртуальної машини;

• shutdown для коректного завершення роботи;

• destroy для грубого переривання роботи;

• suspend для тимчасового призупинення;

• resume для продовження роботи після припинення;

• autostart для включення (або для виключення, з опцією --disable) автоматичного запуску віртуальної машини під час запуску хост-системи;

• undefine для видалення всіх слідів віртуальної машини з libvirtd.

Всі ці підкоманди приймають ідентифікатор віртуальної машини в якості параметра.

12.2.3.5. Установка RPM-системи в Debian за допомогою yum

Якщо віртуальна машина призначається для запуску Debian (або одного з похідних дистрибутивів), систему можна форматувати за допомогою debootstrap, як описано вище. Але якщо на віртуальну машину треба встановити систему, засновану на RPM (таку як Fedora, CentOS або Scientific Linux), установку слід проводити за допомогою утиліти yum (яка доступна з однойменного пакету).

Ця процедура вимагає використання rpm для розпакування початкового набору файлів, включаючи, зокрема, конфігураційні файли yum, а потім виклик yum для розпакування залишилися пакетів. Але оскільки yum викликається ззовні chroot, буде потрібно внести деякі тимчасові зміни. У прикладі нижче цільової chroot - / srv / centos.

# Rootdir = "/ srv / centos" # mkdir -p "$ rootdir" / etc / rpm # echo "% _dbpath / var / lib / rpm"> /etc/rpm/macros.dbpath # wget http: // mirror. centos.org/centos/7/os/x86_64/Packages/centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm # rpm --nodeps --root "$ rootdir" -i centos-release-7 -1.1503.el7.centos.2.8.x86_64.rpm rpm: RPM should not be used directly install RPM packages , use Alien instead! rpm: However assuming you know what you are doing ... warning: centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm: Header V3 RSA / SHA256 Signature, key ID f4a80eb5: NOKEY # sed -i - e "s, gpgkey = file: /// etc /, gpgkey = file: // $ {rootdir} / etc /, g" $ rootdir / etc / yum.repos.d / *. repo # yum --assumeyes - -installroot $ rootdir groupinstall core [...] # sed -i -e "s, gpgkey = file: // $ {rootdir} / etc /, gpgkey = file: /// etc /, g" $ rootdir / etc /yum.repos.d/*.repo