Чем виртуализация отличается от эмуляции с точки зрения структуры?


20

Кто-то сказал мне, что виртуализирующая программа, такая как VirtualBox, не работает, как эмулятор, в том смысле, что она не эмулирует регистры и использует реальные для виртуализированных данных, которые находятся на ЦП. Эмуляторы должны эмулировать регистры, поскольку они в основном предназначены для запуска программного обеспечения, которое зависит от внешней среды (например, эмулятору Genesis требуются регистры и адреса памяти Motorola 68000, поэтому разработчик должен сделать эти ресурсы доступными в виде эмулируемых регистров).

Мой главный вопрос: как развивается виртуализация? Как мы можем позволить всей ОС работать как процесс на виртуальной машине, но заставить ее работать независимо, при этом используя фактический процессор? Я знаю только эмуляцию, а не виртуализацию, так что если бы кто-нибудь мог помочь, это было бы здорово!

PS: я спрашиваю не только о разнице, а о том, как они работают с программным обеспечением.

Ответы:


32

Первоначально, вы не могли позволить гостевой ОС использовать реальное оборудование, потому что у вас не было возможности управлять им. Если вы пытались запустить его на реальном процессоре, у вас не было никакой гарантии, что он вернет управление обратно операционной системе.

Виртуализация, как вы ее описали, реализована на аппаратном уровне, позволяя применять определенные правила и ограничения на аппаратном уровне, которым может управлять хост-ОС. Это позволяет операционной системе хоста устанавливать правила о том, что гость может и не может делать, а затем фактически запускать гость на реальном оборудовании. Если гость пытается что-то сделать с реальным оборудованием, которое нарушает правила (например, пытается получить доступ к дисковому устройству), оборудование приостановит гостя и отправит хосту прерывание, которое позволяет хосту предоставить ответ (например, возвращение данных с эмулируемого дискового устройства), а затем возобновите гостевую.

Вот упрощенный пример процесса:

ОС хоста: Эй, процессор, мне нужно, чтобы вы виртуализировали этот код. Позвоните мне, если он хочет сделать что-то, что не просто выполняет инструкции.

Процессор хоста: Вы получили это!
ЦП хоста сохраняет все регистры и состояние хоста, а затем начинает выполнение кода гостевой ОС

Гостевая ОС: я жива! Эй, процессор, ты можешь достать мне этот файл?

Процессор хоста: Э-э ... конечно. Один момент.
ЦП хоста сохраняет все гостевые регистры и состояние, а затем восстанавливает все регистры и состояние
хоста. ЦП хоста: Привет, ОС хоста, Гость хотел этот файл!

ОС хоста: О, хорошо, дайте им это: Файл с виртуального жесткого диска

Процессор хоста: Вы получили это!
ЦП хоста сохраняет все регистры и состояние хоста, восстанавливает гостевые регистры и состояние, а затем начинает выполнять код гостевой ОС.
ЦП хоста: вот этот файл!

Гостевая ОС: Сладко, спасибо!

Ключевое отличие здесь заключается в эмуляторе, гостевая ОС фактически никогда не работает на оборудовании. При виртуализации хост-ОС настраивает ограничения в ЦП, а затем фактически запускает гостевой код на физическом ЦП. Приведенный выше пример чрезвычайно упрощен, но память, дисковый ввод-вывод и даже работа в сети можно контролировать на самых современных современных процессорах, что позволяет им безопасно взаимодействовать без необходимости каждый раз беспокоить операционную систему хоста. До тех пор, пока гость не пытается выйти за виртуализированные границы, то на хост-ОС может не работать какой-либо код, если в данный момент времени ему нечего делать.


Чтобы добавить немного перспективы, это просто еще один шаг в долгой истории виртуализации и управления. (Нет гарантий, что это в правильном порядке или является исчерпывающим, но должно дать хороший начальный обзор)

Первоначально не было никакой виртуализации. Все процессы совместно используют одно и то же пространство памяти, все имеют полный доступ к аппаратному обеспечению, а возможность многозадачности полностью зависит от остановки одного процесса и передачи управления следующему процессу. Если ОС хотела иметь какой-либо контроль над процессом, она должна была запускать процесс в эмуляторе (никто не делал, потому что это было слишком мучительно медленно).

Сначала была Привилегированная память : определенные действия, которые могут быть выполнены только специальными областями памяти. Эти регионы заняты ОС, что позволяет ей действовать в качестве шлюза для этих привилегированных действий. Примером является возможность чтения / записи данных на оборудование. Это предотвращает процессы чтения / записи непосредственно на жесткий диск и вместо этого заставляет их запрашивать у ОС чтение / запись для них. Это означает, что ОС может проверить, есть ли у процесса разрешение перед выполнением действия.

Далее пришло виртуализированное «время» как бы. ОС может настроить ЦП на прерывание активного процесса через заданные интервалы, что позволит ему контролировать планирование и переключаться между процессами. Операционная система теперь может запускать процессы непосредственно на оборудовании и при этом предотвращать неправильное использование процессорного времени. Это было обеспечено аппаратным таймером .

Затем появилась виртуализированная память : проблема с разделяемой памятью заключается в том, что любой процесс может читать память любого другого процесса. Что происходит, когда программа Мэри считывает пароль Боба из своего веб-браузера? Виртуальная память позволяет ОС отображать память, которую видит процесс, в различные части физической памяти или даже полностью перемещать их из физической памяти (в файл подкачки). Каждый раз, когда процесс пытается читать или записывать в память, VMMU (блок управления виртуальной памятью) ЦП ищет, где он отображается в физической памяти, и выполняет действие там. Если он сопоставлен с памятью, то ЦП вызывает ОС для извлечения страницы в память из файла подкачки.

Итак, на данный момент мы достигли начала процессоров X86, где мы можем безопасно запускать процессы и активно предотвращать их захват системы, если ОС специально не позволяет им делать это. На этом этапе процессы фактически «виртуализированы». Эта поддержка существует уже давно , поэтому вы на самом деле не слышите, чтобы люди говорили о виртуализированных процессах, поскольку предполагается, что все процессы теперь виртуализированы.

Почему виртуализированные ОС особенные? Почему мы не можем просто запустить его как процесс и позволить ему делать свое дело? Проблема в том, что в качестве ОС гостевая система рассчитывает получить доступ и использовать те же элементы управления, которые использует хост для управления процессами - в основном ОС ожидает, что она будет верховным правителем компьютера, и они просто не не работает, если это не так. Расширения «Аппаратная виртуализация» (AMD-V для AMD и VT-x для Intel) позволяют хост-системе предоставлять виртуализированный набор элементов управления виртуальными процессами (виртуальная привилегированная память, виртуальные аппаратные таймеры, виртуальная виртуальная память).


Напоминает мне одноактную пьесу IRC, которую я видел однажды (возможно, NSFW: содержит немного языка PG-13)
Скотт Чемберлен

На моем компьютере нет аппаратной виртуализации (AMD-V или VT-x). Но я могу запустить виртуальную машину на VirtualBox ... VirtualBox устанавливает драйвер на ОС, чтобы иметь возможность сделать это. Как это сделать?
NothingsImpossible

1
@NothingsImpossible: если у вас нет очень старой машины, большинство распространенных в настоящее время процессоров поддерживают аппаратную виртуализацию. Базовая виртуализация всегда возможна, потому что процессор отправит прерывание супервизору (ядру), если какая-либо программа (например, гостевая ОС) попытается выполнить инструкции, которые не разрешены на текущем уровне безопасности. Все, что нужно сделать ОС хоста, - перехватить эти прерывания, выяснить желаемую операцию и возобновить выполнение дочернего процесса. AMD-V / VT-x обеспечивает более эффективную виртуализацию, поскольку теперь сам процессор может выполнять «запрещенные» инструкции.
Ли Райан

@LieRyan Спасибо за объяснение. Но это не старый, это процессор Atom. Вот этот, если быть точным: ark.intel.com/products/70105
NothingsImpossible

1

Как мы можем позволить всей ОС работать как процесс на виртуальной машине, но заставить ее работать независимо, при этом используя фактический процессор?

(Следующее сильно упрощено.)

Используя тот же или аналогичный механизм, который ОС использует для поддержания процессов пользовательского режима в основном.

Процессы пользовательского режима вызовут исключения CPU, когда они попытаются сделать то, что им не разрешено.

Итак, если у нас ядро ​​ОС запущено в пользовательском режиме, то всякий раз, когда оно пытается сделать что-то вроде прямого доступа к оборудованию, это вызовет исключение. Гипервизор может использовать это исключение и реагировать эмулированным или виртуализированным поведением, вместо того, чтобы вызвать системный сбой, как обычное ядро.

Он может осуществлять аппаратный доступ от имени этого ядра, выполнять модифицированный аппаратный доступ (т. Е. Получать доступ к части файла вместо прямого доступа к сектору диска) или к чему-либо еще, о чем вы могли только мечтать.

Расширения виртуальной машины ЦП в основном расширяют весь «супервизор» или «защищенный» режим ЦП на еще один уровень для выполнения именно этого, а также обеспечивают дополнительный «уровень вложенности» виртуальной памяти, что упрощает виртуализацию подкачки.


0

Виртуализация включает в себя моделирование частей аппаратного обеспечения компьютера - достаточно для того, чтобы гостевая операционная система работала без изменений - но большинство операций по-прежнему выполняются на реальном оборудовании по соображениям эффективности. Поэтому виртуализация обычно быстрее, чем эмуляция, но реальная система должна иметь архитектуру, идентичную гостевой системе. Например, VMWare может предоставить виртуальную среду для запуска виртуальной машины с Windows XP «внутри» реальной. Однако VMWare не может работать ни на каком реальном оборудовании, кроме настоящего x86-ПК.

В эмуляции виртуальная машина имитирует все аппаратное обеспечение в программном обеспечении. Это позволяет операционной системе для одной компьютерной архитектуры работать на архитектуре, для которой написан эмулятор. Поскольку все операции выполняются в программном обеспечении, эмуляция имеет тенденцию быть медленной, однако может поддерживать больше платформ, поскольку она не зависит от оборудования.


Хорошо ... но как вы подразумеваете "моделирование" частей оборудования? Эмулятор делает то же самое ... как виртуализация позволяет гостевой ОС использовать реальные ресурсы процессора?
тонны бонов

@tonsbons: по определению. : P Эмулятор не делает то же самое - он эмулирует все, начиная от процессора и выше. Например, Bochs - это эмулятор. Виртуализация тоньше; Гипервизор запускает гостевую ОС на физическом процессоре (в основном обманывая гостя в том, что он владеет процессором). Так как у гостя нет привилегий, которые он считает, что он имеет, однако, он вызывает "ошибки", когда он пытается делать вещи ядра. Гипервизор отслеживает эти сбои и переключает виртуальное оборудование, чтобы оно выглядело для гостя, как будто эти операции действительно произошли.
Чао

0

Просто для полноты, есть также симуляция , в которой действия машины дублируются, но с использованием кода, чьи внутренние компоненты могут радикально отличаться от «реальной» машины. (Подумайте «симулятор полета».) Часто симуляторы компилируют исходный код «реальной» машины, но нацелены на совершенно другую архитектуру ЦП с совершенно другими средствами ОС и ввода-вывода.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.