Технологii вiртуалiзацii: вчора, сьогоднi, завтра
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
т перетворився на безкоштовний унiверсальний менеджер вiртуальних машин для новiтнiх процесорiв AMD Intel i, придатний для використання широким колом користувачiв. Швидше за все, завдяки активнiй пiдтримцi обох грандiв процесоробудування, саме Xen, а не продукцiя Microsoft або VMWare, ляже в основу майбутнього стандарту на VMM i стане традицiйним вибором користувачiв. На жаль, станеться це, схоже, у порiвняно вiддаленому майбутньому, бо встановити, налаштувати, i змусити як-то працювати Xen прямо зараз зможе, боюся, далеко не кожен навiть досить досвiдчений користувач.
Схема 12. XenSE: полiпшення безпеки вiртуальних систем
Технiчнi характеристики Xen виглядають наступним чином: пiдтримуються всi спецiально адаптованi до Xen операцiйнi системи, або будь-якi x86-сумiснi операцiйнi системи (Itanium-сумiснi - у стадii бета-версii Xen) за наявностi коштiв апаратноi пiдтримки вiртуалiзацii (Intel VT-х Вандерпул / AMD SVM Пасифiк). На момент написання статтi (Xen 3) для встановлення Xen-а було потрiбно наявнiсть працюСФ версii Linux з завантажувачем GRUB, а конфiгурацiя проводилася рiчний правкою конфiгурацiйних файлiв; причому Xen включав в себе самостiйне ядро Linux, завантажувати в цiй рiдний системi замiсть основного, що, примiром, могло зажадати перекомпiляцii для цього ядра наявних у системi модулiв LKM. Для дистрибутивiв, в якi Xen спочатку був включений, особливоi проблеми подiбне своСФрiднiсть установки не створить (у SuSe Linux Professional 1910 управлiння Xen-му було навiть включено в графiчну утилiту YAST Центр управлiння), всiм iншим - доведеться чекати виходу вiдповiдних придатних до використання звичайним користувачем пакетiв. Правда, на жаль, навiть тодi серйозно запустити на платформi Xen операцiйну систему MS Windows вдасться лише з великим скрипом - надаються Xen можливостi з iмiтування обладнання вiртуального компютера сьогоднi, мяко кажучи, недорозвиненi, а працювати з мережевого протоколу з-пiд Linux iз запущеною де- то там, в глибинах компютера, MS Windows, доступноi хiба що у виглядi вiртуального мережевого хоста, на якому з залiза присутнiй лише жорсткий диск, процесор, оперативна память, та мережева картка, завдання не з тривiальних. Юнiксоiда такий набiр влаштуСФ цiлком, домашнього користувача - навряд чи.
Проте це навряд чи сильно зашкодить свiтлого майбутнього Xen: з драйверами Intel i AMD проекту напевно посприяють, а поява зручного для кiнцевого користувача дистрибутива, встановлюваного на голу або навiть вже працюючу машину - це лише питання часу. ПочекаСФмо ближче до кiнця 2006 року Xen версii 4?
Таблиця 1. Операцiйнi системи Xen.
4. Емулятори вiртуальних машин
Окрема iсторiя - це системи, що забезпечують повнiстю програмну емуляцiю нiкого вiртуального компютера без залучення його реальних апаратних ресурсiв. Найбiльш яскравим прикладом подiбного емулятора СФ вiдома Java, в якiй програмне забезпечення реалiзуСФ для кожного Java-додатки стандартну вiртуальну Java-машину, яка не маСФ абсолютно нiчого спiльного з реальним апаратним забезпеченням i працюСФ з не маСФ альтернатив системою машинних команд - байт-кодом Java. Кожна iнструкцiя з цього байт-коду (а там зустрiчаються i досить нетривiальнi екземпляри) розбираСФться програмою-емулятором вручну - емулятор самостiйно, без будь-якоi апаратноi пiдтримки виконуСФ вiдповiднi iнструкцii дii з iснуючою (знову ж таки, лише в чисто програмному виглядi) вiртуальною машиною.
У емуляторiв дуже багато переваг. Реалiзованi ними вiртуальнi машини можуть бути як завгодно складнi i, що важливiше, принципово вiдрiзнятися вiд реальноi фiзичноi машини, засобами якоi вони пiдтримуються. Одне й те ж Java-додаток може бути запущено практично на будь-якому залiзi; емулятор Спектр дозволяСФ виконувати додатки, написанi для процесора Z80 на процесорах архiтектури x86, i т.д. Класичнi вiртуалiзатор всього цього робити, на жаль, не дозволяють, - запустити, скажiмо, на x86, додаток для MacOS (використовуСФ архiтектуру PowerPC) з iх допомогою принципово неможливо.
Слабкi мiiя емуляторiв цiлком очевиднi: оскiльки апаратнi ресурси процесора задiюються дуже опосередковано (де можна було б обiйтися однiСФю машинноi iнструкцiСФю, доводиться виконувати вiд сотень до десяткiв тисяч машинних iнструкцiй для виконання однiСФi iнструкцii емульованого коду), то i продуктивнiсть переважноi бiльшостi емуляторiв просто катастрофiчно мала. Навiть в Java, розробники якого чудово передбачали цю ситуацiю i використанням складного байт-коду постаралися звести виникаСФ надлишок роботи до мiнiмуму (чим простiше iнструкцiя, тим помiтнiше час, що витрачаСФться емуляторiв на ii декодування - визначення, що ця iнструкцiя означаСФ), повнiстю позбутися вiд цих проблем, на жаль, не вдалося: важкi Java-додатки вiдчутно гальмують i споживають велику кiлькiсть оперативноi памятi.
Кiлька разiв робилися серйознi спроби виправити це положення справ, вiдмовившись вiд виконання коду на льоту, коли емулятор послiдовно, iнструкцiя-за-iнструкцiСФю, транслюСФ програму, i перейшовши до динамiчноi компiляцii програм, коли програма, записана в однiй системi команд попередньо переводиться в рiдну систему команд даного процесора, i вже потiм, у виглядi отриманого рiдного коду на цьому процесорi виконуСФться. Примiром, розроблений Connectix, пiзнiше купленоi Microsoft, продукт Virtual PC для Macintosh дозволяв, за рахунок такого перекомп додаткiв для операцiйних