Технології віртуалізації: вчора, сьогодні, завтра (стр. 4 из 8)

У нас є якісь апаратні ресурси, які треба імітувати. В архітектурі x86 їх, загалом-то, всього три:

· Регістри процесора (включаючи регістри службового призначення).

· Порти введення-виведення (що використовуються для обміну інформацією з периферією).

· Оперативна пам'ять.

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

Але є кілька неприємних винятків. Ось, приміром, уже згадуваний регістр CR3, керуючий таблицею трансляції оперативної пам'яті. Власне, знаючи «віртуальне» значення CR3, «базовою» операційній системі неважко зімітувати власне таблицю трансляції: достатньо пов'язані з цієї таблиці області віртуальної пам'яті помітити за допомогою P-прапора, отримати таким чином перехоплення всіх звернень до цієї таблиці, та синхронізувати реальну таблицю трансляції з віртуальною, яку гостьова операційна система приймає за реальну (техніка «тіньових таблиць трансляції», Shadow Page Table). Але при цьому, на жаль, потрібно якось обманювати гостьову операційну систему, «підсовуючи» їй «віртуальний CR3» замість реального, а коштів відповідного апаратного контролю звичайний x86-процесор не надає.

Схема 6. Віртуалізація з гостьовими ОС.

Ще одна проблема з тієї ж серії - внутрішній регістр процесора, що відповідає за «рівень привілеїв» поточного запущеного додатку. Процесор використовує його, щоб перехоплювати спроби звернення «звичайних» додатків до «небезпечним», «недозволеним» інструкцій і областях пам'яті; призначається цей рівень привілеїв операційною системою. Таких рівнів всього чотири; про додатки із заданим рівнем привілеїв говорять, що вони працюють у відповідному кільці. Чим менше чисельне значення даного параметра, тим більше можна відповідним додатків. У кільці 0 (Ring 0), приміром, працює операційна система і (зазвичай) драйвера операційної системи; в кільці 3 (Ring 3) - «звичайні» користувальницькі додатки. Так от: довіряти «гостьовий» операційній системі нульове кільце не можна - інакше неможливо буде перехоплювати деякі його дії, оскільки в нульовому кільці «дозволено все» і багато перевірки безпеки просто не працюють. Але оскільки гостьова операційна система, природно, за замовчуванням припускає, що її потрібно запускати саме в нульовому кільці, а перевірити цей факт особливої праці не представляє, то цілком природно, що при спробі її запуску в будь-якому іншому кільці додаток-віртуалізатор доб'ється хіба що повідомлення про помилку. Тому, строго кажучи, повноцінну імітацію «фізичного» комп'ютера за допомогою апаратних ресурсів віртуалізації в x86 не можна. Кажуть, що не виконано критерій самовіртуалізіруемості Попека і Голберга (Popek and Goldberg self-virtualization requirements).

Як же тоді працюють «віртуалізатор» типу VMWare? Досить нетривіальним чином. Віртуалізатор злегка «підрізає крила» коду виконується під його керуванням операційної системи, на льоту дізассембліруя її код і замінюючи «погані» інструкції (на кшталт читання-запису регістра CR3) нейтральними з її точки зору (це називається динамічної трансляцією; dynamic recompilation). Зробити це, м'яко кажучи, не так вже просто, а гарантувати працездатність що виходить на виході результату - ще складніше. Приплюсуйте сюди задачку імітації софтом віртуального x86-комп'ютера (що вимагає реалізації спеціального складного драйвера), і ви отримаєте уявлення про те, чому «віртуалізується ПЗ» для x86 до цих пір не відрізнялося ні особливою надійністю, ні особливою продуктивністю. На жаль, але в архітектурі IA-32 з її з самого початку непоганий віртуалізаційних функціональністю спочатку була закладена здоровенна «дірка», яку можливо обійти тільки з великими труднощами.

Цікаво, до речі, що в що прийшла на зміну IA32 технології AMD64/Intel EM64T, виправити більшість невдалих і тонких місць архітектури, що веде свій родовід аж з процесора Intel i80386, цю «віртуалізаційних дірку» ні Intel, ні AMD так і не закрили! Замість цього вони абсолютно незалежно один від одного випустили дві абсолютно несумісні один з одним «заплатки» до AMD64 і EM64T відповідно, по-різному що полегшують життя розробникам віртуалізаційних ПЗ.

b) VMWare Workstation і VMWare Server

У Росії ім'я VMWare є практично синонімічним для «програмного забезпечення для віртуалізації». Саме ця компанія в 1999 році вперше вивела на ринок успішний продукт, що забезпечував для операційних систем виробництва Microsoft можливість запуску віртуальних машин з «чужими» операційними системами. Правда, в 2003 році VMWare була скуплена корпорацією EMC2, до складу якої з тих пір і входить, проте свого існування як самостійного гравця з розкрученим брендом вона з тих пір не припинила. І поточна політика керівництва EMC2 полягає в тому, щоб VMWare і далі працювала на ринку як самостійна одиниця, впливати на стратегію і тактику якого EMC особливо не буде.

На сьогоднішній день VMWare пропонує три лінійки базового і деяку кількість супутнього віртуалізаційних ПЗ (таблиця-ца 1). Перша лінійка, VMWare Workstation 5.5 орієнтована насамперед на звичайних розробників, запускаючих на своєму комп'ютері декілька операційних систем одночасно. Друга, VMWare Server GSX 3 - практично ідентична першої по основній функціональності, але орієнтована вже на серверне застосування в якості засобу організації безлічі захищених віртуальних серверів на одному фізичному. Існують версії обох пакетів для Windows 2000/XP/2003 та основних дистрибутивів Linux. Третя лінійка, VMWare Server ESX 2 коштує дещо окремо, оскільки орієнтована не на запуск в якості звичайного додатки в «батьківського» операційній системі, а, фактично, реалізує свою власну операційну систему, в якій запускається одно-єдина програма - власне віртуалізаційних ПЗ. Область застосування Server ESX приблизно та ж, що і у Server GSX, але ESX орієнтована на великі дата-центри, що вимагають особливої надійності від віртуалізується ПЗ.

Конфігурація віртуальних машин у VMWare більш ніж гідна. Ресурси процесора доступні віртуальній машині в повному обсязі (якщо на «батьківського» машині коштує Pentium 4 - в імітованих комп'ютері буде стояти точно такий же процесор); обсяг оперативної пам'яті - практично необмежений (до 3,6 Гбайт на кожну віртуальну машину); підключаються безпосередньо або імітуються стандартні IDE-пристрої (жорсткі диски та оптичні накопичувачі у вигляді файлів на диску), підтримується пряме підключення SCSI-адаптерів і імітація SCSI-дисків, підключених через контролер LSI Logic Ultra160 або Mylex BT-958. Відеокарта - абстрактний графічний адаптер VGA / SVGA. Підтримується і емулюється до двох флоппі-дисків, до чотирьох COM-портів, UCHI-контролер на 2 порти USB 1.1; до двох паралельних LPT-портів, стандартна 104-кнопкова клавіатура і миша PS / 2. Підтримується до чотирьох віртуальних мережевих карт (AMD PCnet) і навіть віртуальна локальна мережа, що складається з довільного числа хостів і до дев'яти віртуальних світче. Загалом, звання лідера VMWare утримує цілком заслужено.

VMWare використовує у своїх продуктах класичну технологію «бінарної трансляції»; в останні версії ПЗ включена і експериментальна підтримка технології віртуалізації Intel VT-x. Підтримка технології віртуалізації AMD «Pacifica» обіцяна в самому найближчому майбутньому. До речі, саме продукти VMWare корпорація Intel використовувала ще рік тому для публічних демонстрацій (наприклад, в рамках Intel Developer Forum) майбутніх можливостей своїх процесорів з Virtualization Technology, тоді ще не оснащених блоками VT. І, слід зазначити, що, наприклад, на трехгігагерцовом процесорі Intel Xeon (ядро Nocona) робота такої віртуальної системи не відрізнялася особливою прудкістю, в чому нам довелося переконатися особисто.

с) Microsoft VirtualPC / Virtual Server

На відміну від VMWare, Microsoft ніколи до ладу не розробляла власних систем віртуалізації: що випускаються сьогодні під її брендом VirtualPC і Virtual Server спочатку були розроблені компанією Connectix. Але в 2003 році Microsoft скупила дані продукти у Connectix, що називається, «на корені», і з тих пір приблизно та ж команда розробників випускає лише злегка «підрихтувати» колишні продукти Connectix під Microsoft-івської маркою. Однією з сторін подібного переходу «під крило» Microsoft стало те, що відтепер VirtualPC працює виключно під управлінням десктопних версій ОС Windows XP/2000, а більш функціональний Virtual Server - і зовсім тільки під управлінням серверних Windows XP/2003 Server.

Спочатку віртуалізаційних ПЗ Microsoft був орієнтований на використання технології бінарної трансляції коду. Виняток - VirtualPC for Macintosh, який формально також використовує ту ж технологію бінарної трансляції, але по суті своїй є, швидше, просунутим емулятором (див. нижче). У 2005 році Microsoft також заявила про підтримку в своїх майбутніх продуктах технологій Intel VT-x та AMD SVM «Pacifica», проте бета-версії відповідних продуктів вийдуть лише в першій половині 2006 року, а остаточний реліз - у другій половині.