49268 (666202), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

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

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

Схема 5. Паравиртуализация

Другий спосіб дуже добре знаком «просунутим користувачам» згідно з додатками типу VMWare Workstation, що забезпечує успішний запуск на одному комп'ютері з-під «базової» операційної системи кількох «гостьових» операційних систем без спеціальної їх модифікації. «Гостьова» операційна система разом з усіма її додатками фактично стає одним «звичайним» додатком «батьківського» операційної системи, з-під якої вона запущена. Ідея тут дуже проста: використовуючи віртуальну пам'ять, ми можемо зімітувати віртуальний комп'ютер практично будь-якої складності: так що «гостьовий» операційній системі просто «підсовується» віртуальна машина, яка дуже схожа на «фізичну" x86-машину. «Гість» приймає «обманку» за справжній комп'ютер - і цілком успішно починає на цій віртуальній машині, імітованої «батьківського» ОС, працювати. Зверніть увагу, на те, що це не підхід, аналогічний «віртуальній машині Java» або емуляторам стародавнього Sinclair, коли програма-емулятор віртуальної машини «вручну» розбирає код додатку і «вручну» ж виконує кожну його інструкцію. Гостьова операційна система і всі запущені в її рамках програми працюють на фізичних ресурсах комп'ютера практично так само, як це робить звичайне запущене на ньому додаток, а «віртуалізується додаток» тільки забезпечує контроль над ним - тонюсінька прошарок коду, підтримана стандартними апаратними ресурсами комп'ютера. Давайте розберемо трошки детальніше, як таке виявляється можливим.

У нас є якісь апаратні ресурси, які треба імітувати. В архітектурі 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 року, а остаточний реліз - у другій половині.

У частині обладнання VirtualPC і Virtual Server імітують один і той же «стандартний комп'ютер» з процесором Pentium II (з підтримкою MMX), що працює на чіпсеті Intel 440BX, з відеокартою S3 Trio 64 PCI (з 4 Mb відеопам'яті), BIOS від American Megatrends (AMI), звуковою картою Creative Sound Blaster 16 PnP (Virtual Server її не підтримує), і мережною картою DEC 21041 / 21040. Конфігурація хоч і старенька, але вельми поширена в свій час, а тому має дуже непогану підтримку з боку програмного забезпечення.

2. Віртуалізація сьогодні і завтра: Intel VT і AMD «Pacifica»

Корпорація Intel пішла досить прямолінійнім шляхом, просто випустив «мінімально необхідну» латочку до x86. Повна назва «заплатки» - Intel Virtualization Techology for x86 (VT-x); Одночасно була випущено аналогічна віртуалізаційніх «технологія» для процесорів Intel Itanium (VT-i). Втім, розглядаті останню технологію ми не будемо, оскількі по суті своїй вона практично повністю аналогічна VT-x. Нагадаємо, що раніше дана технологія була відома під кодовими іменамі Vanderpool (для персональних комп'ютерів) і Silvervale (для серверів).

Що ж зробила Intel? Досить нетрівіальну, Хоча і напрошуються річ. Розробник архітектури IA-32 просто ввела в своїх процесора СПЕЦІАЛЬНИЙ «режим виконання віртуальної машини» (Virtual Machine eXecution mode, VMX), призначений спеціально для віртуалізаційніх ПЗ (Virtual Machine Manager, VMM), і визначена для ЦЬОГО режиму Кілька Ключовий «віртуалізаційніх» інструкцій, таких як, пріміром, «створити віртуальний комп'ютер» і «запустіті віртуальний комп'ютер». Власне цей самий «віртуальний комп'ютер» в VT-x опісується спеціальної структурою під назв VMCS (Virtual Machine Control Structure) і по суті своїй є невелика ділянкою фізичної оператівної пам'яті, що зберігають мінімально необхідні Дані для запуску гостьової операційної системи, а такоже Дані, необхідні для безпечного виходить з режиму роботи гостьової ОС, і Деякі налаштування, пов'язані з Керування цією віртуальною машиною.

Програміст практично вручну створює цю структуру, повністю опісує необхідній Йому віртуальний комп'ютер та його Властивості, ПІСЛЯ чого «завантажує» Її в СПЕЦІАЛЬНИЙ апаратний регістр «поточної віртуальної машини». Потім програміст може «запустіті» свіжоствореній віртуальну машину спеціальною інструкцією.

Характеристики

Список файлов реферата