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

· Найбільш необхідні операції з переключення контексту при переходах 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) з їх допомогою принципово неможливо.