Технології віртуалізації: вчора, сьогодні, завтра
Втім, справедливості заради, треба відзначити, що в 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.
4. Емулятори віртуальних машин
Окрема історія - це системи, що забезпечують повністю програмну емуляцію нікого віртуального комп'ютера без залучення його реальних апаратних ресурсів. Найбільш яскравим прикладом подібного емулятора є відома Java, в якій програмне забезпечення реалізує для кожного Java-додатки стандартну віртуальну Java-машину, яка не має абсолютно нічого спільного з реальним апаратним забезпеченням і працює з не має альтернатив системою «машинних» команд - байт-кодом Java. Кожна інструкція з цього байт-коду (а там зустрічаються і досить нетривіальні «екземпляри») «розбирається» програмою-емулятором вручну - емулятор самостійно, без будь-якої апаратної підтримки виконує відповідні інструкції дії з існуючою (знову ж таки, лише в чисто програмному вигляді) віртуальною машиною.
У емуляторів дуже багато переваг. Реалізовані ними віртуальні машини можуть бути як завгодно складні і, що важливіше, принципово відрізнятися від реальної фізичної машини, засобами якої вони підтримуються. Одне й те ж Java-додаток може бути запущено практично на будь-якому «залізі»; емулятор Спектр дозволяє виконувати додатки, написані для процесора Z80 на процесорах архітектури x86, і т.д. Класичні віртуалізатор всього цього робити, на жаль, не дозволяють, - запустити, скажімо, на x86, додаток для MacOS (використовує архітектуру PowerPC) з їх допомогою принципово неможливо.
Слабкі місця емуляторів цілком очевидні: оскільки апаратні ресурси процесора задіюються дуже опосередковано (де можна було б обійтися однією машинної інструкцією, доводиться виконувати від сотень до десятків тисяч машинних інструкцій для виконання однієї інструкції емульованого коду), то і продуктивність переважної більшості емуляторів просто катастрофічно мала. Навіть в Java, розробники якого чудово передбачали цю ситуацію і використанням складного байт-коду постаралися звести виникає надлишок роботи до мінімуму (чим простіше інструкція, тим помітніше час, що витрачається емуляторів на її «декодування» - визначення, що ця інструкція означає), повністю позбутися від цих проблем, на жаль, не вдалося: «важкі» Java-додатки відчутно «гальмують» і споживають велику кількість оперативної пам'яті.
Кілька разів робилися серйозні спроби виправити це положення справ, відмовившись від виконання коду «на льоту», коли емулятор послідовно, інструкція-за-інструкцією, транслює програму, і перейшовши до «динамічної компіляції програм», коли програма, записана в одній системі команд попередньо «переводиться» в «рідну» систему команд даного процесора, і вже потім, у вигляді отриманого «рідного» коду на цьому процесорі виконується. Приміром, розроблений Connectix, пізніше купленої Microsoft, продукт Virtual PC для Macintosh дозволяв, за рахунок такого «перекомп» додатків для операційних систем Microsoft, запускати ці програми на комп'ютерах Apple Macintosh. А компанія Transmeta в 1999 році навіть випустила абсолютно унікальний процесор Crusoe (VLIW-архітектури), який імітував «видимість» x86-архітектури за допомогою спеціального полуаппаратного емулятора, розробленого, до речі, за участю Лінуса Торвальдса. А пізніше Microsoft розробила на основі даного підходу і «удосконалену альтернативу» Java - технологію. Net, що використовує для запису програм спеціальний «універсальний код» КСС (Common Intermediate Language), який за своєю суттю аналогічний псевдокод, який генерують у ході своєї роботи сучасні компілятори перед тим, як сконвертувати цей «абстрактний код» до цілком конкретні машинні інструкції.
Потенційно даний підхід позбавлений всіх «вузьких місць», пов'язаних з недостатньою продуктивністю звичайних емуляторів, проте технологія. Net до цих пір так і не отримала обіцяного розповсюдження, а продуктивність Virtual PC для Macintosh, так само як і Transmeta Crusoe, залишає бажати кращого.
Після всіх компліментів на адресу AMD Pacifica може здатися, що нічого принципово більш сучасного в технологіях віртуалізації придумати неможливо. Але насправді це далеко не так.
Проведемо невеликий уявний експеримент. У нас є один комп'ютер з якимось набором апаратного забезпечення (яке, по суті, зводиться до процесора, оперативної пам'яті і засобів вводу-виводу). З пам'яттю і процесором ми вже розібралися: вони чудово віртуалізуются, і тому припустимо, що на цьому «залізі» працюють відразу декілька операційних систем. А ось хто і як працює з цих операційних систем з «введенням-виводом»? Ну, допустимо, різні жорсткі диски та логічні розділи цих дисків ми ще як-небудь розкидані між різними ОС. А ось візьмемо ту ж відеокарту: яка з операційних систем з нею повинна працювати? Не передавати ж її «по руках», перекидаючи від однієї ОС до іншої, - адже про присутність «сусідів», «підлаштовуються» під себе відеокарту ці ОС можуть навіть і не підозрювати!
Що робити? Єдине розумне рішення - застосувати все ту ж віртуалізацію до наших апаратних ресурсів. Замість того щоб працювати з цілком конкретної відеокартою, гостьові ОС працюють з якоюсь її «імітацією», яку створює модуль VMM, синхронізуючий потім цю імітацію з реальною відеокартою. Але оскільки на дійсно складну імітацію сил програмістів зазвичай не вистачає, то і можливості «віртуальної» відеокарточкі виходять відповідні, зразка десь 1996 року в кращому випадку. Щоправда, менш «наворочені» пристрою, на щастя, імітувати куди простіше, так що в дійсності ситуація далеко не так удручающа, як це може на перший погляд здатися, проте ж свого дозволу вона, безумовно, все-таки вимагає. А називається це все «віртуалізацією введення-виведення».
Зараз, правда, важко загадувати в майбутнє: коли ми ставили запитання співробітникам Intel, то з'ясовувалося, що відповідні проекти поки носять статус дослідницьких, а вже намірів по створенню і просуванню будь-яких стандартів у цій галузі у них ще немає і в помині. Але можна ризикнути припустити, що розвиток тут піде у бік часткового перенесення драйверів пристроїв з операційних систем в менеджери віртуальних машин (VMM). Кожен такий драйвер буде надавати певний універсальний інтерфейс до всіх можливостей відеокарти, що враховує при цьому існування багатьох «споживачів» цих можливостей; драйвера ж рівня операційної системи будуть просто надавати більш високорівнева доступ до тих же функцій у термінах специфічною для даної операційної системи графічної підсистеми (будь то Windows GDI з DirectX або X Window System з OpenGL). Благо, що на прикладі AMD Pacifica добре видно, що і «місце» під драйвера поруч з VMM в системах «другого покоління» чудово знайдеться, і інтерфейс між VMM і операційними системами (і навіть прикладним ПЗ) можна зробити надзвичайно зручним і швидкодіючим (можливо навіть більш швидким, ніж традиційні системні виклики). Самі ж «пристрої введення-виведення» також обзаведуться специфічними апаратними доробками, які спрощують можливості їх одночасного використання декількома операційними системами одночасно. Ймовірно, з'явиться і свій стандарт на VMM і «програмний інтерфейс» VMM, що надаються ними розширені можливості для звичайних операційних систем. І, цілком можливо, що зовсім недалеко той день, коли на типовому комп'ютері буде встановлений «вінегрет» з пари версій Microsoft Windows, Linux, FreeBSD, Solaris, якого-небудь популярного VMM з відкритим кодом, і все це різноманіття буде чудово, без сьогоднішніх проблем з драйверами для різних ОС, одночасно в повну силу працювати.