Виртуальная машина и эмулятор разница
QEMU (Quick EMUlator) или VirtualBox
QEMU — это программное обеспечение с открытым исходным кодом, используемое для виртуализации и в качестве эмулятора, тогда как другой инструмент VirtualBox используется для виртуализации. Прежде чем углубляться в эти инструменты, давайте взглянем на концепцию эмуляции и виртуализации:
Эмуляция — это вычислительный феномен, который позволяет одному компьютеру вести себя как другой компьютер, например, запускать другое программное обеспечение, созданное не для этого компьютера специально, например, консольные игры на вашем ПК или выполнение программного обеспечения для Windows на Mac.
Виртуализация, как следует из названия, представляет собой акт создания копии или виртуальной версии чего-либо, и на компьютерах ресурсы могут использоваться совместно с компьютерами для создания большего количества рабочих машин, обычно называемых виртуальными машинами. С другой стороны, VirtualBox — еще один полезный инструмент, специально созданный для виртуализации. Его можно установить на один компьютер, и с помощью виртуализации вы можете получить больше операционных систем вместе с родительской ОС.
Оба инструмента широко используются из-за их функциональности и требований современной эпохи, поэтому в нашей сегодняшней статье мы обсудим оба инструмента:
Плюсы и минусы VirtualBox
Давайте посмотрим на некоторые плюсы и минусы VirtualBox:
Минусы
Плюсы и минусы QEMU
В этом разделе перечислены заметные плюсы и минусы QEMU:
Плюсы
Минусы
Ключевые различия между QEMU и VirtualBox
Как обсуждалось ранее, QEMU можно использовать для эмуляции и виртуализации, однако VirtualBox можно использовать только для виртуализации. QEMU имеет двойную поддержку эмуляции и виртуализации, тогда как последняя предоставляет только функции виртуализации. Следя за этой точкой зрения, мы перечислили несколько различий между обоими инструментами:
Удобство использования: первое, что замечают пользователи, — это интерфейс и простота использования. В этом отношении VirtualBox превосходит QEMU, поскольку VB более удобен для пользователя, тогда как QEMU сложно установить и использовать.
Поддержка архитектуры: Архитектура обработки, поддерживаемая VirtualBox, основана на x32bit и x64bit; однако QEMU имеет длинный список поддерживаемых архитектур, таких как ARM, Alpha, SPARC. Поэтому QEMU рекомендуется для пользователей продвинутого уровня и для разработчиков ядра. С другой стороны, VirtualBox лучше подходит для пользователей, которые хотят запустить несколько операционных систем на одной машине без препятствий для двойной загрузки.
Настройка: функция настройки VirtualBox занимает больше времени, чем QEMU и даже другие конкуренты; Одна из причин заключается в том, что VB прост в использовании, а параметры настройки понятны и для начинающих пользователей. Хотя VB удобен для пользователя и прост в настройке, QEMU старше VirtualBox и, что интересно, VB использует несколько компонентов QEMU для виртуальных машин.
Виртуализация: для виртуализации QEMU должен быть объединен с KVM (модулем Linux), чтобы действовать как виртуальная машина, тогда как пользователи могут напрямую создавать виртуальные машины в VirtualBox без добавления каких-либо дополнительных компонентов.
Удовлетворенность конечного пользователя: Основное различие между обоими инструментами заключается в том, что VirtualBox оценивается как хороший, когда дело доходит до удовлетворенности конечного пользователя, тогда как QEMU не хватает этой функции, поэтому QEMU попадает в недооцененное ведро.
Заключение
В эту современную эпоху виртуализация и эмуляция проложили путь для любителей техники, позволяя им запускать любую ОС на своей родительской ОС и запускать программное обеспечение, недоступное для их машин. Для выполнения этих действий доступно несколько инструментов, позволяющих включить поддержку виртуализации и эмуляции. Например, QEMU — это инструмент, который поддерживает виртуализацию, а также эмуляцию, тогда как другой инструмент VirtualBox позволяет только виртуализацию. В этом руководстве мы представили подробное сравнение этих инструментов и пришли к выводу, что, если вы профессионально играете с технологиями, вы можете выбрать QEMU для виртуализации и эмуляции, тогда как VirtualBox лучше всего подходит для начинающих пользователей, чтобы виртуализировать ОС своих выбор.
Чем виртуализация отличается от эмуляции с точки зрения структуры?
Кто-то сказал мне, что виртуализирующая программа, такая как VirtualBox, не работает, как эмулятор, в том смысле, что она не эмулирует регистры и использует реальные для виртуализированных данных, которые находятся на ЦП. Эмуляторы должны эмулировать регистры, поскольку они в основном предназначены для запуска программного обеспечения, которое зависит от внешней среды (например, эмулятору Genesis требуются регистры и адреса памяти Motorola 68000, поэтому разработчик должен сделать эти ресурсы доступными в виде эмулируемых регистров).
Мой главный вопрос: как развивается виртуализация? Как мы можем позволить всей ОС работать как процесс на виртуальной машине, но заставить ее работать независимо, при этом используя фактический процессор? Я знаю только эмуляцию, а не виртуализацию, так что если бы кто-нибудь мог помочь, это было бы здорово!
PS: я спрашиваю не только о разнице, а о том, как они работают с программным обеспечением.
Первоначально, вы не могли позволить гостевой ОС использовать реальное оборудование, потому что у вас не было возможности управлять им. Если вы пытались запустить его на реальном процессоре, у вас не было никакой гарантии, что он вернет управление обратно операционной системе.
Виртуализация, как вы ее описали, реализована на аппаратном уровне, позволяя применять определенные правила и ограничения на аппаратном уровне, которым может управлять хост-ОС. Это позволяет операционной системе хоста устанавливать правила о том, что гость может и не может делать, а затем фактически запускать гость на реальном оборудовании. Если гость пытается что-то сделать с реальным оборудованием, которое нарушает правила (например, пытается получить доступ к дисковому устройству), оборудование приостановит гостя и отправит хосту прерывание, которое позволяет хосту предоставить ответ (например, возвращение данных с эмулируемого дискового устройства), а затем возобновите гостевую.
Вот упрощенный пример процесса:
ОС хоста: Эй, процессор, мне нужно, чтобы вы виртуализировали этот код. Позвоните мне, если он хочет сделать что-то, что не просто выполняет инструкции.
Процессор хоста: Вы получили это!
ЦП хоста сохраняет все регистры и состояние хоста, а затем начинает выполнение кода гостевой ОС
Гостевая ОС: я жива! Эй, процессор, ты можешь достать мне этот файл?
ОС хоста: О, хорошо, дайте им это: Файл с виртуального жесткого диска
Процессор хоста: Вы получили это!
ЦП хоста сохраняет все регистры и состояние хоста, восстанавливает гостевые регистры и состояние, а затем начинает выполнять код гостевой ОС.
ЦП хоста: вот этот файл!
Гостевая ОС: Сладко, спасибо!
Ключевое отличие здесь заключается в эмуляторе, гостевая ОС фактически никогда не работает на оборудовании. При виртуализации хост-ОС настраивает ограничения в ЦП, а затем фактически запускает гостевой код на физическом ЦП. Приведенный выше пример чрезвычайно упрощен, но память, дисковый ввод-вывод и даже работа в сети можно контролировать на самых современных современных процессорах, что позволяет им безопасно взаимодействовать без необходимости каждый раз беспокоить операционную систему хоста. До тех пор, пока гость не пытается выйти за виртуализированные границы, то на хост-ОС может не работать какой-либо код, если в данный момент времени ему нечего делать.
Чтобы добавить немного перспективы, это просто еще один шаг в долгой истории виртуализации и управления. (Нет гарантий, что это в правильном порядке или является исчерпывающим, но должно дать хороший начальный обзор)
Первоначально не было никакой виртуализации. Все процессы совместно используют одно и то же пространство памяти, все имеют полный доступ к аппаратному обеспечению, а возможность многозадачности полностью зависит от остановки одного процесса и передачи управления следующему процессу. Если ОС хотела иметь какой-либо контроль над процессом, она должна была запускать процесс в эмуляторе (никто не делал, потому что это было слишком мучительно медленно).
Сначала была Привилегированная память : определенные действия, которые могут быть выполнены только специальными областями памяти. Эти регионы заняты ОС, что позволяет ей действовать в качестве шлюза для этих привилегированных действий. Примером является возможность чтения / записи данных на оборудование. Это предотвращает процессы чтения / записи непосредственно на жесткий диск и вместо этого заставляет их запрашивать у ОС чтение / запись для них. Это означает, что ОС может проверить, есть ли у процесса разрешение перед выполнением действия.
Затем появилась виртуализированная память : проблема с разделяемой памятью заключается в том, что любой процесс может читать память любого другого процесса. Что происходит, когда программа Мэри считывает пароль Боба из своего веб-браузера? Виртуальная память позволяет ОС отображать память, которую видит процесс, в различные части физической памяти или даже полностью перемещать их из физической памяти (в файл подкачки). Каждый раз, когда процесс пытается читать или записывать в память, VMMU (блок управления виртуальной памятью) ЦП ищет, где он отображается в физической памяти, и выполняет действие там. Если он сопоставлен с памятью, то ЦП вызывает ОС для извлечения страницы в память из файла подкачки.
Как виртуализация отличается от эмуляции с точки зрения структуры?
Кто-то сказал мне, что виртуализационная программа, такая как VirtualBox, не работает, как эмулятор, в том смысле, что она не эмулирует регистры и использует фактические для виртуализированных данных, находящихся на процессоре. Эмуляторы должны эмулировать регистры, поскольку они в основном предназначены для выполнения программного обеспечения, зависящего от внешней среды (например, эмулятор Genesis нуждается в регистрах и адресах Motorola 68000, поэтому разработчик должен сделать эти ресурсы доступными как эмулированные регистры).
Мой главный вопрос: как развивается виртуализация? Как включить полную ОС для запуска в качестве процесса на виртуальной машине, но заставить ее работать независимо, все еще используя фактический процессор? Я знаю только эмуляцию, а не виртуализацию, поэтому, если кто-то может помочь, это будет хорошо!
PS: Я не спрашиваю только, в чем разница, но различия в том, как они запускают программное обеспечение.
4 ответа
Первоначально вы не могли позволить гостевой ОС использовать реальное оборудование, потому что у вас не было никакого способа его контролировать. Если вы попытались запустить его на реальном процессоре, у вас не было гарантии, что он будет передавать управление ОС хоста.
Виртуализация, как вы ее описываете, реализована в аппаратном обеспечении, позволяя применять определенные правила и ограничения на аппаратном уровне, которым может управлять ОС хоста. Это позволяет операционной системе хоста настраивать правила о том, что гость может и не может сделать, а затем фактически запустить гостя на реальном оборудовании. Если гость пытается что-то сделать с использованием реального оборудования, нарушающего правила (например, попытки доступа к дисководу), аппаратное обеспечение приостанавливает гостевую систему и отправляет хосту прерывание, которое позволяет хосту предоставлять ответ (например, возврат данных с эмулируемого дискового устройства), а затем возобновить гость.
Вот упрощенный пример процесса:
Хост-ОС: Привет, CPU, мне нужно, чтобы этот код был виртуализирован. Позвоните мне, если он хочет сделать что-то, что не просто выполняет инструкции.
ЦП хоста: Вы получили его!
Хост-процессор сохраняет все регистры и состояние хоста, а затем запускает исполняемый код гостевой ОС
Гостевая ОС: Я жив! Привет, CPU, можете ли вы получить мне этот файл?
Хост-ОС: О, дайте им следующее: Файл с виртуального жесткого диска
Главный процессор: Вы получили его!
Хост-процессор сохраняет все регистры и состояние хоста, восстанавливает гостевые регистры и состояние, а затем запускает исполняемый код гостевой ОС Главный процессор: Вот этот файл!
Гостевая ОС: Сладкая, спасибо!
Основное различие здесь в эмуляторе, гостевая ОС никогда не работает на аппаратном уровне. При виртуализации ОС хоста настраивает ограничения в ЦП, а затем фактически запускает гостевой код на физическом ЦП. Приведенный выше пример чрезвычайно упрощен, но память, дисковый ввод /вывод и даже сетевое взаимодействие можно контролировать на новейших современных процессорах, что позволяет им безопасно взаимодействовать без необходимости беспокоить хост-систему каждый раз. До тех пор, пока гость не пытается выйти за пределы виртуализованных границ, у хост-операционной системы может не работать какой-либо код, если он не имеет ничего общего в данный момент времени.
Чтобы добавить немного перспективы, это еще один шаг за долгую историю виртуализации и управления. (Нет гарантий, что это в правильном порядке или является исчерпывающим, но должно дать хороший обзор для начала)
Первоначально не было виртуализации. Процессы все разделяют одно и то же пространство памяти, все имеют полный доступ к оборудованию, а способность к многозадачности полностью зависит от одного процесса, останавливающего себя и дающего контроль над следующим процессом. Если ОС захотела иметь какой-либо контроль над процессом, имел для запуска процесса в эмуляторе (никто этого не делал, потому что он был слишком болезненно медленным).
Сначала была Привилегированная память : определенные действия, которые могут выполняться только специальными областями памяти. Эти регионы заняты ОС, что позволяет ей выступать в качестве шлюза для этих привилегированных действий. Примером может быть возможность чтения /записи данных на оборудование. Это препятствует процессам чтения /записи непосредственно на жестком диске, а вместо этого вынуждает их запрашивать ОС для чтения /записи для них. Это означает, что ОС может проверить, имеет ли процесс разрешение до выполнения действия.
Далее появилась виртуальная память : проблема с общей памятью заключается в том, что любой процесс может читать память любого другого процесса. Что происходит, когда программа Мэри читает пароль Боба из своего веб-браузера? Виртуальная память позволяет ОС отображать память, которую процесс видит в разных частях физической памяти, или даже полностью вывести их из физической памяти (в файл страницы). Каждый раз, когда процесс пытается прочитать или записать в память, VMMU (блок управления виртуальной памятью) процессора просматривает там, где он отображается в физической памяти, и выполняет там действие. Если он отображен не в памяти, тогда процессор вызывает ОС для извлечения страницы в память из файла страницы.
Как включить всю ОС для запуска в качестве процесса на виртуальной машине, но заставить ее работать независимо, все еще используя фактический процессор?
Используя тот же или похожий механизм, который ОС использует, чтобы поддерживать процессы пользовательского режима в строю, в основном.
Процессы пользовательского режима будут вызывать исключения ЦП, когда они пытаются сделать то, что им не разрешено делать.
Итак, если у нас есть ядро ОС в пользовательском режиме, в любое время он пытается сделать что-то вроде аппаратного обеспечения доступа напрямую, это вызовет исключение. Гипервизор может забрать это исключение и отвечать эмулированным или виртуализированным действием, а не вызывать сбои системы, как нормальное ядро.
Он может выполнять аппаратный доступ от имени этого ядра, выполнять модифицированный доступ к аппаратным средствам (то есть получить доступ к части файла вместо прямого доступа к диску) или что-то еще, о чем вы могли бы мечтать.
Расширения виртуальной машины CPU в основном расширяют весь «супервизор» или «защищенный» режим процессора на один уровень, чтобы сделать именно это, а также обеспечивают дополнительный «уровень вложенности» виртуальной памяти, поэтому подкачка проще виртуализировать.
В эмуляции виртуальная машина имитирует полное аппаратное обеспечение в программном обеспечении. Это позволяет запускать операционную систему для одной компьютерной архитектуры в архитектуре, на которой написан эмулятор. Sine все операции выполняются в программном обеспечении, эмуляция имеет тенденцию быть медленнее, однако может поддерживать больше платформ, поскольку она не зависит от оборудования.
Разница между эмуляцией и виртуализацией
Может кто-нибудь популярно объяснить разницу между виртуализацией и эмуляцией? Если qemu эмулятор, то почему VirtualBox нет?
его можно запустить на арме и получить x86 на выходе. и наоборот.
его можно запустить на арме и получить тот же арм на выходе.
Если qemu эмулятор, то почему VirtualBox нет?
VB не может эмулировать другую архитектуру процессора, если запускаешь на x86 в виртуалке без вариантов получаешь х86. Поэтому VB нет.
на x86 можно спокойно пускать x86_64
Виртуализатор исполняет код на том же процессоре, возможно, используя специальные режимы работы процессора. Ресурсы (память, диск и др.) предоставляет также напрямую или перехватывая обращения для подсовывания нужных данных. Иначе говоря, виртуализатор или совсем не эмулирует (имитирует) реальную машину, её архитектуру и процессор или делает это в минимальном варианте для отдельных ресурсов.
Соответственно, преимущества виртуализатора в скорости исполнения кода, программа в виртуалке без специальной поддержки будет работать медленнее всего на 30-50% При наличии поддержки виртуализации специальными командами процессора задержки могут быть совсем не большими по сравнению с нативным исполнением, разница в скорости может быть буквально несколько процентов.
Эмулятор даёт бОльшую гибкость, но сильно теряет в скорости. Обычно в 10-50 раз и более, если архитектура хост системы и эмулируемой сильно отличается.
Некоторые программы-эмуляторы могут иметь режимы работы как виртуализаторы
Нельзя давать определение через термины, которые сами требуют определения %)
Можно. Через себя нельзя.
в vbox`е на x86 хосте можно пускать x86_64 оффтопы
с ляликсом не прокатит
Все потому, что x86_64 это надстройка над x86.
Дадад. Сепульки 🙂 Рекурсия бывает и не вполне очевидной
на x86 можно спокойно пускать x86_64
Только если процессор поддерживает.
можно ссыль на кого-нибудь более многословного?
Речь о возможности установки 64-битного гостя на 32-битный хост при наличии в хосте 64-битного процессора
на x86 можно спокойно пускать x86_64
Как процессор будет исполнять код x86_64 будет если он в него не может? Речь напомню шла о VB.
при наличии в хосте 64-битного процессора
Речь о возможности установки 64-битного гостя на 32-битный хост при наличии в хосте 64-битного процессора
Если камень без VT-x или AMD-V, то 64-бинтую ОС нельзя запустить даже на 64-битном хосте.
Напоролся на это во времена Pentium D (9×5 не поддерживают, 9×0 — все нормально).
Только если есть аппаратная виртуализация.
Лучше конечно не эмулятор, а гипервизор(ы) разных родов.
Эмулятор даёт бОльшую гибкость, но сильно теряет в скорости. Обычно в 10-50 раз и более, если архитектура хост системы и эмулируемой сильно отличается.
Виртуализатор исполняет код на том же процессоре, возможно, используя специальные режимы работы процессора. Ресурсы (память, диск и др.) предоставляет также напрямую или перехватывая обращения для подсовывания нужных данных. Иначе говоря, виртуализатор или совсем не эмулирует (имитирует) реальную машину, её архитектуру и процессор или делает это в минимальном варианте для отдельных ресурсов.
Соответственно, преимущества виртуализатора в скорости исполнения кода, программа в виртуалке без специальной поддержки будет работать медленнее всего на 30-50% При наличии поддержки виртуализации специальными командами процессора задержки могут быть совсем не большими по сравнению с нативным исполнением, разница в скорости может быть буквально несколько процентов.
А паравиртуализатор использует ещё более специальные режимы работы процессора, а также использует ядро хостовой системы из-за чего скорость выполнения кода будет ещё больше, так?
И ещё вопрос, а какие системы виртуализации могут масштабировать вм между ядрами процессора, например одно ядро отдать одной вм полностью, а все остальные пусть использует хостовая система?
Некоторые программы-эмуляторы могут иметь режимы работы как виртуализаторы
В чем заключаются конкретные различия между собой «эмулятор» и «Мои виртуальную машину» и?
Я вижу, что это разные вещи, но я действительно могу’т сказать, почему. Некоторые люди говорят: «и эмуляторы для игры; виртуальные машины предназначены для операционных систем» Я не’т согласен с этим ответы, потому что есть эмуляторы для платформ, отличных от игровых видеоприставок (Амиги (?) )
Можете ли вы помочь мне, пожалуйста?
Виртуальных машин использовать самостоятельно виртуализации процессора, в том объеме, она существует, чтобы обеспечить виртуальных интерфейса на реальном оборудовании. Эмуляторы эмуляция оборудования, не полагаясь на ЦП способен выполнять код напрямую и перенаправить некоторые операции на гипервизор контролирует виртуальный контейнер.
Гипервизор можно сказать, чтобы «имитировать» и защищенный доступ; это не’т эмулировать процессор, хотя и было бы более правильно сказать, что он посредником защищенный доступ.
Защищенный доступ означает такие вещи, как создание таблицы страниц или чтение/запись портов ввода/вывода. Для первых, гипервизор проверяет (и, как правило, изменяется, чтобы соответствовать гипервизор’собственная память) работу таблица и выполняет сама инструкция защищена; операции ввода-вывода сопоставляется с эмулируемого устройства вместо эмулируемого процессора.
И просто усложнять вещи, вино тоже больше гипервизор, виртуальная машина (хотя и на более высоком уровне ABI), чем эмулятор (отсюда и»Wine-это не эмулятор и»).
Цель виртуальной машины для создания изолированной среды.
Цель эмулятора-это точно воспроизводить поведение некоторых аппаратных средств.
Оба нацелены на определенный уровень независимости от аппаратного обеспечения на хост-машине, а виртуальная машина, как правило, для моделирования достаточно оборудования, чтобы сделать оценки работы, и делать это с акцентом на эффективность эмуляции/виртуализации. В конечном счете, виртуальная машина может действовать как любое оборудование, которое реально существует, и может потребоваться ВМ-специальные драйверы, но набор драйверов оценки будут согласованы на большое количество виртуальных сред.
Эмулятор с другой стороны пытается точно воспроизвести все поведение, в том числе причуды и ошибки, некоторые аппаратные имитируется. Требуются водители гость будет точно соответствовать имитируемая среда.
Виртуализация, паравиртуализация и технология эмуляции, или некоторая комбинация может быть использована для реализации виртуальных машин. Эмуляторы, как правило, может’т использовать виртуализацию, потому что это сделает абстракции несколько дырявых.
Делл объяснил, в чем разница между эмуляторов и виртуальных машин.
эмуляции или виртуализации: какая разница?
эмуляции и виртуализации носит много сходств, но они есть > в различных эксплуатационных различиях. Если вы хотите получить доступ к старой операционной системы в новой архитектуре, эмуляция будет вашим предпочитаемый маршрут. Наоборот, виртуализированные действовать системы независимы базовое оборудование. Мы позаботимся о том, чтобы разделить эти часто путают термины и описать, что каждый из них означает для бизнеса ИТ-операций.
эмуляция, короче говоря, предполагает одну систему подражать другим. Для например, если программа работает на компьютере, а не на систему Б, мы делаем систему B “эмулировать” работу системы А. программное обеспечение работает на эмуляции системы А.
В этот же пример, виртуализации потребуется системе и разделив его на два сервера, B и C. оба этих “виртуальных” серверы независимые программные контейнеры, имеющие собственный доступ к программным ресурсам на основе процессора, оперативной памяти, систем хранения данных и сетей – и можно перезагружается самостоятельно. Они ведут себя в точности как реальные скобяными, > и приложение или другой компьютер не смог бы сказать разница.
У каждой из этих технологий есть свои применения, преимущества и недостатки.
В нашем примере эмуляции программного обеспечения заполняет оборудования – создание В среде, которая ведет себя в аппаратном режиме. Это сказывается на процессор за счет выделения циклов для процесса эмуляции – циклы, которые должны быть использованы на выполнение расчетов. Таким образом, большая часть мышц процессора расходуется в создании этой среды.
и GT; интересно, вы можете запустить виртуальный сервер в эмулируемой В среду. Так, если эмуляция-это такая трата ресурсов, поэтому рассмотреть его?
эмуляция может быть эффективно использована в следующих случаях:
• запуск программы, предназначенные для другой операционной системы (работает программное обеспечение для Mac на ПК и наоборот)
• запуск старых программ после сопоставимые оборудование устареет
эмуляция является также полезным при разработке программного обеспечения для различных систем. кодирование может быть сделано на одной машине, и приложение может быть работать в эмуляции нескольких операционных систем, все работает одновременно в их собственных окнах.
В нашем примере виртуализации, мы можем смело сказать, что он использует вычислительные ресурсы эффективно, функционально – независимых их физического местоположения или компоновки. Быстрая машина с достаточным количеством оперативной памяти > и достаточно места, можно разделить на несколько серверов, каждый с пул ресурсов. Что ни одной машины, часто развертывается как один сервер может затем разместить на своем веб-и почтового сервера. вычислительные ресурсы, которые ранее были недозагружены, теперь можно использовать > в полной мере. Это может существенно помочь сократить расходы.
В то время как эмулируется среда требует программного обеспечения моста для взаимодействия с оборудования, виртуализации обращается к оборудованию напрямую. Однако несмотря на то, что в целом более быстрый вариант, виртуализации ограничивается запуск программного обеспечения, которые уже способны работать на базовых оборудование. Ярчайший преимущества виртуализации включают в себя:
•широкая совместимость с существующими x86 процессора архитектуры
•способность появляться в физическом устройств все оборудование и программное обеспечение
•автономные в каждом случае