Виртуализация без гипервизора против гипервизора типа 2 - PullRequest
1 голос
/ 28 апреля 2011

Согласно помеченному ответу на stackoverflow.com здесь и другой ссылке здесь , я понимаю, что:

Виртуализация гипервизора = ниже операционной системы и аппаратная виртуализация, где оборудование предназначено для поддержки виртуализации

Виртуализация без гипервизора = поверх операционной системы (как прикладное программное обеспечение), то есть чисто программная виртуализация

Но у нас также есть классификации Type1 и Type2 для гипервизоров , и мне кажется, что Type2 является чисто программной виртуализацией ... поэтому это означает, что виртуализация без гипервизора эквивалентна гипервизору типа 2 Есть ли тонкие различия ??

Или это тот случай, когда все эти термины свободно определены ??

Заранее спасибо.

Ответы [ 4 ]

2 голосов
/ 01 июня 2013

мне кажется, что Type2 - это чисто программная виртуализация

Не путайте виртуализацию типа 1 с типом 2 и оборудования с программным обеспечением. На самом деле между аппаратным и программным обеспечением существует нечто среднее: есть полное аппаратное обеспечение (HVM), «частичное» аппаратное обеспечение (PVM) и чистое программное обеспечение (SW).

Попробую уточнить, расширив все 6 комбинаций:

Тип 1 + Полное оборудование (HVM) - Это позволяет гипервизору, например Xen HVM, загружать неизмененную гостевую ОС. Это на самом деле медленно, потому что гипервизор должен декодировать «телеграфные сообщения», которые гостевая ОС пытается отправить на оборудование. (т.е. запись на диск требует многократного сохранения байтов в ячейке 0xblahblah.)

Тип 1 + Паравиртуализация (PVM) - Это когда вы немного модифицируете гостевую ОС, чтобы вызвать гипервизор напрямую для некоторых задач, таких как дисковый ввод-вывод. Это быстрее, потому что гость просто говорит «здесь, напишите эту страницу байтов» и ему не нужно делать (виртуализированный) ввод-вывод для каждого байта. Вы знаете, что делаете PVM при установке специальных драйверов. Конечно, иногда в ОС уже встроены виртуальные драйверы. Например, любое современное ядро ​​Linux при загрузке автоматически переключится в режим PVM, когда обнаружит, что оно работает под Xen, KVM, UML и т. Д.

Type 1 + Pure Software (SW) - Я не уверен, существует ли он, но его будет не так сложно построить. Поскольку программная эмуляция медленная, накладные расходы на загрузку реальной ОС и запуск Type 2 не имеют большого значения.

Тип 2 + Полное оборудование (HVM) - Это позволяет загружать немодифицированную Windows под VirtualBox или KVM. Вы знаете, что это тип 2, когда вы можете перезагрузить всех ваших гостей и по-прежнему воспроизводить MP3 в фоновом режиме:)

Тип 2 + Паравиртуализация (PVM) - Это происходит каждый раз, когда вы устанавливаете гостевые драйверы или загружаете современное ядро ​​Linux под VirtualBox / KVM.

Type 2 + Pure Software (SW) - ранние версии Bochs и Qemu. (В последних версиях также есть режимы с аппаратной поддержкой.) Вы можете сказать, что они являются «чистым программным обеспечением», потому что они позволяют запускать программное обеспечение, которое вы обычно не можете запустить без него. (т.е. я запускаю Windows '95 под Bochs на процессоре ARM и загружаю дистрибутив ARM на x86 под Qemu.)

Существует также другая тема, которая отличается от описанной выше:

Контейнерная техника . Контейнеры типа Docker / Rkt / LXD не помещаются в приведенную выше таблицу. Приложения в контейнерах - это обычные программы, вызывающие ядро ​​обычными способами, без участия гипервизора.

Просто контейнеры используют функции ядра в cgroups и пространствах имен, чтобы приложение "чувствовало", что оно находится в виртуальной машине. Каждый контейнер получает «разделенное» представление системы: это собственная файловая система, свои собственные идентификаторы пользователей, свои собственные идентификаторы процессов, свое собственное имя хоста + IP-адрес и т. Д. Но снаружи вы можете видеть все процессы во всех контейнерах с помощью ' пс.

2 голосов
/ 28 апреля 2011

На мой взгляд, виртуализация без гипервизора - это уровень виртуализации, на котором выполняется нечто ДРУГОЕ, чем ОС, - чаще всего это виртуализация среды уровня пользователя какой-либо другой операторской системы. Например, проект WINE - это виртуализация без гипервизора - он позволяет запускать программы win32 на хосте linux (или другом). Там нет попытки запустить реальную ОС Windows или эмулировать «голое» оборудование для виртуализированной ОС. Вместо этого виртуальный уровень предоставляет абстракции пользовательского уровня и системные вызовы для окон напрямую.

Сравните это с гипервизором, который может быть либо типа 1 (работающего на голом железе), либо типа 2 (работающего на ОС), который предоставляет абстракции аппаратного уровня и над которым вы запускаете целую ОС.

1 голос
/ 29 апреля 2011

Гипервизор по определению эмулирует аппаратное обеспечение. (Это может или не может существовать физически) - оно может виртуализировать также некоторых.

Виртуализация перехватывает вызов и перенаправляет его в другое место.

Это две разные, но взаимосвязанные темы.

Гипервизоры типа 1 работают на «голом железе» и находятся между оборудованием и вашими виртуальными операционными системами (сам гипервизор является операционной системой). Например, VMWare ESX , Citrix XenServer или Microsoft Hyper-V

Гипервизоры типа 2 работают поверх существующей операционной системы и могут поддерживать аппаратную или программную виртуализацию. Например, QEmu и Bochs ) эмулируют весь ЦП, опционально даже другую архитектуру ЦП. Оба являются гипервизорами типа 2, но имеют значительные потери производительности из-за необходимой эмуляции.

Рабочая станция VMware / Сервер / Плеер / Fusion , Parallels , Virtualbox все являются примерами гипервизоров типа 2, которые поддерживают Аппаратная виртуализация - это означает, что вместо эмуляции инструкций ЦП инструкции ЦП могут проходить напрямую без эмуляции или трансляции - эффективно работает без потери производительности, если процессор его поддерживает.

Далее, виртуализация без гипервизора , которая (эффективно) - виртуализация приложений. Само оборудование никак не эмулируется, уровень виртуализации просто перехватывает определенные системные вызовы и виртуализирует их. Примеры в этой категории включают VMWare Thinapp , Microsoft App-V и многие другие. Сама Windows Vista виртуализирует определенные записи реестра и диска в области, где у пользователя нет прав на запись. Эта виртуализация в Vista имеет решающее значение для обратной совместимости со многими устаревшими приложениями.

Наконец-то у нас есть чистые эмуляторы - здесь не происходит виртуализация. В этой категории у нас есть WINE и в некоторой степени Cygwin . Также Bochs подпадает под эту категорию, также как и гипервизор типа 2, так как здесь нет виртуализации, только аппаратная эмуляция. DOSEMU - еще один пример, который здесь подходит.

Я уверен, что пропустил множество примеров, но

0 голосов
/ 15 ноября 2014

(я опубликую свой комментарий к # answer-16868851 здесь, так как мне не хватает нескольких баллов, чтобы выполнить"У вас должно быть 50 репутаций, чтобы комментировать" требование)

BraveNewCurrency пишет:

Type 1 + Pure Software (SW) - я не уверен, существует ли это, но не будетэто сложно построить.Поскольку программная эмуляция медленная, накладные расходы на загрузку реальной ОС и запуск Type 2 не представляют большой проблемы.

Пока что я нашел только один Type 1 гипервизорспособен сделать это - это VMware ESXi .

vSphere 5 Центр документации | Требования к оборудованию ESXi скажем:

■ Для поддержки 64-разрядных виртуальных машин должна быть включена поддержка аппаратной виртуализации (Intel VT-x или AMD RVI) на процессорах x64.

Следовательно, 32-битные гости работают без VT-x в нем.

Поскольку я вижу нулевую конкуренцию за него (как проприетарную, так и с открытым исходным кодом), я предполагаю прерывание чувствительных инструкций процессора безПоддержка VT-x (то есть в Pure Software ) является серьезной проблемой на практике.

Хотя следующее уже не относится к исходному вопросу, v5.0 (и v4.x) требует 64-битной поддержки от ЦП, хотя:

■ ESXi 5.0 будет устанавливать и запускать толькона серверах с 64-разрядными процессорами x86.

■ Для ESXi 5.0 требуется хост-компьютер с как минимум двумя ядрами.

Те, кто заинтересован в работе Тип 1 + SW гипервизор на 32-битных машинах (как и я) может использовать более ранние версии. Минимальные системные требования для установки ESXi / ESX (1003661) говорит:

ESX 3.5.x

Требования к оборудованию для ESX 3.5.x те же, что перечислены в разделе ESX 3.0.x, со следующими дополнениями:

[...]

ESX 3.0.x

Вам необходимы эти аппаратные и системные ресурсы для установки и использования ESX 3:

At least two processors:
    1500 MHz Intel Xeon and above, or AMD Opteron (32bit mode) for ESX
    1500 MHz Intel Xeon and above, or AMD Opteron (32bit mode) for Virtual SMP
    1500 MHz Intel Viiv or AMD A64 x2 dual-core processors

+ Руководство по установке ESX 3.5 повторяет это в следующем разделе / ​​подразделе:

Требования ESX Server 3

В этом разделе рассматриваются минимальная и максимальная конфигурации оборудования, поддерживаемые ESX Server 3 версии 3.5.

Минимальные требования к оборудованию сервера

...

Следовательно, Чистое (и только 32-битное) программное обеспечение :)

...