Зазвичай користувачі "Лінукса", вдосталь наперезагружавшісь назад в Windows, починають думати, який поставити віртуалізатор: VirtualBox, VMWare або щось ще? Не поспішайте. Встановивши "Лінукс", а, швидше за все, це Ubuntu, ви, можливо, поставили і віртуальну машину. Все залежить від "заліза" і від. вас!
Про те, що таке віртуальна машина (ВМ), що має власну ОС, "Вести" писали неодноразово. Серед користувачів найбільшим спонуканням для установки ВМ в комп'ютер є проста цікавість до нових ОС або, навпаки, бажання без перезавантаження запускати "віндового" додатка після установки ОС Лінукс. Але це далеко не єдина перевага ВМ. Особисто мені дуже подобається "внежелезность" ВМ; ВМ на зовнішньому носії - це верх приватності і ізольованості. Вийняв носій - і ніякої експерт нічого не нариє.
Однак за все треба платити: кожна ВМ займає ресурси комп'ютера. І, як буде показано, необхідно, щоб процесор підтримував ВМ апаратно. Але користувачі купують вже 4-х-ядерні комп'ютери, а більша частина вже йдуть в історію 2-х-ядерники і деякі одноядернікі теж мають такі процесори! Тому продовжимо.
Всі способи організації ВМ базуються на апаратно-програмному дуалізм: апаратні обчислення можна виконувати програмно, і навпаки.
Самий універсальний спосіб створення ВМ - емуляція апаратного забезпечення реального "заліза" програмними засобами. При цьому в пам'яті машини-господині ( "хоста" на сленгу) відтворюється образ реального процесора з усіма його регістрами та іншими атрибутами, а хост віддає ВМ частину свого пам'яті і дискового простору. Якщо при цьому емулюються і пристрої введення-виведення, то це - "чиста віртуалізація". Працює вкрай повільно. Приклад - емулятор QEMU, до якого ми ще повернемося.
А чому гостьова ОС не може працювати на реальному процесорі і використовувати реальні фізичні пристрої (останнє на сленгу називається "прокинути" пристроїв)? На жаль, на одному комп'ютері архітектури x86 не можна змусити працювати дві ОС одночасно. Введення-виведення спочатку спроектований для монопольного використання лише однієї ОС, і як віртуальному процесору, що працює в третьому колі привілеїв, виконувати інструкції рівня ядра ОС хоста? Вихід: треба підселити в нульовий коло щось, що перехоплювало б виключення, що викидаються при спробах виконання "поганих" інструкцій і виконувало їх як би від імені основний ОС. Це "щось" носить назву "гипервизор". Саме він і здійснює кидок введення-виведення на фізичний рівень. Але в коді ядра гостьової ОС є ще і непривілейованих інструкції, які по-різному поводяться в залежності від контексту виконання і не піддаються перехоплення, так як виключення не генеруються. І знову виручає гипервизор. можна змусити його переглядати гостьовий код "на льоту" до виконання і підміняти "погані" інструкції набором "хороших". Цей спосіб віртуалізації отримав назву "повна віртуалізація". Вона, як і "чиста", спочатку захищена: код гості виконується в просторі користувача і не може пошкодити ОС хоста. Але і тут ВМ працює повільніше реального прототипу: так як виконуваний код походу правиться, то на цьому втрачається час. Існує два способи уникнути правки коду "на льоту".
Другий спосіб більш дієвий і називається "апаратна віртуалізація". При цьому методі робота гипервизора по відстеженню "поганих інструкцій" виконується апаратно самим процесором хоста (дуалізм!) В особливому гостьовому режимі. На це здатні процесори, що підтримують технології Intel VT або AMD SVM. Швидкість роботи ВМ мало поступається швидкості оригінальної машини. Правда, Intel VT і AMD SVM - не одне й те саме. У интеловский підході в процесор введені 10 нових інструкцій для управління гостьовим режимом і доступу в VMCS (керуюча структура, знаходиться в пам'яті), куди попередньо заносяться "правки". У AMD все реалізовано ще більш апаратно. В обох системах виловлювання "поганий" інструкції проводиться шляхом її апаратної дешифрування в гостьовому режимі (докладніше див. Xakep.ru/post/51718/default.asp). Існують два різновиди апаратної віртуалізації: з підтримкою інструкцій введення-виведення "VT-d плюс VT-x" і без неї - тільки VT-x. Зрозуміло, що більш глибока підтримка дає приріст в швидкості обміну з ВМ.
Щоб дізнатися, чи підтримує процесор вашого комп'ютера апаратну віртуалізацію, введіть в терміналі наступну команду:
egrep -c '(vmx | svm)' / proc / cpuinfo
Для роботи KVM потрібен емулятор QEMU, але QEMU працює і без KVM. ОС Windows під чистим QEMU на середньому двухядерніке працює так, як якщо б вона працювала на якомусь древньому P2-350. Зате список комп'ютерів, емульованого QEMU, дуже широкий. При запуску KVM + QEMU гостьова ОС прискорюється у багато разів, але емулюються тільки комп'ютери Intel VT і AMD SVN, зате список гостьових ОС все ж ширше, ніж в інших віртуалізатор.
У QEMU можна встановити практично будь-яку ОС, яка "бачить" емульований процесор, диски, які насправді є великим файлом в хості, "бачить" емульованого мережеву карту і т.д. Після виключення ВМ все це залишається в хості як один великий файл під назвою чином гостьовий ОС. Його ще називають віртуальним диском. Файл цей має розширення img. QEMU встановлюється з репозиторіїв тривіальної командою sudo apt-get install qemu. Для чистого QEMU розроблено кілька GUI: QtEMU, KQEMU і інші, але вони застаріли і не працюють з KVM. Якщо пригнічують термінальні команди, то відразу переходите до наступного розділу статті, ми ж коротко розглянемо ті з команд, які найбільш важливі для розуміння ідеології QEMU. Взагалі ж детальну документацію англійською мовою по термінальним командам для QEMU можна подивитися тут: wiki.qemu.org/download/qemu-doc.html.
Щоб в хост встановити образ ОС нової ВМ, спочатку готують для гості місце в вигляді порожнього образу віртуального диска, на якому гостя буде розміщена. Для створення образів віртуальних дисків і управління ними QEMU розпорядженні командою qemu-img, яка підтримує різні формати віртуальних дисків. Якщо спеціально не вказувати, який саме формат треба створити, то за замовчуванням QEMU буде працювати з файлом у так званому сиром форматі raw. Ось синтаксис термінальній команди qemu-img create, що створює порожній образ віртуального диска:
qemu-img create myimage.img mysize
qemu-img create -f qcow2 winxp.img 10GB
Після того, як для гостьової ОС підготовлений порожній образ диска, на нього встановлюють цю ОС з ISO-образу, записаного на CD, DVD, флешці або жорсткому диску. Непорожній образ * .img машини-гості в подальшому можна буде використовувати багаторазово, при цьому вихідний ISO-образ гостьовий ОС стає зайвим. Установку гостьовий ОС можна виробляти і з Інтернету. В Інтернеті є безліч ISO-образів різних ОС, можна скачати вподобану і встановити як гостьову, що не пропалюючи CD, взявши образ, наприклад, звідси: wiki.qemu.org/Download #QEMU_disk_images. Звичайно, можна встановити ОС і з завантажувального диска, що містить, наприклад, файл WinXPSP3.iso. Щоб прискорити установку, з ISO-образу записують на інший CD містяться в ньому файли. Після того, як ISO-образ вставлений в CD-привід і CD автоматично змонтувати, установка Windows може бути розпочато такий рядком в терміналі:
qemu -m 696 -hda winxp.img -cdrom /media/WinXPSP3/WinXPSP3.iso -boot d
Отже, запустилася установка ОС: відкрилося вікно QEMU, пішла розмітка порожнього способу winxp.img під NTFS, копіюються файли, инициализируется конфігурація майбутньої Windows, система просить рестарту, але кнопки рестарту віртуальної машини немає, і вона висить в очікуванні. Тепер треба запустити завантаження гості з віртуального диска C: (він створився!), Зберігши, проте, доступ до джерела, тобто до CD-приводу, інакше сервіс-пак SP3 виявиться невидимим. Тому закриваємо вікно QEMU, міняємо в CD-приводі ISO-диск на диск з нормальними установочними файлами і в терміналі даємо команду:
qemu -m 696 -hda winxp.img -boot c -cdrom / dev / cdrom
На час установки слід запастися терпінням: кожна віртуальна хвилина дорівнює кільком реальним - емулятор все-таки. Якщо є 2 екрани, то доцільно перемістити вікно QEMU на інший екран, щоб наглядати за установкою гості і займатися своїми справами на першому екрані. На сучасному комп'ютері потрібно годину-півтора. Нарешті, гостьова ОС встала! Можна запустити її всередині "Лінукса", що виконується наступною термінальній рядком:
qemu -m 696 -boot c
KVM налаштовується точно так же, як і QEMU, але слово qemu замінюється словом kvm. CLI жахливий, чи не так?
На щастя для QEMU і KVM, є чудовий GUI, написаний на мові QT4 фахівцями з Nokia; називається він AQEMU, лежить в репозиторіях, встановлюється тривіально: sudo apt-get install aqemu або ж мишкою за допомогою Центру додатків Ubuntu. У AQEMU все, що вище регулювали термінальними командами, налаштовується мишею. Щоб працювати з AQEMU, на вашому комп'ютері попередньо повинні бути встановлені бібліотека Qt версії не нижче 4.4.2 і емулятор QEMU версії 0.9.0 або вище. Російська документація знаходиться тут: sourceforge.net/projects/aqemu/files/AQEMU%20Russian%20Documentation/0.7.3/AQEMU-Documentation-0.7.3.tar.bz2/download. АQEMU в даний час також русифікований. Крім того, AQEMU має майстер першого запуску, який дозволяє відшукати всі встановлені на вашому комп'ютері емулятори: "Файл> Майстер першого запуску> Далі> Далі> Пошук".
Недоліки у KVM, звичайно, є. Перший підводний камінь: оновивши ядро машини-господині, ви несподівано виявляєте, що гостя під KVM відмовляється працювати. Так і повинно бути: гостя використовує старе ядро, якого вже немає. Тому після поновлення ядра господині доводиться або створювати образ гості знову, або, користуючись завантажувальним меню господині, завантажувати господиню з колишнім ядром. Втім, цей недолік властивий і повним емуляторам. Другий підводний камінь: не намагайтеся запустити інший віртуалізатор, скажімо, VirtualBox, якщо в пам'яті знаходиться працюючий модуль KVM. Його спочатку треба вивантажити з пам'яті командами sudo rmmod kvm і sudo rmmod kvm-intel (або sudo rmmod kvm-amd, якщо комп'ютер з процесором AMD). Нарешті, KVM укупі з QEMU допускає "нечесну" емуляцію, при якій ВМ вимагає ресурсів більше, ніж має ваш комп'ютер, наприклад, процесор ВМ містить більше ядер. При цьому замість прискорення ви отримуєте різке уповільнення.
Результати порівняння тестування KVM vs VirtualBox можна подивитися в phoronix.com/scan.php?page=articleitem=linux_kvm_virtualbox4num=1. При цьому VirtualBox також використовував апаратну віртуалізацію. У синтетичних тестах KVM явно перевершує VirtualBox. У той же час результати голосування "яка ВМ краще" свідчать про протилежне, ці результати наведені тут: ubuntuforums.org/showthread.php?t=1145462. Переміг VirtualBox. Парадокс? Ні. Справа в тому, що голосування більше відповідає рівню просунутості конкретних убунтоідов, ніж реальні гідності тієї чи іншої ВМ. Але це голосування цінне тим, що позиції учасників хоч якось аргументовані, при цьому користувачі нерідко зізнавалися: "KVM не пробував.". Так пробуйте ж!
Версія для друку