Установка linux mint kvm ubuntu. Гумовий гипервизор. Використовуємо логічні групи для віртуалізації QEMU-KVM в Linux. Ручна настройка моста

В 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 \u003d metadata -f qcow2 qcow2.img 20G

Згідно з тим же man qemu-img, попереднє розміщення метаданих (-o preallocation \u003d 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 \u003d kvm \\ --name ubuntu1604 \\ --ram тисячу двадцять-чотири \\ --vcpus \u003d 1 \\ --os-variant \u003d ubuntu16.04 \\ --hvm \\ --cdrom \u003d / var / lib / libvirt / boot / ubuntu-16.04.1-server-amd64.iso \\ --network network \u003d default, model \u003d virtio \\ --graphics vnc \\ --disk path \u003d / var / lib / libvirt / images / ubuntu1604. img, size \u003d 20, bus \u003d virtio

Перекладаючи всі ці параметри на "людську мову", то виходить, що ми створюємо віртуальну машину з ОС Ubuntu 16.04, 1024 МБ ОЗУ, 1 процесором, стандартної мережевої картою (віртуальна машина буде ходити в інтернет как-будто через NAT), 20 ГБ HDD.

Варто звернути увагу на параметр --os-variant, Він вказує Гіпервізор під яку саме ОС слід адаптувати настройки.
Список доступних варіантів ОС можна отримати, виконавши команду:

Osinfo-query os

Якщо такої утиліти немає у вашій системі, то встановлюємо:

Sudo apt-get install libosinfo-bin

Після запуску установки, в консолі з'явиться ось такий напис:

Domain installation still in progress. You can reconnect to the console to complete the installation process.

Це нормальна ситуація, продовжувати установку ми будемо через VNC.
Дивимося на якому порту він був піднятий у нашій виртуалки (в сусідньому терміналі, наприклад):

Virsh dumpxml ubuntu1604 ... ...

Порт 5900, на локальному адресу 127.0.0.1. Щоб підключитися до VNC, необхідно використовувати Port Forwarding через ssh. Перед тим як це зробити, переконайтеся, що tcp forwarding дозволений у демона ssh. Для цього йдемо в настройки sshd:

Cat / etc / ssh / sshd_config | grep AllowTcpForwarding

Якщо нічого не знайшлося або ви бачите:

AllowTcpForwarding no

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

AllowTcpForwarding yes

і перезавантажуємо sshd.

Налаштування Port forwarding

Виконуємо команду на локальній машині:

Ssh -fN -l login -L 127.0.0.1:5900:localhost:5900 server_ip

Тут ми налаштували ssh port forwarding з локального порту 5900 на серверний порт 5900. Тепер уже можна підключитися до VNC, використовуючи будь-який VNC-клієнт. Я віддаю перевагу UltraVNC через простоти і зручності.

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

Після завершення установки і звичної перезавантаження, з'явиться вікно входу в систему. Авторизувавшись, визначаємо IP адреса новоспеченої виртуалки, щоб пізніше зробити його статичним:

Ifconfig

Запам'ятовуємо і йдемо на хост машину. Витягуємо mac-адресу "мережевий" карти виртуалки:

Virsh dumpxml ubuntu1604 | grep "mac address"

Запам'ятовуємо наш mac адресу:

редагуємо мережеві настройки гипервизора:

Sudo virsh net-edit default

Шукаємо DHCP, і додаємо ось це:

Має вийти щось на зразок цього:

Для того, щоб настройки вступили в силу, необхідно перезавантажити DHCP сервер гипервизора:

Sudo virsh net-destroy default sudo virsh net-start default sudo service libvirt-bin restart

Після цього перенавантажуємо віртуальну машину, тепер вона завжди буде мати заданий їй IP адреса - 192.168.122.131.

Є й інші способи задати виртуалке статичний IP, наприклад, безпосередньо редагуючи мережеві настройки всередині гостьової системи, але тут вже як душі вашої буде завгодно. Я лише показав варіант, який сам вважаю за краще використовувати.

Щоб підключитися до терміналу віртуальної машини, виконуємо:

Ssh 192.168.122.131

Машина готова до бою.

Virsh: список команд

Щоб подивитися запущені віртуальні хости (Всі доступні можна отримати додавши --all):

Sudo virsh list

Перезавантажити хост можна:

Sudo virsh reboot $ VM_NAME

Зупинити віртуальну машину:

Sudo virsh stop $ VM_NAME

Виконати halt:

Sudo virsh destroy $ VM_NAME

Sudo virsh start $ VM_NAME

відключення:

Sudo virsh shutdown $ VM_NAME

Додати в автозапуск:

Sudo virsh autostart $ VM_NAME

Дуже часто потрібно склоніровать систему, щоб в майбутньому використовувати її як каркас для інших віртуальних ОС, для цього використовують утиліту virt-clone.

Virt-clone --help

Вона клонує існуючу виртуалку і змінює host-sensitive дані, наприклад, mac address. Паролі, файли та інша user-specific інформація в клоні залишається колишньою. Якщо на клонують виртуалке IP адреса був прописаний вручну, то можуть виникнути проблеми з доступом по SSH на клон через конфлікт (2 хоста з однаковим IP).

Крім установки виртуалки через VNC, також можливий варіант з X11Forwarding через утиліту virt-manager. У Windows, наприклад, для цього можна використовувати Xming і PuTTY.

У цій вступній статті я розповім коротко про всі програмних засобах, Використаних в процесі розробки послуги. Більш докладно про них буде розказано в наступних статтях.

Чому? ця операційна система мені близька і зрозуміла, так що при виборі дистрибутива мук, мук і метань випробувано не було. Особливих переваг перед Red Hat Enterprise Linux у нього немає, але було прийнято рішення працювати зі знайомою системою.

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

Ми ж, повторюся, вирішили використовувати Debian Squeeze з набором пакетів з Sid / Experimental і деякими пакетами, бекпортірованнимі і зібраними з нашими патчами.
У планах є публікація сховища з пакетами.

При виборі технології віртуалізації розглядалися два варіанти - Xen і KVM.

Також до уваги приймався факт наявності величезної кількості розробників, хостерів, комерційних рішень саме на базі Xen - тим цікавіше було провести в життя рішення саме на базі KVM.

Основною ж причиною, по якій ми вирішили використовувати саме KVM, є необхідність запуску віртуальних машин з FreeBSD і, в перспективі, MS Windows.

Для управління віртуальними машинами виявилося надзвичайно зручно використовувати і продукти, що використовують її API: virsh, virt-manager, virt-install, Пр.

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

Зрозуміло, рішення не ідеально. З мінусів слід назвати:

Абсолютно несамовиті повідомлення про помилки.
Неможливість змінювати частина конфігурації віртуальної машини на льоту, хоча QMP (QEMU Monitor Protocol) це цілком дозволяє.
Іноді до libvirtd з незрозумілої причини неможливо підключитися - він перестає реагувати на зовнішні події.

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

У KVM нічого такого не було до появи механізму розподілу ресурсів ядра. Як завжди в Linux, доступ до цих функцій був реалізований за допомогою спеціальної файлової системи cgroup, В якій за допомогою звичайних системних викликів write () можна було додати процес в групу, призначити йому його вага в папуг, вказати ядро, на якому він буде працювати, вказати пропускну здатність диска, яку цей процес може використовувати, або, знову ж таки, призначити йому вагу.

Профіт в тому, що все це реалізується всередині ядра, і використовувати це можна не тільки для сервера, але і для робочого столу (що і використовували у відомому «The ~ 200 Line Linux Kernel Patch That Does Wonders»). І на мій погляд, це одна з найзначніших змін в гілці 2.6, не рахуючи улюбленого # 12309, а не запилення черговий файлової системи. Ну, хіба що, крім POHMELFS (але чисто через назву).

Ставлення до цієї бібліотеці-утиліту у мене дуже неоднозначне.

З одного боку це виглядає приблизно так:

І ще цю штуку чертовски складно зібрати з початкових кодів і тим більше в пакет: іноді мені здається, що Linux From Scratch зібрати з нуля дещо простіше.

З іншого боку - дуже потужна штука, яка дозволяє створювати образи для віртуальних машин, модифікувати їх, утискувати, ставити grub, модифікувати таблицю розділів, керувати файлами, переносити «залізні» машини в віртуальне середовище, переносити віртуальні машини з одного образу на інший, переносити віртуальні машини з образу на залізо і, чесно кажучи, тут мене фантазія трохи підводить. Ах, да: ще можна запустити демон всередині віртуальної машини Linux і отримати доступ до даних віртуальної машини наживо, і все це робити на shell, python, perl, java, ocaml. Це короткий і далеко не повний список того, що можна зробити з.

Цікаво, що більша частина коду в генерується в момент складання, так само як і документація до проекту. Дуже широко використовується ocaml, perl. Сам код пишеться на C, який потім обертається в OCaml, і повторювані шматки коду генеруються самі. Робота з образами здійснюється шляхом запуску спеціального сервісного образу (supermin appliance), в який через канал всередину нього відправляються команди. Усередині цього образу міститься деякий rescue набір утиліт, таких як parted, mkfs і інших корисних в господарстві системного адміністратора.

Я з недавнього часу його навіть вдома став використовувати, коли виколупував з образу nandroid потрібні мені дані. Але для цього потрібно ядро \u200b\u200bз підтримкою yaffs.

інше

Нижче наведено ще кілька цікавих посилань на опис використаних Пограмна коштів - почитати і повивчати самостійно, якщо цікаво. наприклад,

Раніше я вже писав про встановлення Qemu-KVM в Debian. Але, на мій погляд, інформація вийшла неповною. Плюс я не врахував деякі нюанси. Тому пропоную вашій увазі оновлену статтю по установці віртуальної машини Qemu-KVM. Стару статтю, природно, видалю.

Думаю, пояснювати що таке віртуальна машина, Не варто. Ви напевно це знаєте (раз читаєте цю статтю). Якщо ні - . Ми ж зупинимося непосредсвенно на сабже. Qemu-KVM - це проект по об'єднанню двох замечтальнейшійх (на мій погляд) технологій повної віртуалізації. Qemu - це свого роду "емулятор комп'ютера", який підтримує безліч апаратних архітектур. У ньому можна запустити практично будь-яку ОС для будь-якого пристрою (наприклад я запускав старі версії Mac OS X, Який для PowerPC). Недоліком Qemu є його повільність внаслідок відсутності апратних прискорення. І тут на допомогу приходить інший проект - KVM . Або Kernel Virtual Machine. KVM - це технологія ядра Linux, яка дозволяє забезпечити апаратне прискорення при повній віртуалізації. Недоліком KVM є підтримка тільки архітектури x86

Чому Qemu-KVM? Для Linux це самий рекомендований проект віртуалізації. Він працює швидше, ніж VirtualBox і VMware Player (За моїми тестам), KVM - це рідна для Лінукса технологія. Плюс, якщо ви власник гарного ігрового комп'ютера з двома відеокартами, ви можете встановити в Qemu-KVM Windows, Прокинути в неї одну з відеокарт, і забути про перезавантаження в іншу ОС. Захотіли погратися - запустили виртуалку з виндой і граєте. Продуктивність буде 95% від продуктивності встановленої на "залізо" вінди. Але це просто шикарно, на мій погляд. Про це я напишу окрему статтю. Буде цікаво:)

А тепер опишу план наших дій. По-перше, установку я буду проводити на прикладі Debian 8.2 GNOME 64 bit, Хоча, особливих відмінностей в інших графічних середовищах не буде. По-друге - я буду описувати роботу з KVM тільки в графічному режимі (ми ж не на сервер буде його ставити). Тому ніяких терміналів, скриптів і так далі, як зазвичай надходять в разі серверної віртуалізації. По-третє - раджу вам додатково прочитати документацію до Qemu і KVM (посилання дам в кінці статті). Вам це дуже стане в нагоді, якщо ви хочете по-максимуму використовувати весь потенціал цієї зв'язки. Ну що ж, план наших дій ясний. Тепер етапи дій:

установка qemu-kvm;
установка графічного менеджера і додаткових утиліт;
настройка мережевого моста;
створення сховища для віртуальних машин;
установка гостьової системи.

Для початку перевіримо, чи підтримує ваш комп'ютер апаратну віртуалізацію. Для цього в терміналі виконуємо команду:

egrep "(vmx | svm)" / proc / cpuinfo

У висновку команди повинні бути присутніми або vmx, або svm. Якщо їх немає - перевірте чи включена віртуалізація в BIOS (шукайте пункти Intel VT-i або аналогічний для AMD). Якщо нічого немає - значить не пощастило.

Встановлюємо необхідні компоненти:

sudo apt install qemu-kvm bridge-utils libvirt-bin virt-manager

Додаємо себе в групу libvirt:

sudo adduser $ USER libvirt

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

sudo nano /etc/sysctl.conf

Шукаємо рядок net.ipv4_forward \u003d 0 і міняємо її значення на 1 . Зберігаємо і:

sudo sysctl -p

Далі я буду припускати наступне: 1) на вашому комп'ютері є одна мережева карта, яка отримує ip-адреса від роутера. 2) ви виходите в інтернет через 3G-модем, і мережева карта у вас вільна. Цей варіант передбачає побільше ручної роботи, але він перевірений неодноразово (у самого так на одній з машин). Отже, відкриваємо файл interfaces:

sudo nano / etc / network / interfaces

Його вміст за замовчуванням таке:

auto lo
iface lo inet loopback

Міняємо його вміст. Для першого варіанту:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.2
gateway 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0

Для другого варіанту:

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto ppp0
iface ppp0 inet wvdial

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
address 192.168.0.2
gateway 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0
up route del default br0

Примітка: якщо вам не потрібно автоматичне підключення Інтернету через модем після старту системи, приберіть з конфіга рядки auto ppp0 і
iface ppp0 inet wvdial. В іншому випадку, переконайтеся що при запуску системи, модем вставлений в USB-порт.

Зберігаємо. Тепер для варіанту з модемом, потрібно встановити програму дозвону wvdial:

sudo apt install wvdial

Правимо конфиг (зверніть увагу: як приклад використовується 3G-модем Beeline. Приклади конфіги для інших модемів ви без зусиль знайдете в інтернеті):

sudo nano /etc/wvdial.conf

Init1 \u003d ATZ
Init2 \u003d ATQ0 V1 E1 S0 \u003d 0 & C1 & D2 + FCLASS \u003d 0
Init3 \u003d AT + CGDCONT \u003d 1, "IP", "home.beeline.ru"
Stupid Mode \u003d 1
ISDN \u003d 0
Modem Type \u003d USB Modem
New PPPD \u003d yes
Phone \u003d * 99 #
Modem \u003d / dev / ttyACM0
Username \u003d beeline
Password \u003d beeline
Baud \u003d 9600
Country \u003d Russia
Auto Reconnect \u003d on
Auto DNS \u003d off
Idle Seconds \u003d 0

Зберігаємо. Тепер модем буде включатися відразу після завантаження системи. Рядок up route del default br0 видаляє маршрут за замовчуванням через міст. Якщо цього не зробити, ви не зможете з'єднатися з Інтернетом, так як трафік буде йти по мосту, а не через 3G-модем.

Останнім етапом нам потрібно сказати фаєрволлу, Щоб він пропускав в мережу трафік від наших віртуалок і назад. Для цього можна піти двома шляхами: написати скрипт з кількома правилами для iptables, Який буде запускатися разом з системою, або ввести ці правила вручну і зберегти їх. Я скористаюся першим варіантом. Для другого вам потрібно буде встановити пакет iptables-persistent і просто по черзі вводити правила (з використанням sudo). Отже. створюємо скрипт (в будь-якому текстовому редакторі). Вставляємо туди наступне вміст:

#! / Bin / sh

# Визначаємо вихідний інтерфейс для якого буде застосовуватися заміна адрес (NAT)
iptables -v -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

# Пересилаємо все вхідні пакети з модем з глобальної мережі (0.0.0.0/0) в локальну мережу (192.168.0.0/24)
iptables -v -A FORWARD -i ppp0 -o br0 -s 0.0.0.0/0 -d 192.168.0.0/24 -j ACCEPT

# Пересилаємо все пакети, що прийшли з локальної мережі (192.168.0.0/24) в глобальну (0.0.0.0/0)
iptables -v -A FORWARD -i br0 -o ppp0 -s 192.168.0.0/24 -d 0.0.0.0/0 -j ACCEPT

Зберігаємо його як gateway.sh і даємо права на виконання (або у властивостях файлу, або в терміналі командою chmod + x gateway.sh). Тепер ви можете або запускати його вручну, після того як завантажилася система, або додати в автозавантаження. Для цього перемістіть скрипт в ~ / .Config / autostart (в файловому менеджері включите показ прихованих файлів, І ви побачите каталог .config в домашній директорії).

Тепер все готово для установки віртуальної машини. З меню додатків запускаємо Virt Manager (менеджер віртуальних машин):

Натискаємо правою кнопкою на рядку localhost і вибираємо деталі. Переходимо на вкладку сховище. Нам потрібно вказати каталог (або розділ диска / диск) для зберігання віртуальних машин.

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

на вкладці Мережеві інтерфейси, Можете перевірити, чи все працює.

тепер натискаємо Файл - New virtual machine. Вказуємо шлях до образу диска, тип віртуальної машини. Далі вказуємо кількість оперативної пам'яті для неї і кількість ядер процесора. Далі вказуємо наше сховище і натискаємо новий том . Вказуємо назву, тип залишаємо qcow2, І розмір. Це буде віртуальний жорсткий диск. Якщо плануєте встановлювати систему з графічною оболонкою і купою програм, дайте місця побільше (гигов 50). На останній вкладці ставимо галочку на Змінити налаштування перед запуском, Перевіряємо що в якості мережевого пристрою обраний наш міст, пишемо будь-яку назву для виртуалки і тиснемо завершити. Перед вами відкриється вікно параметрів цієї віртуальної машини.

Переходимо на вкладку процесор, І ставимо галочку на Скопіювати настройки процесора хост-системи.

Далі на вкладку Мережа (Наступна), і також вказуємо vitio. на вкладці дисплей вкажіть Spice, А на вкладці Відео - QXL. Зазвичай ця зв'язка забезпечує максимальну продуктивність відтворення графіки, але, якщо хочете, можете поексперементувати. Врахуйте, що для гостьових систем Windows, Потребує окремого встановлення QXL-драйвера (в самій Windows).

Тепер коли все готово, в лівому верхньому кутку тиснемо почати установку. І ставимо систему як зазвичай, за одним винятком: як тільки установник почне автоматично налаштовувати мережу, натисніть скасування, І виберіть Налаштувати мережу вручну. Вкажіть для виртуалки бажаний IP-адреса (у нашому випадку 192.168.0.3 ), Маску підмережі ( 255.255.255.0 ), Шлюз (шлюзом буде адреса хоста, тобто 192.168.0.2 ) І DNS-сервер (тут просто вкажіть Гуглівський 8.8.8.8 ). І все. Далі нічого робити не потрібно. Ставте систему і налаштовуйте. В общем-то, все. Описані дії - це спосіб замінити, скажімо, VirtualBox на більш кращу альтернативу. Прочитавши документацію, ви зрозумієте, наскільки широкі можливості Qemu-KVM. Я навмисно не став описувати тут додаткові консольні параметри і методи запуску віртуальних машин через термінал, так як це далеко не завжди потрібно на домашній машині. Про це я напишу окрему статтю, по налаштуванню домашнього багатофункціонального сервера (який також зможе виступати в якості сервера віртуальних машин). Для тих, хто з якихось причин не зрозумів написане, або залишилися незрозумілі моменти - пропоную подивитися ролик, в якому я вже не опишу, а покажу, як все це добро встановлювати і налаштовувати. Якщо у вас є пропозиції або доповнення до статті - пишіть в коментарях.

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

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

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 \u003d 1

Застосовуємо настройки:

sysctl -p /etc/sysctl.d/99-sysctl.conf

Створення віртуальної машини

Для створення першої віртуальної машини вводимо наступну команду:

virt-install -n VM1 \\
--autostart \\
--noautoconsole \\
--network \u003d bridge: br0 \\
--ram 2048 --arch \u003d x86_64 \\
--vcpus \u003d 2 --cpu host --check-cpu \\
--disk path \u003d / kvm / vhdd / VM1-disk1.img, size \u003d 16 \\
--cdrom /kvm/iso/ubuntu-18.04.3-server-amd64.iso \\
--graphics vnc, listen \u003d 0.0.0.0, password \u003d vnc_password \\
--os-type linux --os-variant \u003d ubuntu18.04 --boot cdrom, hd, menu \u003d on

VM1 - ім'я створюваної машини;
autostart - дозволити віртуальній машині автоматично запускатися разом з сервером KVM;
noautoconsole - не вдалося підключитися до консолі віртуальної машини;
network - тип мережі. В даному прикладі ми створюємо віртуальну машину з інтерфейсом типу «мережевий міст». Для створення внутрішнього інтерфейсу з типом NAT вводимо --network \u003d default, model \u003d 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 \u003d 5901.

Запускаємо TightVNC Viewer, який ми встановили і вводимо дані для підключення:

Кількома по Connect. На запит пароля вводимо той, що вказали при створенні ВМ, ( vnc_password). Ми підключимося до віртуальної машини віддаленої консоллю.

Якщо ми не пам'ятаємо пароль, відкриваємо налаштування віртуальної машини командою:

І знаходимо рядок:

* В даному прикладі для доступу до віртуальної машини використовується пароль 12345678 .