Інтерес користувачів до віртуалізації останнім часом став пропадати. З одного боку, є зрозумілі десктопні рішення під будь-яку вісь. З іншого - вартість VDS не так вже й висока, а сервер доступний всім, можна демонструвати розробки з будь-якої точки. Але якщо з Linux все більш-менш ясно і вибір є, то Windows-хостинги пропонують далеко не всі, їх вартість висока (приблизно в два рази дорожче) і брати їх, коли така система потрібна рідко, не має сенсу. Ось тут нас може виручити знання KVM.
Плюси і мінуси KVM
Технологія надає повну віртуалізацію на апаратному рівні. Тому, на відміну від популярних LXC і OpenVZ, KVM може запускати в принципі будь-яку ОС, не тільки Linux (Windows, FreeBSD ...), і Linux, що відрізняється від конфігурації основної системи. Якщо потрібна віртуальна машина, не збігається параметрами з основним хостом, то вибору особливо немає. Включення в ядро було великим проривом. Тепер підтримка віртуалізації в ОС не вимагала установки гипервизора (як Xen) і могла бути реалізована в будь-якому дистрибутиві, включаючи настільний. З коробки доступний VNC, що дає можливість управляти віртуальним сервером з моменту завантаження (тобто коли ще не працює SSH), як ніби з локальної консолі. Проект активно співпрацює з іншим подібним рішенням QEMU. задіяні деякі утиліти і загальний формат файлу образу Qcow2.
Мінуси, звичайно, теж є. Куди ж без них. Головний - процесор повинен мати апаратну підтримку віртуалізації Intel VT-x або AMD-V. Перевірити їх наявність можна вручну або за допомогою утиліт:
Також про підтримку технологій говорять прапори в CPU:
Залежно від виробника процесора буде завантажений свій модуль ядра (kvm-amd.ko або kvm-intel.ko).
Перевіряємо підтримку KVM
Накладні витрати трохи вище, ніж при використанні LXC і OpenVZ. Причин тому дві.
KVM-контейнер запускає свою копію ядра і оточення, і під них потрібно пам'ять. LXC і OpenVZ ж використовують ядро і системні виклики сервера. Тому при однакових характеристиках на хостингу у них абсолютно різні можливості. При створенні KVM-контейнера під нього відразу резервуються всі ресурси згідно з настановами. Це добре видно в htop. Варто додати ОЗУ в KVM, як відразу на це значення збільшується обсяг використаної пам'яті. Вийти за ліміти VM не може, вони встановлюються жорстко. У цьому навіть і плюс, можна відразу розрахувати майбутню навантаження на своєму сервері, а ресурси ніхто не запозичить.
І VM працюють відносно стабільно в плані продуктивності. У той час як при OpenVZ-віртуалізації ресурси виділяються динамічно в міру потреби і кожен віртуальний сервер використовує рівно стільки ресурсів, скільки йому зараз потрібно. Незайняті ресурси залишаються вільними. Тому він і популярний у хостерів, адже можна завжди напхати трохи більше VM, і саме тому віртуальні машини, створені з запасом, можуть працювати то швидше, то повільніше. Іноді оптимізація VM під OpenVZ - справжня мука: незрозуміло, чому сервер став працювати по-іншому - через нові налаштувань або зовнішніх чинників.
Адмініструвати KVM складніше, так як прозорий доступ до файлів, процесів, консолей і мережі контейнерів відсутня, це доводиться налаштовувати самостійно. Перебудова параметрів VM в KVM (CPU, RAM, HDD) не надто зручна і вимагає додаткових дій, що включають перезавантаження ОС. У тому ж OpenVZ це можна зробити на льоту. Сам проект не пропонує зручних графічних інструментів для управління віртуальними машинами, тільки утиліту virsh, що реалізує всі необхідні функції. Але, пошукавши в Мережі, можна знайти кілька інтерфейсів, хоча для індивідуального використання однієї або декількох VM їх зазвичай ставити немає сенсу. До того ж багато open source проектів, активно розвивалися під час великого інтересу до віртуальних машин, сьогодні стали комерційними, хоча деякі як і раніше пропонують обрізану free-версію. У репозиторії пакетів є virt-manager. що пропонує графічний інтерфейс для управління KVM і іншими типами VM, що підтримують virtlib, як встановлених локально, так і віддалено через SSH.
Як веб-інтерфейсів можна порекомендувати старенький, але ще робочий WebVirtMgr. безкоштовний UVMM UCS Core Edition. openQRM Free Community Edition і інші. Крім того, існують спеціальні дистрибутиви начебто Proxmox VE. в якому всі необхідні інструменти для створення і управління VM на базі KVM і LXC вже є (правда, він підходить для bare metal установки, а не на віддалений VDS).
установка KVM
Плюси KVM в тому, що вона працює з коробки і що процесори серверів хостерів однозначно підтримують цю технологію. Тому цілком реально при наявності вільних ресурсів довантажити в VDS ще одну віртуальну машину (або кілька). Звичайно, під фактично подвійний виртуализацией вони будуть працювати не так швидко, як на залозі, але якщо велике навантаження не планується, то цього цілком повинно вистачити. Більш того, у деяких хостингів є rescue-інструменти, що дають можливість подмонтировать іншу файлову систему (в hetzner це rescue / LARA), підмінити наявну і навіть встановити свою ОС. При деякому умінні можна за тарифами Linux абсолютно легально використовувати Windows.
Перевіряємо підтримку KVM.
Якщо така відповідь отримано, значить, все нормально. Список підтримуваних ОС і їх правильна назва можна отримати за допомогою osinfo-query.
Файли libvirt знаходяться в каталозі / etc / libvirt. журнали, в яких потрібно шукати відповіді на проблеми, розміщуються в / var / log / libvirt. В / var / lib / libvirt кілька каталогів: в boot система, якщо не вказано шлях, буде шукати спосіб для установки гостьової системи, а в images розміщувати жорсткі диски.
Управління віртуальними машинами з консолі проводиться за допомогою утиліти virsh. Параметрів багато, їх всі можна дізнатися, ввівши:
Спочатку просто варто пройтися і познайомитися, щоб зрозуміти суть. Список ОС поки порожній:
Перевіряємо, що мережа налаштована. За замовчуванням використовується default (докладніше далі по тексту).
Якщо у відповідь отримуємо, що неможливо підключитися, перевіряємо права доступу на сокет і каталоги вище (в основному в цьому проблема).
І перезавантажуємо модулі:
Ще один момент. Для роботи Win будуть потрібні паравіртуальние драйвери virtio, які реалізують роботу основних пристроїв в віртуальному оточенні. Вони не є обов'язковими, але їх використання дозволяє досягти більшої продуктивності і чуйності в роботі віртуальних оточень. Вони повинні підтримуватися як хостом, так і гостьовий ОС. У ядрі Linux драйвер підтримується з 2.6.25, але модуль за замовчуванням не ставиться. Якщо виклик / sbin / lsmod | grep virtio і cat "/ boot / config- uname -r" | grep -i virtio нічого не показав, слід встановити пакет qemu-guest-agent. Для гостьової ОС ISO-образ доступний на fedoraproject.org.
Далі два варіанти. Можна самостійно встановити операційну систему або взяти вже готовий образ зі встановленою ОС. Перший крок в загальному відрізняється тим, що потрібно підготувати диск, запустити VM і встановити ОС стандартним способом. Створимо диск розміром 25 Гбайт.