Общие сведения о виртуальных машинах (Вдруг кому интересно)

Полезные советы и программы от пользователей нашего форума.

Модератор: Модераторы разделов

Ответить
Аватара пользователя
polachok
Бывший модератор
Сообщения: 2199
Статус: главный форумный маргинал
ОС: gnu/linux
Контактная информация:

Общие сведения о виртуальных машинах

Сообщение polachok »

первая часть моего реферата.
DISCLAIMER не выдаю весь текст за свой: понатыркано из различных источников, ныне почивших и живых. Линки привести не могу.

Часть 1. Общие сведения о виртуальных машинах

Глава 1.Методы запуска приложений других ОС

1.Эмуляция API операционной системы


Обычно приложения работают в изолированном адресном пространстве и взаимодействуют с оборудованием при помощи API, предоставляемым операционной системой. Если две операционные системы совместимы по своим АРI (например, Windows 98 и Windows 2000), то приложения, разработанные для одной из них, будут работать и на другой. Если две операционные системы несовместимы по своим API (например, Windows 2000 и Linux), то существует способ перехватить обрашения приложений к АРI и сымитировать поведение одной операционной сисгемы средствами другой операционной системы.При таком подходе можно поставить одну операционную систему и работать одновременно как с ее приложениями, так и с приложениями друтой операционной системы. Поскольку весь код приложения исполняется без эмуляции и лишь вызовы API эмулируются, потеря в производительности незначительная. Но из-за того что многие приложения используют недокументированные функции API или обращаются к операционной системе в обход API, даже очень хорошие эмулкгоры API имеют проблемы совместимости и позволяют запустить не более 70% от общего числа приложений. Кроме того, поддерживать эмуляцию API бурно развивакицейся операционной системы (например, такой как Windows) очень нелегко и большинство эмуляторов АРI так и остаются эмуляторами какой-то конкретной версии операционной системы. Так, в Windows NT/2000 до сих пор встроен эмулятор для приложений
OS/2 версии I.х, а в последних версиях OS/2 Warp 4 есть возможность запуска приложений Windows 3.11. Но самый большой минус способа эмуляции API - это его строгая ориентация на конкретную операционную систему. Для того, чтобы запустить в нем приложения другой операционной системы, необходимо все переписывать с нуля.Примеры продуктов, выполненных по технологии эмуляции АР1 операционной системы:
Проект с открьпым кодом Wine (Wine Is Not an Emulator),
позволяющий запускать приложения DOS, Win16 и Win32 под операционными системами Unix;
Продукт Win4Lin компании Netraverse, позволяющий запускать
операционные системы семейства Windows под операционной системой Linux;
Проект с открытым кодом DOSEMU, позволяюший запускать
приложения MS DOS под операционной системой Linux;
Проект с открытым кодом User Mode Linux (UМL), позволяющий
запускать несколько копий операционной системы Linux на одном компьютере(в настоящее время встроен в ядро Linux версий 2.6);
Технология Virtuozzo, разработанная российской компанией SWsoft
и позволяющая запускать несколько копий операционной системы
Linux на одном компьютере;
Технология, используемая во FreeBSD для запуска приложений Linux.
Проект SoftPear, в перспективе позволяющий запускать приложения Mac OS X на Linux и FreeBSD

Итоговые оценки по десятибалльной шкале:
Одновременная работа: 9
Многоплатформенность: 0
Производительность: 9
Совместимость: 3

2.Полная эмуляция
Проекты, выполненные по технологии полной эмуляции работают как интерпретаторы. Они последовательно выбирают код гостевой операционной системы и эмулируют поведение каждой отдельно взятой инструкции. Поскольку при этом полностью эмулируется поведение как процессора, так и всех внешних устройств виртуального Intel х86 компьютера, то существует возможность запускать эмулятор на компьютерах с совершенно другой архитектурой, например, на рабочих станциях Mаc или на RISC'овых серверах Sun. Самый серьезный недостаток этого подхода заключается в катастрофической потере производительности гостевой операционной системы.Скорость работы гостевых приложений
может упасть в 100-1000 раз, что означает практическую невозможность нормальной работы с гостевой операционной системой внутри эмулятора. Тем не менее, существуют некоторые технологии, такие как динамическая трансляция, позволяющие увеличить скорость полной эмуляции. Полные эмуляторы чаще всего используются в качестве низкоуровневых отладчиков для исследования и трассировки операционных систем. Примеры проектов, выполненных по технологии полной эмуляции:
Проект с открытым кодом Bochs, позволяющий запускать различные
операционные системы Intel х86 под Linux, Windows, BeOS и Мас
OS;
Продукт Simics компании Virtutech, позволяющий запускать и
отлаживать различные операционные системы Intel х86 под Windows и другими операционными системами.
Продукт Virtual PC фирмы Connectix(ныне купленной Microsoft) позволяющий запускать различные x86-ОС на PC и Mac
Проект Qemu - самый быстрый эмулятор различных архитектур на PC. При использовании модуля Accelerator практически сравнивается по производительности с виртуальными машинами.
Итоговые оценки по десятибалльной шкале:
Одновременная работа: 10
Многоплатформенность: 9
Производительность: 2
Совместимость: 9

3.Квази-эмуляция
Сначала давайте порассуждаем, а почему мы не можем запустить две операционные системы одновременно на одном компьютере? Во-первых, такие внешние устройства, как видео-карта, контроллер IDE, таймер и т.п. разработаны таким образом, чтобы работать под управлением только одной операционной системы. То есть, внешние устройства рассчитаны на монопольное управление только одним драйвером внешнего устройства. Во-вторых, процессор IA-32 разработан в расчете на то, что он будет конфигурироваться и использоваться эксклюзивно одной операционной системой. Это относится к модулю страничной памяти, механизму защиты, сегментной модели и т.п. Другие свойства и инструкции уровня приложений не вызывают проблем и в принципе могут исполняться без эмуляции. К счастью, именно эти инструкции и составляют основную массу кода, исполняемого процессором. Таким образом, существует большое количество инструкций, которые будут нормально исполняться в режиме нескольких операционных систем, и некоторое небольшое количество инструкций, которые должны эмулироваться. Технология квази-эмуляции заключается в том, чтобы обнаружить и сымитировать поведение второго множества инструкций и исполнять инструкции первого множества без эмуляции. Примеры проектов, выполненных по технологии квази-эмуляции:
Виртуальная машина Serenity Virtual Station (SVISTA)(бывшая twoOStwo), разработанная российской компанией Параллели по заказу немецкой компании NetSys GmbH. SVISTA позволяет запускать такие гостевые операционные
системы, как OS/2, Linux, QNX, MSDOS и другие. В настоящий момент существует три продукта: SVISTA для Windows NT/2000/XP, twoOStwo для Linux и twoOStwo для FreeBSD;
Технология Virtual Platform компании VMware, позволяющая
запускать большое количество Intel х86 гостевых операционных систем. Компания VMware предлагает четыре продукта: VMware Workstation для Windows NT/2000/XР, VMware Workstation для Linux, VMware GSX Server (group server) и VMware ESX Server (enterprise server);
Проект с открытым кодом Plex86, позволяющий запускать
различные операционные системы Intel х86 под Linux.
Проект с открытым кодом L4Ka, использующий микроядро
Проект с открытым кодом Xen, позволяет запускать модифицтрованные ОС Linux, FreeBSD, NetBSD и Windows XP под Linux, FreeBSD, NetBSD. При соблюдении некотрых условий позволяет получить даже прирост(!) производительности.
Итоговые оценки по десятибалльной шкале:
Одновременная работа: 10
Многоплатформенность: 5
Производительность: 8
Совместимость: 8


Глава 2.Краткая история виртуальных машин

Первым проектом, в котором возникла концепция системы виртуаньных машин, был проект IBM 7044Х-7044М. А в IBM System/370 появился уже полноценный продукт VM/370. Эта система виртуальных машин претерпела впоследствии немало изменений (версии VM/SP, VМ/ХА, VN/ЕSА) и стала самой распространенной в компьютерной индустрии. В операционной системе VM/370 пользователь получал в свое распоряжение полноразмерный и полнофункциональный виртуальный компьютер, на который он мог поставить собственную версию операционной системы и установить собственное прикладное программное обеспечение. Этот компьютер включал оперативную память, ресурсы процессора, собственные виртуальные периферийные устройства - практически все то, чем обладает обычный компьютер, только в виртуальном виде. Количество обслуживаемых виртуальных компьютеров определялось лицензией, доступными ресурсами памяти, диска, центрального процессора и т.д.
Операционная система VM/370 стала прототипом для отечественной разработки системы СВМ (система виртуальных мжпин). Первая версия системы СВМ 1.1 была выпущена в1982 году комбинатом "Роботрон". В 1983 г. операционную систему СВМ 2.2, базирующуюся на шестом релизе VM/370, выпустил Минский НИИЭВМ. С этого момента система СВМ, не подменяя систем ДОС и ОС, заняла прочное место в базовом программном обеспечении для ЕС ЭВМ. В качестве операционной системы, управляющей работой виртуальной машины, могли использоваться любые операционные системы, разработанные для ЕС ЭВМ (например, ОС ЕС, ДОС ЕС и МОС ЕС).
Совершенствование СВМ в НИИЭВМ в начале 90-х годов привело к разработке операционной системы VM/СВМ. Минская компания IВА, основанная компанией IBM на базе МПО ВТ и НИИЭВМ, до сих пор ведет разработку новых изданий VM/СВМ для мэйнфреймов IВМ.
Инженеры корпорации IBM изначально заложили в архитектуру своих процессоров потенциальную возможность виртуализации и создателям операционной системы VM не пришлось преодолевать специфические аппаратные проблемы. Но архитектура процессоров Intel х86 значительно отличается от архитектуры процессоров IBM и не может бьпь виртуализована "простым" способом. Здесь по определению предполагается, что ядру работающей на этой платформе операционной системе будуг доступны абсолютно все ресурсы процессора. Поэтому отчуждение отдельно взятой операционной системы от процессора и установка промежуточных виртуализующих слоев теоретически невозможна. Попытка запустить две операционные системы на одном компьютере просто приведет к конфликту между ними.
И пионером технологии виртуальных машин на платформе Intel х86 стала компания VMware.
VMware была создана на базе Стэндфордского университета профессором Менделем Розенблюмом и его супругой Дианой Грин в 1998 году. Компания разработала технологию Virtual Platform для виртуализации IA-32 систем, и уже в 1999 году выпустила первую виртуальную машину VMware Workstation для операционной системы Linux. Чем произвела немалый переполох и снискала себе вечную славу в Linux сообществе.
В тоже самое время задачей виртуализации процессоров Intel х86 занималась небезызвестная компания Connectix. В 1997 году она выпустила эмулятор Virtual PC для Мас, позволяющий запускать операционные системы DOS и Windows на макинтошах. А в 1999 году вышла виртуальная машина Virtual PC для Windows, исполняющая различные операционные системы


под Windows NT/9х. Большую популярность компания Connectix снискала в OS/2 сообществе после выхода Virtual РС для OS/2, разработанного совместно с немецкой компанией InnoTek


Глава З.Общая концепция

Система виртуальных машин может быть построена на базе различных аппаратных платформ при помощи разных технологий. Схема виртуализации может отличаться в зависимости, как от используемой платформы, так и от выбора определенной операционной системы. Некоторые архитектуры обеспечивают возможность виртуализации аппаратно, другие, такие как IA-32, требуют использования дополнительных программных ухищрений. В принципе, система виртуальных машин может быть построена с использованием микро-ОС(либо микроядра - как в проекте L4Ka), которая взяла бы на себя функции управления устройствами и системными свойствами процессора. Операционные системы второго уровня и их приложения могли бы работать одновременно и без какой-либо виртуализации, используя микро-ОС для выполнения системных операций и работы с внешними устройствами. Однако, существующие операционные системы напрямую работают с процессором и внешними устройствами. Для работы с такими операционными системами, наша микро-ОС должна уметь отлавливать обращения к системным ресурсам и эмулировать их поведение. Одной из главных проблем разработки собственной микро-ОС является необходимость написания драйверов для поддержки десятков тысяч внешних устройств. К счастью, возможно использование средств уже существующей операционной системы для работы с реальными внешними устройствами. Это позволяет избежать необходимости написания собственных драйверов и сосредоточиться на технологии виртуализации. Операционная система, управляющая реальным оборудованием и предоставляющая функции для доступа к нему, называется "хостовой операционной системой". Хостовая операционная система загружается самостоятельно и не требует виртуальной машины для своей работы. Операционные системы, работающие в виртуальных машинах, называются "гостевыми операционными системами". На одном физическом компьютере может быть запущена одна хостовая и много гостевых операционных систем.
Общая системная архитектура виртуальной машины построена на взаимодействии трех основных компонентов: приложение виртуальной машины; драйвер виртуальных машин; монитор виртуальной машины.
Приложение виртуальной машины - это обычное приложение, выполняющееся под управлением хостовой операционной системы. Приложение виртуальной машины имеет графический интерфейс и позволяет пользователю взаимодействовать с виртуальной машиной и гостевой операционной системой. Приложение является непереносимым компонентом виртуальной машины, поскольку разрабатывается для конкретной хостовой операционной системы и использует ее функции для отображения графического интерфейса и доступа к внешним устройствам. Как правило, для портирования виртуальной машины под другую хостовую операционную систему, необходимо полностью переписать приложение.
Приложение виртуальной машины построено по многопоточной технологии и поддерживает три основных потока:
Поток виртуализации для передачи управления монитору и обмена
информационными сообщениями с ним;
Графический поток для отображения видеобуфера гостевой
операционной системы;
Поток GUI для работы пользовательского интерфейса и передачи
событий от мыши и клавиатуры гостевой операционной системе.



Для каждой виртуальной машины запускается своя копия приложения виртуальной машины. Приложение виртуальной машины выполняег следующие OCHOBHЫЕ функции:
Создание, удаление и конфигурирование виртуальных машин;
Включение, вьпслючение и управление работой виртуальных машин;
Обеспечение интерфейса пользователя с гостевой операционной
системой ввод с клавиатуры (мыши) и отображение экрана гостевой операционной системы;
Выделение памяти для виртуальной машины и загрузка (инициализация) монитора виртуальной машины;
Взаимодействие с физическими ресурсами компьютера через функции хостовой операционной системы (работа с жесткими и гибкими дисками, видеокартой, последовательными и параллельными портами и т.д.).
Драйвер виртуальных машин - это системный драйвер работающий на уровне привилегий ядра хостовой операционной системы. Драйвер является шлюзом между приложением и монитором виртуальной машины, позволяющий им передавать управление и обмениваться информационными сообщениями между собой. Кроме того, драйвер выполняет функции взаимодействия с хостовой операционной системой, такие как выделение и закрепление страниц памяти по физическим адресам. Драйвер виртуальной машины является непереносимым компонентом виртуальной машины. Для портирования виртуальной машины под другую хостовую операционную систему необходимо полностью переписать драйвер используя средства этой операционной системы. Все виртуальные машнны пользуются одной копией драйвера виртуальных машин.
Монитор виртуальной машины - это основной компонент виртуальной машины. Монитор не зависит от конкретной хостовой операционной системы и отвечает за создание виртуальной среды для исполнения гостевой операционной системы. Монитор работает на уровне привилегий ядра хостовой операционной системы и реализует выбранную технологию виртуализации. Поскольку монитор включает в себя блок эмуляции процессора и внешних устройств, то время от времени он вынужден обращаться к приложению для доступа к реальным внешним устройствам. Для каждой виртуальной машины запускается своя копия монитора виртуальной машины. Монитор может взаимодействовать с приложением двумя способами:
Синхронно при помоши обмена информационными сообщениями через драйвер виртуальных машин;
Асинхронно при помощи разделяемых системных структур и участков памяти.
Монитор работает в изолированном от хостовой операционной системы контексте и поддерживает свои собственные системные таблицы GDT, LDT, IDT и т.д. При переключении контекста между монитором и хостовой операционной системой выполняется операция сохранения одного контекста и загрузка другого. Переключение контекста напоминает процедуру переключения задач операционной системы, но включает в себя дополнительный набор данных. Также, монитор должен отлавливать и перенаправлять хостовой операционной системе все прерывания от реальных внешних устройств

Глава 4.Технология квази-эмуляции

Процессор изначально может быть спроектирован так, чтобы аппаратно поддерживать внртуализацию. Это значит, что на пользовательском уровне привилегий все инструкции, работающие с системными регистрами процессора, вызывают исключение процессора, позволяя виртуализующему монитору эмулировать их поведение.
К сожалению, архитектура процессора IA-32 не поддерживает полностью виртуализацию на аппаратном уровне. Некоторые инструкции на пользовательском уровне привилегий при записи в системные регистры генерируют исключение процессора, а при чтении из системных регистров нет. Таким образом, при попытке виртуализовать эти системные регистры для гостевой операционной системы мы столкнемся с ситуацией, когда гостевой код прочтет из этих регистров совсем не то, что он туда записывал. И, следовательно, путь исполнения гостевой операционной системы изменится. Говоря по-простому, гостевая операционная система вылетит с синим/черным/зеленым/желтым экраном.
Квази-эмуляция - это технология, позволяющая аппаратно невиртуализуемый процессор виртуализовать программным путем. Основные задачи квази-эмуляции можно сформулировать следующим образом:
Необходимо определить множество инструкций процессора, которые можно исполнять без эмуляции. Все системные регистры и области процессора, с которыми работают эти инструкции, надо поддерживать в состоянии, ожидаемом гостевой операционной системой; Необходимо определить множество инструкций процессора, которые нельзя исполнять без эмуляции. Надо обеспечить обнаружение этих инструкций в гостевом коде и произвести их эмуляцию. В тех случаях, когда для эмуляции требуется взаимодействие с хостовой операционной системой (например, при эмуляции внешних устройств), надо обеспечить переключение в контекст хосговой операционной системы и использовать ее функции. Для нормального функционирования хостовой операционной системы надо обеспечить передачу ей прерываний от внешних устройств, произошедших в контексте монитора или гостевой операционной системы.
Существуют различные программные техники, позволяющие решать задачи квази-эмуляции.
Рассмотрим две наиболее популярные техники, используемые в большинстве проектов виртуализации и эмуляции, "технику программного отладчика" и "технику динамической трансляции".
Техника программного отладчика
Эта техника позаимствована у программных отладчиков и заключается в установке точек прерывания на эмулируемые инструкции гостевого кода. При старте виртуального компьютера монитор начинаег анализировать гостевой код с процедуры POST из ROM BIOS, расположенный по адресу FFFF:FFFO. Он выбирает по очереди инструкции гостевого кода и проставляег точки прерывания на все эмулируемые инструкции. Как только встречается инструкция ветвления с неопределенным адресом перехода (например, косвенный JMP), монитор просгавляет на нее точку прерывания и передает управление отсканированному коду.
При исполнении гостевого кода монитор гарантированно получает прерывания по каждой эмулируемой инструкции и выполняет соответствующий код эмуляции, В момент получения прерывания от последней отсканированной инструкции (как мы помним это инструкция перехода) монитор определяет адрес перехода и повторяет процедуру сканирования для нового алреса. Таким образом обеспечивается постоянный контроль за выполнением гостевого кода и эмуляция всех необходимых инструкций. Основная проблема техники программного отладчика это значительные накладные расходы на обработку прерывания и переключение контекста "гостевая операционная система" - "монитор" при эмуляции каждой инструкции.

Техника динамической трансляции
При использовании техники динамической трансляции монитор выступает как компилятор гостевого кода. Монитор просматривает исходный гостевой код и преобразует его в исполняемый гостевой код. При этом эмулируемые инструкции заменяются на набор инструкций эмуляции непосредственно в исполняемом гостевом коде. Поскольку вместо одной эмулируемой инструкции может быть вставлено 10 - 20 инструкций эмуляции, линейные адреса отдельных участков гостевого кода съезжают. Следовательно, адреса всех инструкций перехода тоже должны быть скорректированы.
Для всех инструкций гостевого кода необходимо поддерживать hash-таблицу преобразований линейных адресов, чтобы по адресу инструкции в исходном коде можно было получить ее адрес в откомпилированном коде и наоборот. Это требует значительных накладных расходов на процедуру трансляции гостевого кода. Зато уже обработанный гостевой код исполняется очень быстро и без накладных расходов, так как эмуляция производиться непосредственно в нсполняемом коде.

Обе описанные техники модифицируют исходный гостевой код перед его исполнением.
Поэтому при виртуализации "самомодифицирущегося" и "самочитающегося" кода возникают проблемы. Существуют различные пути решения этих проблем. С "самомодифицирующимся" кодом легко справиться при помощи механизма страничной защиты. А вот для решения проблемы "самочитающегося" кода архитектура IA-32 не предлагает никакого адекватного средства (если бы только существовал страничный атрибут "execute only"). Поэтому способы защиты от "самочитающегося" кода являются важнейшими know-how авторов различных технологий виртуализации.
Очень часто технология квази-эмуляции использует как технику программного отладчика, так и технику динамической трансляции. Техника программного отладчика эффективней для однократно исполняемых участков кода с небольшим содержанием эмулируемых инструкций.
А техника динамической трансляции эффективней для часто повторяемых участков кода с большим содержанием эмулируемых инструкций. Например, можно использовать динамическую трансляцию для виртуализации ядра гостевой операционной системы, а программную отладку для виртуализации кода приложений.

Эмуляция процессора
По аналогии с контекстом отдельного процесса можно ввести понятие контекста операционной системы. Для этого контекст процесса надо расширить системными регистрами CROx, дескрипторными таблицамн GDT, LDT, IDT, страничными таблицами PDE, PTE, отладочными регистрами DROx и т.д. В схеме виртуализации присутствует три независимых контекста контекст хостовой операционной системы, контекст монитора виртуальной машины и контекст гостевой операционной системы. Если контексты хостовой и гостевой операционных систем абсолютно независимы, то контекст монитора является некоторым расширением контекста гостевой операционной системы.
Рассмотрим простейшую схему виртуализации, в которой задействовано только два кольца защиты процессора: кольцо 0 привилегированный уровень и кольцо 3 пользовательский уровень. В этом случае основные компоненты виртуальной машины будут распределены следующим образом:
Приложение виртуальной машины хостовый контекст, кольцо 3;
Драйвер виртуальных машин хостовый контекст, кольцо 0;
Монитор виртуальной машины гостевой контекст, кольцо 0;
Гостевая операционная система и ее приложения гостевой контекст, кольцо 3.
Таким образом, для эмуляции инструкции гостевого кода, не требующей функций хостовой операционной системы, необходимо выполнить одно переключение из кольца 3 в кольцо 0 гостевого контекста. В противном случае надо вьполнить целых три переключения сначала из кольца 3 в кольцо 0 гостевого контекста, затем из кольца 0 гостевого контекста в кольцо 0 хостового контекста, и, наконец, из кольца 0 в кольцо 3 хостового контекста. А потом, естественно, надо переключиться обратно
Как уже говорилось, контекст монитора является расширением контекста гостевой операционной системы. Величина этого расширения зависит от выбранной стратегии виртуализации. Существует два противоположных подхода к эмуляции системных областей процессора:
Использование механизма страничной зашиты для эмуляции системной области и запуск всех работающих с областью инструкций без эмуляции (например, защита и эмуляция таблицы GDT и запуск инструкций загрузки/чтения сегментных регистров без эмуляции); Разрешение свободной записи/чтения системной области и эмуляция всех работающих с областью инструкций (например, свободная запись/чтение в таблицу GDT и эмуляция инструкций загрузки/чтения сегментных регистров).
Как и всегда в этой жизни, выбор неоднозначен:) Для некоторых видов гостевого кода эффективней первый метод, для других второй. Продвинутая схема виртуализации должна применять оба метода адаптивно.
Схема виртуализации должна обеспечивать:
Эмуляцию сегментной модели процессора GDT, LDT и IDT;
Эмуляцию страничной модели процессора PDE и PTE;
Эмуляцию колец защиты процессора;
Эмуляцию исключений и прерываний процессора;
Эмуляцию набора инструкций процессора.
Эмуляция внешних устройств
Для взаимодействия с внешними устройствами процессор использует инструкции ввода/вывода ( IN, OUT) и отмапированные участки адресного пространства. Виртуализационная схема может использовать два различных метода эмуляции внешних устройств: метод полной эмуляции и/или метод сквозного взаимодействия. В первом случае, все регистры и области устройства полностью эмулируются, а для взаимодействия с реальным устройством используются функции хостовой операционной системы. При этом реальное устройство может использоваться виртуальной машиной совершенно не так, как это предполагалось гостевой
операционной системой.
Например, виртуальный CD-ROM может бьпь отображен как на реальный CD-ROM, так и в файл на жестком диске. Несмотря на то, что виртуальная машина может запускаться на самых разных компьютерах с разными конфигурациями, для гостевой операционной системы всегда будет эмулироваться единый набор виртуального "железа". То есть, один раз настроенную и проинсталлированную виртуальную машину можно переносить с одного компьютера на другой, не заботясь о совместимости.
Для метода сквозного взаимодействия необходимо осуществить монопольный захват реального устройства одной виртуальной машиной. В процессе работы оно будег недоступно ни хостовой операционной системе, ни другим виртуальным машинам. При этом устройство не эмулируется, а напрямую используется гостевой операционной системой. Все команды гостевой операционной системы перехватываются монитором и перенаправляются захваченному устройству. Естественно, ни о какой совместимости здесь речь уже не идет. Зато возможна работа гостевой операционной системы с устройствами, которые не поддерживаются хостовой операционной системой.
И немедленно выпил.
Спасибо сказали:
Renso
Сообщения: 7

Re: Общие сведения о виртуальных машинах

Сообщение Renso »

Здорово...
Правда можешь win4lin в стан полной эмуляции переводить,
они теперь в win4lin pro qemu как основу используют...
Спасибо сказали:
Аватара пользователя
alv
Бывший модератор
Сообщения: 7274
Статус: Пенсионер в законе
ОС: Cintu
Контактная информация:

Re: Общие сведения о виртуальных машинах

Сообщение alv »

Мощное сочинение. Если хотите - можно будет по завершении разместить на unix.ginras.ru
Спасибо сказали:
Аватара пользователя
polachok
Бывший модератор
Сообщения: 2199
Статус: главный форумный маргинал
ОС: gnu/linux
Контактная информация:

Re: Общие сведения о виртуальных машинах

Сообщение polachok »

2 alv
собственно, дела обстоят так: Часть 1. Общеознакомительная. см вверху. Часть 2. Перевод про технологию VMWare 3
Часть 3. Перевод про QEmu. Где-то здесь неподалеку лежит.
Если хотите можете выложить эту, первую. Третья-то у вас есть уже. Вторую нужно еще привести в порядок.
И немедленно выпил.
Спасибо сказали:
Ответить