Эта статья должна предоставить много информации в соответствии с тем, что вы ищете. Тем не менее, это специфично для VMware.
Общий случай заключается в том, что это действительно зависит от ряда вещей:
- VT-x / AMD-V используется?
- EPT используется?
- VT-d или какой-то тип IOV используется?
Вышеуказанные вопросы являются вопросами использования аппаратных инструкций . В зависимости от того, какие аппаратные инструкции для процессоров AMD/Intel используются для поддержки виртуализации, структура гипервизора обычно немного отличается. Если никакие аппаратные инструкции не используются, то говорят, что виртуальная машина "полностью эмулирована" или "работает в программном обеспечении", что часто является самым медленным режимом. Однако даже без аппаратной поддержки паравиртуализация (когда гостевая ОС знает, что она работает в виртуальной машине) может значительно ускорить даже уровень программной эмуляции, предоставляя четкий программный интерфейс между гостем и хостом.
Некоторые виртуальные машины, такие как qemu без kqemu или kvm, могут работать полностью в кольце 3, но это имеет несколько ограничений, таких как производительность и отсутствие низкоуровневого доступа к оборудованию. В общем, даже те гипервизоры без какого-либо аппаратного ускорения вообще традиционно работают в кольце 0, т. Е. В ядре хоста в качестве драйвера.
Использование колец 1 и 2 довольно редко, но это происходит, как отмечено в статье Anandtech. Кроме того, кольца 1 и 2 обычно используются для гипервизоров из чистого металла, таких как Xen. Насколько мне известно, ядро операционной системы "dom0" в Xen полностью работает в кольце 1, и только "микроядро" Xen работает в кольце 0. Таким образом, если бы Linux был dom0, то он работал бы в кольце 1, а гостевые (domU) ядра были бы проконтролированы Xen в кольце 0 и работали в кольце 2.
Конечно, "кольца" процессора - не единственный механизм безопасности или изоляции, и инструкции по аппаратному обеспечению обеспечивают большую поддержку для безопасного разделения виртуальных машин без необходимости делать все в программном обеспечении. Подробности, если вы хотите их получить, лучше всего получить, прочитав руководство по программированию процессора Intel, в частности, по теме VT-x.
Вложенная виртуализация, как правило, невозможна, за исключением случая VMware (это единственный гипервизор, о котором я знаю, который может это сделать). Это достигается путем эмуляции инструкций VT-x (и, возможно, EPT) в гостевой системе, что заставляет гостя думать, что у него есть реальная поддержка VT-x/EPT. Вероятно, это хитрость гипервизора, хотя я не знаю деталей реализации. EPT, однако, часто называют "вложенными таблицами страниц", поэтому мне интересно, подразумевает ли "вложенный" аспект, что вы можете создавать дополнительные уровни вложенности, чем один уровень глубже, который требуется для отделения таблиц страниц хоста от гостевой (ы).
Гораздо более распространенным явлением для вложенной виртуализации является то, что вы застряли в режиме "полностью эмулируемого" или, в лучшем случае, паравиртуализированного, что приводит к значительному снижению производительности.
И если говорить о производительности, я не думаю, что очень многие люди вообще используют вложенную виртуализацию, если они могут ее избежать, за исключением, может быть, виртуализации вложенных контейнеров (которая не требует никаких затрат процессора / памяти / оборудования). Влияние на производительность, даже при использовании виртуализированного VT-x VMware, настолько велико, что любые потенциальные преимущества изоляции будут уничтожены. Поверьте мне, одного уровня виртуализации достаточно до тех пор, пока / пока мы не доберемся до аппаратного узла, где на самом деле целесообразно более глубоко вкладывать и уметь воздействовать на производительность уровней косвенности.
