Це страшне слово - «віртуалізація». Моє рішення на базі KVM.
- система віртуалізації повинна бути стабільною, загальнодоступною і невибагливої до ресурсів.
Від вибору розбігаються очі, але після вивчення відгуків в інтернеті і спроб використання склалося суб'єктивної думку.
Продукти VMWare не підходять. Workstation платна, ESXi не вдалося поставити на мою систему через непідтримуваного чіпсета (він у мене виявився більш сучасним). Непоганим вибором був би VMWare Server, але судячи по відкликає вона важкувата і періодично падає, сам я не став пробувати після невдачі з ESXi. Чи не підійшли вони ще з однієї причини - компанія все таки продає свої продукти і тільки частина з них доступна у вільному доступі.
VirtualBox виявився вельми вдалим варіантом. Існує в двох варіантах - OSE і Freeware. У відкритому доступі початкових кодів Freeware-версії немає, зате компенсується це функціональністю. З відомих мені відмінностей - це відсутність в OSE версії підтримки USB, обмеження при роботі з мережею, Неподдерживается графічна акселерація (до речі, дає вельми пристойний приріст швидкості роботи віртуальної машини). VirtualBox ідеально підходить для найпростішої реалізації, тому що дозволяє швидко отримати працездатну віртуальну машину без зайвих рухів тіла і уважного вивчення керівництва. Приємною особливістю виявилася підтримка роботи з консолі, що дозволяє не використовувати графічних надбудов і відповідно знімається додаткове навантаження на хост-машину. Для початківців «домашніх віртуалізатор» я б порадив саме такий варіант. Особисто я до сих пір його використовую на особистому ноутбуку для швидкого піднімання тестового середовища, а також для роботи в Windows (там вже давно і стабільно влаштувалася Ubuntu в якості основної системи). За суб'єктивним відчуттям працює VirtualBox набагато спритніше VMWare Workstation, займає менше місця як на диску, так і в пам'яті. Для кожної машини виділяється окреме вікно, а також при встановлених драйвера в гостьовій системі (тобто «з коробки») є можливість інтегрувати в робочий стіл хоста, що дуже зручно і дозволяє рознести завдання на різні віртуальні столи.
QEMU - дуже потужна штука. Але коли згадав про неї, вже звернув увагу на віртуалізацію на базі ядра і інформацію про Xen і KVM, тому близько знайомиться з чистим QEMU не став.
Xen - ідеальна система для віртуалізації. Але має досить істотний недолік - гостьова система повинна бути заздалегідь підготовлена.
KVM, базується на QEMU, за швидкістю майже не поступається Xen, зате має більш гнучкою функціональністю, усією міццю налаштувань QEMU (хоча основна частина необхідних мені була і в VirtualBOX). Обидва варіанти, Xen та KVM реалізовані у всіх сучасних дистрибутивах і для використання не треба докладати серйозних зусиль. Але є між ними принципова відмінність, про який піде мова далі.
- необхідно мати можливість відтворити на віртуальних машинах різні програмні платформи.
Незважаючи на доступність в цьому плані продуктів VMWare і VirtualBOX, від їх використання я відмовився ще раніше, так що розглядати не буду ... А ось стосовно Xen і KVM опишу трохи докладніше, тому що сам шукав інформацію вельми довго.
Xen не дозволяє запускати системи відмінні від хостовой. а точніше не підготовлені заздалегідь для роботи в віртуальному середовищі. І на жаль (а може на щастя), подібній обробці не піддаються дистрибутиви Windows. Що мене не влаштовувало, тому в підсумку вибір припав на варіанті використання KVM, для якого заздалегідь готувати гостьову систему не треба.
Отже причини вибору KVM коротко:
1. Реалізація доступна з коробки в будь-якому великому дистрибутиві;
2. Реалізовано на базі ядра Linux, відповідно володіє великою швидкістю;
3. Використовується такими гігантами, як RedHat і Ubuntu, що говорить про високу стабільність і гнучкості;
4. Не потрібно додаткових махінацій з гостьової системою для установки в віртуальну машину.
3. Як я зробив це на Debian.
Далі піде більше технічний опис, яке описує по кроках, як я зробив свій сервер, вільно тягне з десяток віртуальних серверів.
Незважаючи на те, що мій улюблений дистрибутив Ubuntu, в результаті під базову системи був обраний Debian. В рамках статті пояснювати тонкощів не буду, що й до чого, але на робочому столі я все також вважаю за краще використовувати Ubuntu. Більшість інструкцій для Ubuntu і Debian актуальні для обох варіантів, тому під час налаштування я використовував і це і те і інше.
Отже, почнемо ставити сервер.
Беремо дистрибутив Debian. Щоб не качати зайвого потім і відразу отримати свіжу систему, я брав варіант netinstall, за допомогою якого встановлював тільки варіант «Стандартна система», більшого нам і не треба. До речі, я використовую 64-бітний випуск, щоб отримати підтримку більшої кількості оперативної пам'яті (> 3 Гб) без обхідних шляхів і викрутасів (наприклад, 32-бітове серверне ядро дистрибутива Ubuntu підтримує більше, ніж 3 Гб, але тільки при наявності такої можливості в чіпсеті ).
Я використовую під системні розділи ( «/», «/ home», swap) жорсткий диск IDE, щоб не мати проблем при роботі системи при установці на RAID-масив (а вони є). При установці відразу створюю RAID-1 на основі двох жорстких дисків SATA для досягнення більшого збереження даних (основна інформація буде зберігатися на ньому). Надалі для роботи з СОФТОВА RAID-масивом слід використовувати утиліту mdadm.
Свіжовстановленому систему я трохи ретушує. Для початку встановлюю ssh, щоб можна було відразу засунути системник подалі і відключити від нього вже непотрібний монітор: sudo apt-get install ssh Багато радять переключити порт з стандартного 22 на інший. Але це слід робити тільки в тому випадку, якщо ви впевнені в своїх діях і ваш сервер підключений безпосередньо до інтернету. До речі, слід згадати, що якщо буде використовуватися нестандартний порт, то потім виникнуть складнощі з віддаленим керуванням KVM-виртуализацией. Тому я залишив стандартний порт, але через апаратний маршрутизатор зробив перекидання на нестандартний, доступний зовні.
Потім включаємо синхронізацію часу через інтернет (настійно раджу, стане в нагоді).
sudo apt-get install ntp ntpdate
Для контролю температури чіпсетів, процесора і жорстких дисків:
sudo apt-get install lm-sensors hddtemp
Утиліта hddtemp працює відразу, для настройки lm-sensors запускаємо після установки: sudo sensors-detect відповідаємо на всі питання ствердно.
Використовувати дуже просто:
- дізнатися температуру процесора, чіпсета і інших характеристик sudo sensors отримуємо щось на кшталт:
it8712-isa-0290
Adapter: ISA adapter
VCore 1: +1.33 V (min = +3.54 V, max = +3.30 V) ALARM
VCore 2: +3.76 V (min = +1.39 V, max = +1.01 V) ALARM
+3.3V: +3.28 V (min = +4.00 V, max = +0.91 V) ALARM
+5V: +6.69 V (min = +3.04 V, max = +6.10 V) ALARM
+12V: +12.67 V (min = +15.23 V, max = +5.57 V) ALARM
-12V: -15.33 V (min = -0.85 V, max = -12.39 V) ALARM
-5V: +2.85 V (min = +3.06 V, max = +3.47 V) ALARM
Stdby: +5.99 V (min = +0.11 V, max = +6.37 V)
VBat: +3.31 V
fan1: 2 922 RPM (min = 3260 RPM, div = 2)
fan2: 0 RPM (min = 5400 RPM, div = 2) ALARM
fan3: 0 RPM (min = 2732 RPM, div = 2) ALARM
M / B Temp: + 44.0 ° C (low = -73.0 ° C, high = -49.0 ° C) sensor = transistor
CPU Temp: + 32.0 ° C (low = -65.0 ° C, high = -9.0 ° C) sensor = transistor
Temp3: + 128.0 ° C (low = + 23.0 ° C, high = -66.0 ° C) sensor = disabled
cpu0_vid: +0.000 V
- дізнатися температуру 1 жорсткого диска SATA - sudo hddtemp / dev / sda отримуємо щось на кшталт:
/ Dev / sda: WDC WD1001FALS-00J7B0: 33 ° C
І найсмачніше, встановлюємо KVM модулі і корисні утиліти. Відразу додамо поточного користувача до відповідної групи для доступності використання KVM. Опис використання утиліт можна знайти за тим самим зазначеним посібникам. sudo aptitude install kvm libvirt-bin virtinst virt-top python-virtinst
sudo adduser softovick libvirt Фактично відразу можна використовувати. Описувати всі команди сенсу не бачу, для цього є man. Але покажу, як я створюю віртуальну машину:
для Linux virt-install -n linux -r 512 -f linux.img -s 15 -c образ.iso --accelerate --vnc --vncport = 5900 --noautoconsole --os-type = linux --os-variant = generic26
для Windows virt-install -n windows -r 512 -f windows.img -s 15 -c образ.iso --accelerate --vnc --vncport = 5901 --noautoconsole --os-type = windows --os-variant = win2k3 --noacpi Після цього подальший хід установки і екран гостьової машини можна контролювати, підключившись за допомогою VNC-клієнта до сервера по порту 5900 і 5901 (рекомендую для кожної машини заздалегідь визначати порт VNC, щоб було зручно підключатися). Є ще кілька корисних опцій, я їх не використовую лише тому, що не зіткнувся з їх необхідністю.
P.S .:
Деякі корисні поради:
1. Якщо ви вказали конкретний порт VNC для гостьової машини, то через Virtual Manager ви не зможете автоматично запустити графічну консоль.
2. Virtual Manager не зможе підключитися, якщо у вас перевизначений порт ssh. Точніше для цього доведеться довго і нудно розбиратися.
3. Обов'язково використовуйте для гостьової Windows Server режим -noacpi, щоб вона нормально встановилася.
4. Акуратно налаштовуйте режим заощадження енергії на гостьових системах, ні в якому разі не відключайте екран, інакше не зможете потім підключиться по VNC.
5. Якщо ви хочете віддалено вимикати і перезавантажувати машини через Virtual Manager, то відключайте хранитель екрану, тому що він блокує управління живленням.
Величезне спасибі за статтю! Багато корисного. Сам в даний момент вирішую питання віртуалізації на «домашньому сервері».