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

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) і по суті своїй є невелика ділянкою фізичної оператівної пам'яті, що зберігають мінімально необхідні Дані для запуску гостьової операційної системи, а такоже Дані, необхідні для безпечного виходить з режиму роботи гостьової ОС, і Деякі налаштування, пов'язані з Керування цією віртуальною машиною.

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

Схема 7. Віртуалізація з використанням VT-x.

Запущена Віртуальна машина працює на звичайних апаратних ресурсах комп'ютера (зазначених VMM в опісі віртуальної машини) і для запущеного на ній програмного забезпечення практично нічим НЕ відрізняється від звічайної «фізічною» машини. Але на відміну від «Звичайний» режиму, в цю віртуальну машину можна вставляті як завгодно багато «закладок», ЯКІ будуть переріваті Її виконання, передавальних управління тому до VMM, Який буде вручну імітуваті ту чи іншу подію, або виконання тієї або іншої Інструкції. Які саме події будуть перекідатіся для «ручної обробки» VMM, визначається Тільки самим програмістом, але ЇХ в будь-якому випадку Навіть Більше, Ніж Необхідно для реалізації як завгодно складної віртуальної машини, аж до точної імітації Зовсім іншого процесора. Пріміром, проблемною у звичайно випадках операція читання-запису регістра CR3 в VT-x просто призведе до того, що процесор на секундочку призупинили гостьова ОС, вікліче VMM, Який програмно сімітірует результат Її виконання (не віконуючі справжня інструкцію MOV to / from CR3 з апаратний регістром, а підмінівші Її читанням-записом звичайно шматочка оператівної пам'яті), ПІСЛЯ чого відновіть виконання гостьовій ОС, яка «каверзи» Навіть не відчує.

При бажанні можна Навіть вручну «підкручування» Лічильник тактів процесора і Свідчення системного таймера, Щоб у гостьовій ОС не виникла сумнівів непотрібніх, з приводу того, з чого це раптом Деякі Інструкції на даному «процесорі» виконуються так довго. Можна Навіть спробувати один-в-один зімітуваті AMD Athlon XP на Intel Pentium 4 - так, що програмне забезпечення «Гостьовий» операційної системи не буде і здогадуватіся про підміну. Правда, Якщо бути точним Зовсім, то оскількі Pentium 4 не підтрімує набір інструкцій AMD 3Dnow, А технологія VT-x НЕ дозволяє перехоплюваті помилки типу «невідома інструкція» (Invalid Opcode), то зімітуваті підтримку 3Dnow! на P4 неможливим. Але 3Dnow! все одно сьогодні практичність не вікорістовується, а в усьому іншому (скажімо, у всьому тому, що рапортує про процесор стандартна інструкція CPUID), імітованім комп'ютер буде вести себе точно як AMD Athlon XP, так що переважно більшість ПЗ на «віверт» піддасться.

От і вся технологія віртуалізації VT-x - ми просто перекладається наш процесор в такий режим, коли ВІН перехоплює Деякі (визначені нами) події і передає ЇХ у спеціальну програму - менеджер віртуальної машини. І ніякої складної бінарної трансляції!

Всього в VT-x десять нових інструкцій:

·          VMXON і VMXOFF включаються і вимикають режим VMX.

·          VMWRITE дозволяє програмісту запісуваті Дані в структуру VMCS, що опісує віртуальну машину; VMREAD - аналогічно читать Дані з VMCS. Власне формат структури VMCS офіційно невідомий, і яким чином і що там, взагалі кажучи, зберігається - одна Intel знає. Зауважімо, такоже, що сама структура VMCS відносно невелика за розмірамі (одиниці кілобайт) і не зберігає в собі, пріміром, даних про віртуальну пам'яті, що утворює фізічну пам'ять «віртуального комп'ютера», - ЦІ Дані менеджер VMM підтрімує (завантажує і зберігає) для віртуальніх машин самостійно.

·          VMPTRLD дозволяє вібрато потоково віртуальну машину (покажчик на VMCS). VMPTRST, аналогічно, ЗБЕРЕГТИ покажчик на поточно віртуальну машину.

·          VMLAUNCH дозволяє запустіті вибране віртуальну машину (опісується раніше встановлених Покажчик на коректно потоково VMCS).

·          Виконання коду працює віртуальної машини переріває або настання зазначених у VMCS події (зовнішнього переривані, спроба ВИКОНАТИ ту чи іншу інструкцію), або виконання Інструкції VMCALL (Якщо вона дозволена в настройках VMCS).

·          VMRESUME дозволяє продовжіті перерване подією виконання коду на віртуальній машіні.

·          VMCLEAR вікорістовується для ініціалізації порожній структури VMCS і для перекладу вібраної віртуальної машини в «зупинення» табору (зі збереженням даних VMCS).

Схема 8. Набор инструкций VT-x

Доступ до інструкцій VT-x за замовчуванням заблокований; для їх включення потрібно «включити» біт 4 в четвертому контрольному регістрі процесора (CR4.VMXE = 1) і «включити» біти 0 і 2 в MSR-регістрі 3Ah. На віртуальній машині, емульованої за допомогою VT-x, можна замаскувати підтримку VT-x, повідомляємо інструкцією CPUID, і примусово заблокувати будь-яку можливість використання у віртуальній машині інструкцій даного сімейства. З урахуванням можливостей по маскуванню виконавчі інструкцій на віртуальній машині це означає, що можна домогтися того, що виконуються на віртуальній машині програмне забезпечення ні за яких умов не зможе здогадатися про те, що працює не на реальному комп'ютері, а на віртуальній машині.

Технологія Intel VT вже вийшла на ринок - у продажу є як настільні, так і серверні процесори, офіційно її підтримують. Перелік процесорів Intel з підтримкою VT постійно поповнюється, і ви без праці зможете знайти його на сайті Intel разом із популярним описом самої технології. Корпорація для популяризації цього свого рішення любить влаштовувати живі демонстрації можливостей технології віртуалізації, коли спершу «типовий професіонал» сидить поруч з чотирма системними блоками (пофарбованими для наочності у різний колір), один з яких вважає професійну задачу, на другий виконується офісна робота, третій « крутить »невеликий сервер, четвертий займається обслуговуванням та антивірусної перевіркою (усі - під різними ОС). І кожну з цих систем можна незалежно «підвісити», «заразити» або перезавантажити, в той час як інші продовжують свою діяльність. І кульмінацією цієї демонстрації стає момент, коли відкриваються кришки цих системних блоків, а під ними - порожньо. Поряд ж коштує звичайний «непримітний» системний блок (для наочності пофарбований у ці ж 4 кольори - в смужку), який лише і виконує всю описану вище роботу - під управлінням Intel VT з апаратною підтримкою і декількома одночасно працюють ОС. На недосвідчених користувачів така демонстрація надає велике враження.

Другий, більш «побутової» демонстрацій Intel VT зазвичай виступає домашній мультимедійний комп'ютер, який одночасно обслуговує декілька незалежних користувачів, таких як тато працює з поштою, мама дивиться фільм, а дитя - так, грає чи слухає музику. Папа закінчив і вимкнув свою систему (або система сина під час гри підвисла і пішла на перезавантаження), але при цьому інші користувачі продовжують роботу / розвага, як ні в чому не бувало. Нарешті, принципи віртуалізації використовуються і в деяких «профільних» рішеннях для певних регіонів ринку. Наприклад, в знаменитому «китайському» домашньому концепт-ПК від Intel, який легким поворотом ключика може перекладатися з режиму роботи звичайної користувацької ОС в спеціальний навчальний режим з графічним сенсорним екраном, призначений тільки для простори освоєння ієрогліфічного письма. При цьому поточний стан звичайної ОС повністю зберігається, і до нього можна легко повернутися зворотним поворотом ключика.

Загалом, простір для застосовності технологій віртуалізації на роботі і в побуті є, і питання його грамотного використання з новітніми процесорами Intel тепер лягає на плечі відповідного програмного забезпечення, яке поки що не отримало широкого розповсюдження. Хоча, будемо сподіватися, скоро його все ж таки отримає.

а) Віртуалізація завтра: AMD Secure Virtual Machine «Pacifica»

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

Щоправда, з іншого боку, рішення AMD більш досконалий і більш сучасним. А несумісність концептуальних підходів виявляється лише у відносно невеликої частини коду модуля VMM (будь-які операційні системи і звичайне ПЗ, природно, будуть як і раніше однаково добре працювати на процесорах і Intel, і AMD). Але - тим не менш.

Давайте на хвилинку повернемося до Intel і подивимося на те, який підхід був покладений в основу ідеології VT-x. У нас є якась «базова» операційна система, в якій користувач запускає програму типу VMWare Workstation або Microsoft VirtualPC, а вже цю програму при бажанні може підкрутити щось в процесорі, включити режим віртуалізації, створити спеціальний модуль з управління віртуальними машинами, створити віртуальні машини, і запустити на них якісь «гостьові» операційні системи зі своїми додатками. При цьому «режим VMX» не є чимось дуже особливим і запущений в цьому режимі код ніякими особливими привілеями не володіє. Фактично це просто звичайна програма (або драйвер), запущене на процесорі і має зайвої парою прапорців, записаних глибоко в службових регістрах процесора.

У AMD підхід принципово інший, більш простий і наочний. Починається він теж з менеджера віртуальних машин VMM, та тільки ось менеджер той на інтеловськіх аналог абсолютно не походить. У Intel VMM - це якесь дуже хитре додаток звичайної операційної системи, яке може бути запущено навіть з кільця звичайного пріоритету. У AMD - це системний код, що працює на більш низькому рівні, ніж сама операційна система, і запускається виключно з системного Ring 0. Модуль VMM в Pacifica фактично виконує роль ядра деякої «базової» операційної системи, і тільки цей код в Pacifica працює з власне фізичним обладнанням. Усі «звичайні» операційні системи в підході AMD - гостьові і працюють з віртуальними машинами, які для них створює VMM. Оцініть всю принадність рішення: у Intel модуль VMM в поті чола займається «фальсифікацією» купи різних подій, вибиваючись з сил, аби зробити вигляд, що гостьова ОС працює з реальним «залізом». У AMD модуль VMM просто один-єдиний раз створює віртуальну машину, перемикається в «гостьовій режим» - і запущений в цій гостьовій машині код працює з свіжостворений віртуальною машиною в практично повністю автономному режимі, без будь-якого втручання VMM.

Схема 9. Віртуалізація з AMD Pacifica

Як таке можливо? Та дуже просто: AMD дійсно віртуалізується фізичні ресурси, і, перш за все, - оперативну пам'ять. «Фізична» віртуальна пам'ять, видима гостьовими ОС в Pacifica - це просто віртуальна пам'ять другого рівня. Таблиці трансляції для якого контролює, природно, VMM. Тобто якщо яка-небудь програма, запущена в цій гостьовій ОС, скажімо, звертається до пам'яті за адресою такому-то, то процесор, використовуючи таблиці трансляції, контрольовані гостьовій ОС, спочатку перетворює цю адресу в «фізичний» адреса, який вже апаратно, без участі VMM перетвориться в справжній фізичну адресу. Або, як уже говорилося, не перетворюється, а викликає підкачування з своп-файлу, завантаження даних по мережі, і інше - можливості віртуальної пам'яті в умілих руках безмежні. VMM, до речі кажучи, влаштований набагато простіше операційної системи, повністю незалежний від неї, і тому потенційно можливо реалізовувати на його основі всю ту «рідкісну» функціональність, яку зазвичай не ризикують (або не хочуть) вносити до ядра звичайних операційних систем.

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

З просто-таки напрошуються прикладів - можна, приміром, буде створити такий комп'ютер, на якому мають виконуватися тільки ліцензійні операційні системи виробництва Microsoft без єдиного байти «чужих» змін з боку любителів халявного ПЗ. Вірніше сказати, запускати на цьому комп'ютері, при бажанні (скажімо, після перепрошивання BIOS) можна буде, звичайно, все що завгодно, але при цьому в процесорі не взведется спеціальний «біт безпеки», легко перевіряється абсолютно будь-яким додатком, і з подібним «не минулим перевірку »комп'ютером, наприклад, може відмовитися працювати яке-небудь ПЗ. Для звичайного користувача, боюся, подібна можливість виллється в чергову купу проблем з копірайтом і вільним софтом, однак для корпоративних користувачів підтримка «безпечного режиму» може виявитися життєво важливою, оскільки дозволяє гарантувати безпеку середовища, в якій запускається корпоративне додаток. Перевірив «безпечний прапор» - означає комп'ютер гарантовано «чистий», «перевірений». Немає цього прапора - значить, в системі щось змінилося: поміняли частина «заліза» (поміняли клавіатуру, на що містить «жучок»; додали шпигунську PCI-плату, що збирає інформацію про ПЗ; поставили чужу мережеву карту; посадили в систему «руткіт» і так далі). Крім того, в захищеному режимі процесор може автоматично знищувати не використовувані більш дані з пам'яті (зокрема, при перезавантаженні системи), гарантуючи відсутність витоків «сміття», що залишається після роботи додатків в «чужі» руки. А оскільки підвищена безпека - одна з основних застосувань майбутніх технологій віртуалізації, то це ще один величезний плюс технології AMD.

Втім, справедливості заради, треба відзначити, що в Intel розробляється (вже протягом декількох років) власна технологія апаратного безпеки під назвою LaGrande, яка вміє дуже багато що і навіть більш готова до виходу на ринок, ніж Pacifica. Так що, цілком можливо, що зв'язка Intel VT + LaGrande виявиться не менш функціонально привабливою, ніж AMD Pacifica. А вже в умінні Intel влаштувати грамотний і широкомасштабний маркетинг своїх продуктів сумніватися не доводиться.

Саме по собі функціонування VMM у AMD дуже нагадує функціонування VMM в технології Intel: VMM за допомогою спеціальних інструкцій готує спеціальні керуючі структури, що описують віртуальні комп'ютери, «запускає» ці структури на виконання і перехоплює вибрані події, що відбуваються там, підміняючи їх «ручний» роботою. Головна відмінність - це обсяг і тип виконуваної роботи. У AMD немає необхідності займатися складним менеджментом пам'яті з підставними таблицями трансляції та синхронізацією цих таблиць з справжніми, нема необхідності у перехопленні пов'язаних з цими таблицями трансляції подій. Потрібно перехоплювати і обробляти тільки деякі зовнішні події (скажімо, переривання від таймера, щоб перемикаючись між гостьовими операційними системами створювати ілюзію їх одночасної роботи; або переривання від клавіатури - перемикатися між гостьовими ОС по натисненню певної комбінації клавіш). Та й то, при бажанні в Pacifica можна просто «напряму» підключити вибрані пристрою в гостьових операційних системах до фізичних ресурсів (у VT-x, для порівняння, будь-яке звернення гостьовій ОС до портів введення-виведення примусово перехоплюється модулем VMM).

Є й інші особливості, що дозволяють мінімізувати кількість непотрібних переключень від гостьової ОС до VMM і назад, переклавши відповідні перевірки на апаратне забезпечення. А якщо і доводиться все-таки перемикатися між гостьовій ОС, VMM, та іншої гостьової ОС - то, знову ж таки за контрастом з VT-x, це переключення відбувається украй швидко, з дуже обмеженою необхідністю у збереженні контексту і повною відсутністю необхідності скидання, приміром, буфера TLB, який зазвичай під час переходу між різними таблицями трансляції доводиться повністю очищати. Природно, що набір перехоплюваних подій і можливості «фальсифікації» усього й вся нітрохи у Pacifica не вже, ніж у VT-x; проте настройка що перехоплювати, а що ні - набагато гнучкіша (у VT-x багато перехоплюється безумовно; в Pacifica можна відключити практично будь-який перехоплення). Навіть не знаємо, до чого причепитися, - навряд чи можна було придумати щось більше за функціональністю, зручне у використанні, і настільки швидкодіюче.

Набір інструкцій Pacifica настільки ж простий і витончений, як і саме рішення AMD:

·          Команда VMRUN перемикає виконання на обрану віртуальну машину.

·          З віртуальної машини управління повертається або з перехоплення одного із зазначеного в налаштуваннях віртуальної машини подій, або при виклику спеціальної інструкції VMMCALL (якщо остання дозволена налаштуваннями).

·          Інформація про віртуальній машині зберігається в спеціальній структурі даних VMCB (Virtual Machine Control Block) відомого формату. VMM працює з даною структурою безпосередньо, вручну змінюючи при необхідності відповідні поля (на відміну від VT-x, де формат аналогічної структури VMCS офіційно невідомий і для роботи з VMCS використовуються спеціальні інструкції VMREAD і VMWRITE). Про всяк випадок ще раз нагадаємо, що сама ця структура відносно невелика і описує тільки стан процесора віртуальної машини, а віртуальну пам'ять і стан віртуальних пристроїв цієї машини VMM повинна обслуговувати самостійно.

·          Найбільш необхідні операції з переключення контексту при переходах VMM до гостьової ОС і назад виконуються повністю автоматично. Проте, щоб не робити зайвих дій, зберігається і завантажується дійсно тільки найнеобхідніше, і при необхідності будь-яких складних дій або перемикання на іншу гостьову ОС, «додаткові» операції збереження стану процесора в VMCB і зворотного завантаження виконуються інструкціями VMLOAD і VMSAVE.

·          Інструкція SKINIT дозволяє почати завантаження процесора в «безпечному режимі», на апаратному рівні гарантувавши відповідність завантажувача (до 64 Кбайт коду) зазначеної в апаратурі (в модулі TPM) цифрового підпису

П'ять інструкцій. Проти десяти в куди більш складному і менш функціональному VT-x. Ну як ще висловити захоплення архітекторами наборів інструкцій AMD? Щоправда, до «п'яти базових» для повного розкриття можливостей Pacifica можна ще використовувати «тактичні» три інструкції, що дозволяють додатково прискорити швидкість роботи Pacifica:

STGI, CLGI - управляють схемою перехоплення переривань в Pacifica (включають-вимикають «глобальний перехоплення переривань»).

INVLPGA - скидає TLB, але не цілком, а тільки ті записи TLB, які відносяться до конкретної гостьовій ОС (або до VMM).

Схема 10. Набір інструкцій Pacifica

Як і у випадку з VT-х, для того, щоб отримати доступ до нових інструкцій, програмного забезпечення потрібно ці інструкції розблокувати (встановити 12-й біт регістра EFER MSR, відтепер відомий як EFER.SVME). При бажанні в Пасифік можна відключити всі її просунуті функції, аж до відключення подвійний трансляції віртуальних адрес, що дозволяє максимально наблизити (хоча і не до кінця) схеми використання до VT-х.

У цілому рішення AMD явно охоплює всю мислиму область застосовності рішення Intel, але витонченіше, швидше і простіше у використанні, а головне - забезпечує більш ніж достатній запас міцності для того, щоб вважатися повноцінним віртуалізаційних рішенням майбутнього. Тим більше що відповідні процесори повинні з'явитися вже зовсім скоро - у першому кварталі 2006 року.

Цікаво, що на останньому московському Intel Developer Forum (що пройшов у жовтні 2005 року) в доповідях абсолютно несподівано прозвучали все ті ж знайомі «подвійні таблиці трансляції», «захист DMA» та інші характерні функції Pacifica, рекламувалися як... друге покоління систем віртуалізації Intel. До першого, природно, ставилася «закриває дірки x86" технологія VT-х. Чесно кажучи, сам московський ІСО з нашою суб'єктивної точки зору, опинився в плані інформації з віртуалізації вкрай скупий, а рівень «пізнань» заміняли своїх іноземних колег співробітників, які виступали з доповідями часом просто шокував - вони були не в змозі відповідати на задаються їм із залу неспеціалістами питання! Але пізніше чудовий чоловік - Всеволод Предтеченський, поодинці замінює всіх інших технічних фахівців російського відділення Intel - в особистій бесіді пояснив, що цим самим «другим поколінням» повинна стати давним-давно анонсована «технологія безпеки» LaGrande (а вірніше, те, у що цей проект перетворився до теперішнього часу), яка вбере в себе не тільки новітні технології віртуалізації (про які ми поговоримо в останній частині), але й складні системи забезпечення гарантованої безпеки (аж до шифрування переданих по USB даних мишкою).

3. Інші підходи до віртуалізації. Віртуальна машина Xen

Проект Xen (вимовляється як «Зен») - мабуть, самий динамічно розвивається і сучасний пакет віртуалізаційних ПЗ, яскравий приклад того, на що, за відповідної підтримки, здатне співтовариство Open Source. Започаткований Кембріджський університети як відкрита реалізація відносно нескладною технології паравіртуалізаціі, Xen незабаром став одним з найбільш популярних віртуалізаційних проектів, і отримав багатющу функціональність, що включає в себе систему забезпечення взаємної безпеки віртуальних машин, систему управління їх ресурсами, систему забезпечення «гарантованого рівня обслуговування» (якості обслуговування, QoS), систему «непомітною міграції» (за 50-300 мс можливо «перекинути» працюючу віртуальну систему з одного фізичного комп'ютера на інший), і багато іншого. Як і будь-яке інше програмне забезпечення, що реалізує технологію паравіртуалізаціі, Xen виступав як прошарку між операційними системами та фізичним обладнанням, і вимагав, щоб операційна система була адаптована до роботи не з реальним «залізом», а з цієї віртуалізаційних прошарком. Відповідні патчі, що забезпечують необхідну підтримку для Xen з боку операційної системи були розроблені для Linux, FreeBSD, NetBSD і екзотичної Plan 9, і багато великих вендори включили цю підтримку, разом з самим Xen, в свої дистрибутиви відповідних операційних систем. І все це - за два роки, з 2003 по 2005 рік!

Схема 11. Віртуальна машина Xen

Наступний етап розвитку проекту був пов'язаний з ім'ям Intel, яка вирішила використовувати Xen як основного «популяризатора» своєї технології віртуалізації VT. Розробники Intel дописали для Xen відповідний модуль, що забезпечує сполучення на VT-сумісних процесорах довільній ОС з внутрішнім інтерфейсом Xen. Модуль був включений в спільний проект, і таким чином Xen «несподівано» знайшов здатність працювати з довільними операційними системами - благо, що вся необхідна для цього інфраструктура в проекті вже була присутня. AMD, теж не залишилася осторонь, від цього питання, і до теперішнього моменту Xen отримав експериментальну підтримку і технології апаратної віртуалізації Pacifica, ще не «включення» ні в одному з продаваних нині процесорів AMD, але зате більш сучасною та зручною з точки зору реалізації. А оскільки «батьківського» операційної системи для Xen не потрібно, то ось так, відразу, з іграшки спільноти Open Source, цей проект перетворився на безкоштовний універсальний менеджер віртуальних машин для новітніх процесорів AMD Intel і, придатний для використання широким колом користувачів. Швидше за все, завдяки активній підтримці обох «грандів процесоробудування», саме Xen, а не продукція Microsoft або VMWare, ляже в основу майбутнього стандарту на VMM і стане «традиційним вибором користувачів». На жаль, станеться це, схоже, у порівняно віддаленому майбутньому, бо встановити, налаштувати, і змусити як-то працювати Xen прямо зараз зможе, боюся, далеко не кожен навіть досить досвідчений користувач.

Схема 12. XenSE: поліпшення безпеки віртуальних систем

Технічні характеристики Xen виглядають наступним чином: підтримуються всі спеціально адаптовані до Xen операційні системи, або будь-які x86-сумісні операційні системи (Itanium-сумісні - у стадії бета-версії Xen) за наявності коштів апаратної підтримки віртуалізації (Intel VT-х «Вандерпул» / AMD SVM «Пасифік»). На момент написання статті (Xen 3) для встановлення Xen-а було потрібно наявність працює версії Linux з завантажувачем GRUB, а конфігурація проводилася річний правкою конфігураційних файлів; причому Xen включав в себе самостійне ядро Linux, завантажувати в цій «рідний» системі замість основного, що, приміром, могло зажадати перекомпіляції для цього ядра наявних у системі модулів LKM. Для дистрибутивів, в які Xen спочатку був включений, особливої проблеми подібне своєрідність установки не створить (у SuSe Linux Professional 1910 управління Xen-му було навіть включено в графічну утиліту YAST Центр управління), всім іншим - доведеться чекати виходу відповідних придатних до використання звичайним користувачем пакетів. Правда, на жаль, навіть тоді серйозно запустити на платформі Xen операційну систему MS Windows вдасться лише з великим скрипом - надаються Xen можливості з імітування обладнання віртуального комп'ютера сьогодні, м'яко кажучи, недорозвинені, а працювати з мережевого протоколу з-під Linux із запущеною де- то там, в глибинах комп'ютера, MS Windows, доступної хіба що у вигляді віртуального мережевого хоста, на якому з «заліза» присутній лише жорсткий диск, процесор, оперативна пам'ять, та мережева картка, завдання не з тривіальних. Юніксоіда такий набір влаштує цілком, «домашнього користувача» - навряд чи.

Проте це навряд чи сильно зашкодить світлого майбутнього Xen: з драйверами Intel і AMD проекту напевно посприяють, а поява зручного для кінцевого користувача дистрибутива, встановлюваного на «голу» або навіть вже працюючу машину - це лише питання часу. Почекаємо ближче до кінця 2006 року Xen версії 4?

Таблиця 1. Операційні системи Xen.