Архітектура віртуальних машин

  1. Абстракція і віртуалізація
  2. Віртуальні машини
  3. Вбудовані системні інтерфейси
  4. Процесні і системні віртуальні машини
  5. Процесні віртуальні машини
  6. багатозадачні системи
  7. Інтерпретатори і динамічні транслятори двійкового коду
  8. Оптимізатори двійкового коду
  9. Віртуальні машини для мов високого рівня
  10. Системні віртуальні машини
  11. Класичні системні ВМ
  12. вкладені ВМ
  13. інтегральні ВМ
  14. многопроцессорная віртуалізація
  15. вбудовані ВМ
  16. Систематика віртуальних машин
  17. ***

Віртуалізація стала важливим інструментом розробки комп'ютерних систем, а віртуальні машини використовуються в самих різних областях - від операційних систем до мов програмування та архітектури процесорів

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

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

Абстракція і віртуалізація

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

На рис. 1 (а) наведено приклад абстракції в застосуванні до дискової пам'яті. Операційна система абстрагується від тонкощів адресації на жорсткому диску, від його секторів і доріжок, щоб для прикладної програми диск виглядав як набір файлів змінного розміру. Спираючись на цю абстракцію, «прикладні» програмісти можуть створювати файли, записувати і читати дані, не знаючи пристрої та фізичної організації жорсткого диска.

Концепція архітектури системи команд комп'ютера (instruction set architecture, ISA) наочно ілюструє переваги добре певних інтерфейсів. Вони дозволяють розробляти взаємодіючі комп'ютерні підсистеми не тільки в різних організаціях, але і в різні періоди, іноді розділені роками. Наприклад, Intel і AMD створюють мікропроцесори з системою команд IA-32 (x86), в той час як розробники Microsoft пишуть програмне забезпечення, яке компілюється в цю систему команд. Оскільки обидві сторони дотримуються специфікацію ISA, можна очікувати, що програмне забезпечення буде правильно виконуватися будь-яким ПК на базі мікропроцесора з архітектурою IA-32.

На жаль, добре визначені інтерфейси мають і недоліки. Підсистеми та компоненти, розроблені за специфікаціями різних інтерфейсів, не здатні взаємодіяти один з одним. Наприклад, додатки, поширювані в довічних кодах, прив'язані до певної ISA і залежать від конкретного інтерфейсу до операційної системи. Несумісність інтерфейсів може стати стримуючим фактором, особливо в світі комп'ютерних мереж, в якому вільне переміщення програм настільки ж необхідно, як і переміщення даних.

Віртуалізація дозволяє обійти цю несумісність. Віртуалізація системи або компонента (наприклад, процесора, пам'яті або пристрою введення / виводу) на конкретному рівні абстракції відображає його інтерфейс і видимі ресурси на інтерфейс і ресурси реальної системи. Отже, реальна система виступає в ролі іншої, віртуальної системи або навіть декількох віртуальних систем.

На відміну від абстракції, віртуалізація не завжди націлена на спрощення або приховування деталей. У прикладі на рис. 1 (б) віртуалізація дозволяє перетворити один великий диск в два менших віртуальних диска, кожен з яких має власні сектори і доріжки. При відображенні віртуальних дисків на реальний програмні засоби віртуалізації використовують абстракцію файлу як проміжний крок. Операція запису на віртуальний диск перетворюється в операцію запису в файл (і, отже, в операцію запису на реальний диск). Відзначимо, що в даному випадку ніякого абстрагування не відбувається - рівень деталізації інтерфейсу віртуального диска (адресація секторів і доріжок) нічим не відрізняється від рівня деталізації реального диска.

Віртуальні машини

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

Вбудовані системні інтерфейси

Обговорення віртуальних машин невіддільне від обговорення комп'ютерної архітектури. Оскільки ВМ спираються на вбудовані системні інтерфейси, головне в їх проектуванні - точність реалізації цих інтерфейсів.

У застосуванні до комп'ютерних систем архітектура означає формальну специфікацію системних інтерфейсів, в тому числі логічні моделі ресурсів, керованих через ці інтерфейси. Реалізація описує фактичне втілення архітектури. Як в обладнанні, так і в програмному забезпеченні рівні абстракції відповідають рівням реалізації, кожен з яких пов'язаний зі своїм власним інтерфейсом або архітектурою.

На рис. 2 показані деякі важливі інтерфейси і рівні реалізації в типовій комп'ютерній системі. Три таких інтерфейсу (розташованих на кордоні між обладнанням і програмним забезпеченням) є особливо важливими для побудови ВМ: це архітектура системи команд (ISA), двійковий інтерфейс додатків (application binary interface, ABI) і інтерфейс прикладного програмування (application programming interface, API).

Архітектура системи команд. ISA визначає межу між обладнанням і програмним забезпеченням і складається з двох інтерфейсів, позначених на рис. 2 цифрами 3 і 4. Інтерфейс 4 являє собою призначену для користувача частину ISA і містить функції, доступні прикладній програмі. Інтерфейс 3 (системна частина ISA) крім призначених для користувача команд містить функції, доступні тільки компонентам операційної системи, які відповідають за управління обладнанням.

Двійковий інтерфейс додатків. ABI надає програмі апаратні ресурси і послуги через призначену для користувача частину ISA (інтерфейс 4) і інтерфейс виклику системних процедур (інтерфейс 2). Привілейовані машинні команди в ABI не входять. Всі прикладні програми взаємодіють з обладнанням опосередковано, звертаючись до послуг операційної системи через інтерфейс виклику системних процедур. За допомогою таких процедур ОС виконує дії від імені користувача програми після підтвердження їх автентичності та безпеки.

Інтерфейс прикладного програмування. API надає програмі апаратні ресурси і послуги через призначену для користувача частину ISA (інтерфейс 4), доповнену зверненнями до бібліотек на мові високого рівня (інтерфейс 1). Всі виклики системних процедур зазвичай виконуються через бібліотеки. Використання API дозволяє шляхом перекомпіляції легко переносити прикладні програми на інші системи, що підтримують той же інтерфейс прикладного програмування.

Процесні і системні віртуальні машини

Щоб зрозуміти сутність віртуальної машини, необхідно розглянути значення слова «машина» з точки зору системи і процесу.

З точки зору процесу, що забезпечує виконання користувальницької програми, машина складається з виділеного процесу логічного адресного простору, команд користувацького рівня і регістрів, які дозволяють виконувати код цього процесу. Пристрої вводу / виводу доступні лише через операційну систему, і для процесу є тільки один спосіб взаємодії з системою введення / виводу - виклики системних процедур. Таким чином, стосовно до процесу машину визначає інтерфейс ABI. А інтерфейс API визначає характеристики машини з точки зору прикладної програми, написаної на високорівневої мовою.

З точки зору операційної системи вона цілком виконується на базовій машині. Опе? Раціон система - повнофункціональна середовище виконання, яка підтримує безліч процесів, спільно використовують файлову систему і інші засоби введення / виводу. Але процеси «приходять і йдуть», а системна середовище залишається. Система виділяє процесам реальну пам'ять і пристрої введення / виводу, дозволяє їм взаємодіяти з цими ресурсами. Отже, стосовно до операційної системи машину визначають лише характеристики базових апаратних засобів, а інтерфейс між системою і машиною забезпечує ISA.

Оскільки процеси і система «бачать» машину по-різному, віртуальні машини бувають процесними і системними. Процесна ВМ - це віртуальна платформа для виконання окремого процесу; вона призначена виключно для його підтримки, створюється при активізації процесу і припиняє своє існування з його закінченням. Системна ВМ надає повнофункціональну, постійно діючу системну середу для підтримки операційної системи разом з безліччю її користувальницьких процесів; вона забезпечує «гостьовий» операційній системі доступ до віртуальних апаратних засобів, в тому числі до процесора і пам'яті, пристроїв введення / виводу, а іноді - і до графічного інтерфейсу.

Процес або система, яка виконується на ВМ, називається гостем, а базова платформа, що підтримує ВМ, - хостом. Програмне забезпечення віртуалізації, що реалізує процессную ВМ, часто для стислості називають робочим середовищем. Програмне забезпечення віртуалізації системної ВМ зазвичай називають монітором віртуальних машин (virtual machine monitor, VMM).

На рис. 3 представлені процессная і системна ВМ. Хвилястими лініями позначені сумісні інтерфейси. У процессной віртуальній машині програмне забезпечення віртуалізації знаходиться на рівні інтерфейсів ABI або API, над кордоном між операційною системою і устаткуванням. Середовище виконання (runtime) емулює як команди користувальницького рівня, так і виклики системних процедур і звернення до бібліотек. У системної віртуальної машині програмне забезпечення віртуалізації знаходиться між апаратними засобами хост-машини і гостьовим програмним забезпеченням. Монітор VMM може емулювати апаратну архітектуру ISA, відмінну від ISA хоста, щоб гостьове програмне забезпечення могло виконувати іншу систему команд. Однак у багатьох реалізаціях системних ВМ монітор VMM не займається емуляцією команд; його основна роль полягає скоріше в віртуалізації апаратних засобів.

Процесні віртуальні машини

Процесні ВМ створюють віртуальні середовища ABI або API для призначених для користувача додатків. Різні їх різновиди дозволяють в багатозадачному режимі здійснювати реплікацію операційного середовища, емулювати систему команд, оптимізувати код або виконувати програми на мовах високого рівня.

багатозадачні системи

Найпоширеніша процессная ВМ стала настільки звичною, що мало хто сприймає її як віртуальну машину. Більшість операційних систем можуть працювати в багатозадачному режимі, підтримуючи кілька користувальницьких процесів одночасно, завдяки чому у кожного з них «створюється ілюзія одноосібного володіння» машиною. Кожен процес має власні адресний простір, регістри і файлову структуру. Операційна система організовує роботу базового обладнання в режимі поділу часу. Фактично операційна система надає процессную ВМ кожному з одночасно виконуваних додатків.

Інтерпретатори і динамічні транслятори двійкового коду

Складнішою проблемою для процесних ВМ є підтримка програм в двійковому коді, які скомпільовані для системи команд, що відрізняється від системи команд хоста. Свіжий приклад процессной ВМ - програмний пакет Intel IA32-EL [1], що дозволяє на платформі Itanium виконувати додатки, розраховані на IA32.

Найпростіше емулювати команди шляхом інтерпретації. Програма-інтерпретатор одну за одною вибирає з пам'яті, декодує і виконує команди гостьовий програми. Цей процес може бути досить повільним і вимагати десятків команд хост-машини для інтерпретації кожної вихідної команди. Більш висока продуктивність досягається шляхом динамічної трансляції двійкового коду, в ході якої команди гостьовий програми по блоках перетворюються в команди хоста і зберігаються для повторного використання в кеш-пам'яті команд. Таким чином, в разі циклічного виконання транслювати команд вдається амортизувати відносно високі витрати на трансляцію.

Оптимізатори двійкового коду

Для підвищення продуктивності динамічні транслятори іноді оптимізують двійкового коду. Ця можливість призводить до ідеї створення віртуальної машини, в якій гість і хост використовують одну і ту ж систему команд. Єдиним призначенням такої ВМ стає оптимізація двійкового коду. Оптимізатори використовують інформацію з профілю, зібрану при інтерпретації або трансляції, щоб оптимізувати двійкового коду «на льоту». Прикладом такого оптимізатора є система Dynamo - один з результатів реалізації науково-дослідного проекту компанії Hewlett-Packard [2].

Віртуальні машини для мов високого рівня

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

Мал. 4 показує відмінності між звичайною середовищем компіляції, що залежить від платформи, і середовищем ВМ мови високого рівня. У звичайному середовищі (рис. 4 (а)) препроцесор транслятора генерує проміжний код, подібний машинному, але більш абстрактний. Потім генератор коду на його основі створює двійковий файл з машинним кодом для конкретної операційної системи і архітектури ISA. Цей файл може виконуватися на платформах, що підтримують дану комбінацію ISA / операційна система.

У ВМ мови високого рівня (рис. 4 (б)) транслятор генерує абстрактний машинний код для віртуальної ISA, яка визначає інтерфейс ВМ. Цей віртуальний код разом з супутніми метаданими (інформацією про структури даних) поширюється для виконання на різних платформах. На кожній з них встановлена ​​ВМ, здатна завантажити і виконати команди віртуальної ISA, а також є набір бібліотечних підпрограм, запропонований стандартизованим API. Найпростіший варіант такої ВМ являє собою інтерпретатор. Більш складні високопродуктивні ВМ транслюють абстрактний код в машинний для безпосереднього виконання на базовій платформі.

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

Відомими прикладами ВМ мови високого рівня є архітектура віртуальної машини Java компанії Sun Microsystems [3] і середовище Microsoft Common Language Infrastructure, на якій заснована платформа .NET Framework [4]. В обох системах застосовуються стекові архітектури ISA, що дозволяє усунути необхідність в регістрах, використовувати абстрактну специфікацію даних і модель пам'яті, що підтримують безпечне об'єктно-орієнтоване програмування.

Системні віртуальні машини

Системна ВМ забезпечує повнофункціональну середу, в якій можуть співіснувати операційна система і кілька процесів, що відносяться до різних користувачам. За допомогою системних ВМ одна апаратна платформа здатна одночасно підтримувати кілька ізольованих гостьових операційних систем.

Системні ВМ з'явилися в середині 60-х років [5]. У той час комп'ютерні системи на базі мейнфреймів були дуже великими і дорогими, зазвичай обслуговували численні групи користувачів. З появою технологій ВМ ці групи отримали можливість на загальному обладнанні експлуатувати різні операційні системи. У міру зниження цін на комп'ютерне обладнання і розвитку настільних ПК інтерес до перших системним ВМ поступово знизився. Однак сьогодні системні ВМ знову набирають популярність, оскільки на зміну мейнфреймів прийшли сервери і серверні комплекси, обслуговуючі великі групи споживачів.

Одним з найважлівішіх ЗАСТОСУВАННЯ технології системних ВМ є ізоляція систем, что одночасно Працюють на Загальній апаратній платформі. У таких випадках відмова в роботі або порушення безпеки однієї з гостьових систем не впливає на програмне забезпечення, що виконується на інших гостьових системах.

У системної ВМ монітор VMM забезпечує реплікацію платформи. Основною проблемою є розподіл апаратних ресурсів між декількома гостьовими операційними системами (прикладом служить віртуалізація диска, показана на рис. 1). VMM управляє всіма апаратними ресурсами. Гостьова операційна система і її прикладні процеси працюють під прихованим контролем VMM. Коли гостьова ОС намагається виконати привілейовану команду або операцію, безпосередньо зачіпає загальні апаратні ресурси, VMM її перехоплює, перевіряє правильність і виконує від імені гостя. Гостьове ВО «не знає» про цю негласної роботі.

Класичні системні ВМ

Більшість системних ВМ забезпечують приблизно однакові функціональні можливості, але розрізняються деталями реалізації. При класичному підході [6] монітор VMM встановлюється на «голому залізі», а ВМ розташовується поверх нього. VMM виконується в привілейованому режимі, в той час як гостьові операційні системи позбавлені майже всіх привілеїв. Це необхідно, щоб VMM міг перехоплювати і емулювати ті їх дії, які в звичайних умовах пов'язані з управлінням життєво важливими апаратними ресурсами.

вкладені ВМ

В альтернативній реалізації системної ВМ програмне забезпечення віртуалізації розташовується поверх існуючої хост-системи. Така ВМ називається укладеною. Перевага вкладених ВМ полягає в тому, що користувач встановлює їх точно так же, як будь-яку прикладну програму. Щоб отримати доступ до драйверів пристроїв і іншим низькорівневим послуг, програмне забезпечення віртуалізації звертається до хост-системі, а не до VMM. Прикладом вкладеної ВМ може служити сервер VMware GSX Server [7], який виконується на апаратній платформі IA-32.

інтегральні ВМ

У звичайних системних ВМ хост-система, всі гостьові операційні системи і прикладні програми використовують архітектуру ISA базового обладнання. Однак в деяких ситуаціях гість і хост не мають загальної ISA. Наприклад, дві найпопулярніші настільні системи, Windows PC і Apple PowerPC, використовують різні ISA і різні операційні системи.

Інтегральні ВМ справляються з такою ситуацією, віртуалізіруя все програмне забезпечення, в тому числі операційну систему і додатки. Через відмінності в системах команд ВМ повинна емулювати і код додатків, і код операційної системи. Прикладом ВМ такого типу служить емулятор Virtual PC [8], в якому система Windows працює на платформі Macintosh. Програмне забезпечення ВМ виконується на хості як звичайна прикладна програма і не використовує системних операцій ISA.

многопроцессорная віртуалізація

Особливий інтерес представляє віртуалізація великого многопроцессорного комплексу з пам'яттю. Важливо розділити велику систему на кілька менших багатопроцесорних систем, розподіливши апаратні ресурси базової системи.

За допомогою фізичного розбиття на розділи [9] апаратні ресурси, які використовуються однією віртуальною системою, відокремлюються від ресурсів інших віртуальних систем. Фізичне розділення забезпечує високу ступінь ізоляції, тому ні проблеми ПО, ні помилки апаратних засобів в одному розділі не зачіпають програми в інших розділах. При логічному розбитті на розділи [10] розділи сервера спільно використовують базові апаратні ресурси в режимі тимчасового мультиплексування, що дозволяє підвищити коефіцієнт завантаження обладнання. Однак при цьому втрачаються деякі з переваг ізоляції апаратних засобів.

При реалізації обох методів зазвичай використовуються додаткове програмне забезпечення або прошивки для базового обладнання, спеціально доопрацьованого для забезпечення підтримки логічних розділів.

вбудовані ВМ

Функціональність і мобільність - ось цілі більшості системних ВМ, реалізованих на вже наявних апаратних засобах зі стандартною архітектурою ISA. На відміну від них, вбудовані ВМ реалізують нові приватні архітектури, націлені на підвищення продуктивності та ефективності роботи. ISA хост-машини може бути повністю нової або розширювати можливості існуючої.

Для вбудованої ВМ немає готових додатків, а монітор VMM виглядає як складова частина обладнання, єдиним призначенням якого є емуляція гостьовий ISA. Для підтримки цієї ілюзії VMM розташовується в області пам'яті, прихованої від звичайного програмного забезпечення. У його склад входить транслятор двійкового коду, який перетворює гостьові команди в оптимізовані послідовності базових команд і поміщає їх в приховану кеш-пам'ять.

Найбільш відомий приклад вбудованої ВМ - процесор Transmeta Crusoe [11]. Його базові апаратні засоби використовують архітектуру команд зі наддовгим командним словом (very long instruction word, VLIW), а гостьова ISA - це Intel IA-32. Завдяки простоті апаратної частини, призначеної для виконання команд VLIW, розробникам Transmeta вдалося істотно знизити енергоспоживання процесора.

В системі IBM AS / 400 (сьогодні відома як iSeries) також використовується технологія вбудованих ВМ [12]. На відміну від інших вбудованих ВМ, основне призначення AS / 400 - підтримка об'єктно-орієнтованої системи команд, що дозволяє по-новому поглянути на інтерфейс між обладнанням і програмним забезпеченням. Сьогоднішні реалізації AS / 400 засновані на розширеній архітектурі PowerPC, тоді як ранні версії використовували істотно відрізнялася від неї приватну архітектуру ISA.

Систематика віртуальних машин

Корисно охопити ВМ різних конструкцій і призначення єдиним поглядом. На рис. 5 представлена ​​найпростіша класифікація, відповідно до якої ВМ поділяються на процесні і системні. Подальша систематизація в рамках цих категорій відбувається в залежності від того, чи збігаються системи команд ВМ і її базової платформи. Справа в тому, що в віртуальних машинах з емуляцією ISA ця функція є домінуючою.

Серед процесних ВМ без емуляції ISA можна виділити багатозадачні системи, які підтримуються більшістю сучасних комп'ютерів. Сюди ж відносяться динамічні оптимізатори двійкового коду, що використовують багато з методів емуляції.

У категорію процесних ВМ з різними гостьовий і базової ISA входять динамічні транслятори, у яких інтерфейс з обладнанням зазвичай визначається на рівні ABI, а також ВМ мови високого рівня на розділи з інтерфейсом на рівні API.

Категорія системних ВМ без емуляції ISA об'єднує класичні та вкладені ВМ, службовці для реплікації ізольованою системної середовища. Основна відмінність між ними полягає в реалізації монітора VMM, а не в функціональних можливостях.

В інтегральних ВМ, в яких гостьова і базова ISA відрізняються один від одного, продуктивність часто вторинна по відношенню до точного відтворення функціональних можливостей. Там, де важливіше продуктивність або питоме енергоспоживання (наприклад, для вбудованих ВМ), інтерфейс реалізації ВМ може бути ближче до фізичних апаратних засобів процесора.

***

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

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

література

  1. L. Baraz et al, IA-32 Execution Layer: A Two-Phase Dynamic Translator Designed to Support IA-32 Applications on Itanium-Based Systems. Proc. 36th Ann. IEEE / ACM Intl Symp. Microarchitecture, IEEE CS Press, 2003.
  2. V. Bala, E. Duesterwald, S. Banerjia, Dynamo: A Transparent Dynamic Optimization System. Proc. ACM SIGPLAN 2000 Conf. Programming Language Design and Implementation, ACM Press, 2000..
  3. T. Lindholm, F. Yellin, The Java Virtual Machine Specification, 2nd ed. Addison-Wesley, 1999..
  4. D. Box, Essential .NET, Volume 1: The Common Language Runtime. Addison-Wesley, 2002.
  5. RJ Creasy, The Origin of the VM / 370 Time-Sharing System. IBM Journal Research and Development, Sept. 1981.
  6. RP Goldberg, Survey of Virtual Machine Research. Computer, June 1974.
  7. J. Sugerman, G. Venkitachalam, BH. Lim, Virtualizing I / O Devices on VMware Workstations Hosted Virtual Machine Monitor. Proc. General Track: 2001 Usenix Ann. Technical Conf., Usenix Assoc., 2001..
  8. E. Traut, Building the Virtual PC. Byte, Nov. 1 997.
  9. Sun Enterprise 10000 Server: Dynamic System Domains. Sun Microsystems, Tech. white paper, 1999..
  10. TL Borden, JP Hennessy, JW Rymarczyk, Multiple Operating Systems on One Processor Complex. IBM Systems Journal, Jan. 1989.
  11. A. Klaiber, The Technology Behind Crusoe Processors: Low-Power x86-Compatible Processors Implemented with Code Morphing Software. Tech. brief, Transmeta, 2000..
  12. E. Soltis, Inside the AS / 400. Duke Press, 1996..

Джеймс Сміт ( [email protected] ) - професор факультету електротехніки та обчислювальної техніки в університеті Вісконсіна. Рави Наїр ( [email protected] ) - науковий співробітник дослідницького центру IBM Watson Research Center.

James Smith, Ravi Nair. The Architecture of Virtual Machines. IEEE Computer, May 2005. IEEE Computer Society, 2005. All rights reserved. Reprinted with permission.

Опе?