§ KVM: Nested Virtualization

KVM Nested Virtualization: we need to go deeper

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

Пытливые умы инженеров создавших виртуализацию, не остановились на достигнутом. Фантазия пошла еще дальше и кто-то однажды сказал (или подумал), а что если мы запустим гипервизор на гипервизоре? И ведь в конечном счете запустили. То что получилось, назвали вложенной виртуализацией (Nested Virtualization). Лично мне на ум приходит фильм Inception, где герой ДиКаприо произносит что-то вроде "We need to go deeper". 

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

Реализация вложенной виртуализации выполнена во многих продуктах, здесь я буду рассматривать KVM. Итак в случае с KVM, вложенная виртуализация реализуется модулем ядра. В зависимости от используемого процессора это может быть модуль kvm_intel или kvm_amd. По умолчанию может быть так, что вложенная виртуализация выключена, проверить это можно с помощью следующей команды:

# cat /sys/module/kvm_intel/parameters/nested 
N

Буква N или 0 обозначает что вложенная виртуализация выключена. Чтобы ее включить нужно выгрузить модуль и загрузить его с параметром kvm_intel.nested=1

Если же KVM монолитно собран внутри ядра, нужно выполнить перезагрузку и ядру передать этот параметр. Делается это с помощью правки конфигурации загрузчика.

Итак выгружаем модуль и загружаем с нужным параметром.
# rmmod kvm_intel
# modprobe kvm_intel nested=1
# at /sys/module/kvm_intel/parameters/nested 
Y
При постоянном использовании рекомендуется добавить этот параметр в автозагрузку. 

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

Для управления эмуляцией виртуальных процессоров в qemu есть параметр -cpu который позволяет определять тип процессора внутри виртуальной машины. Как известно поддержка виртуализации определяется по наличию флагов vmx для Intel и svm для AMD. Соответственно возможность использования этих расширений нужно передать в наши виртуальные машины. Для этого запускаем виртуальные машины с таким набором опций:

# qemu-kvm -cpu host ...
или
# qemu-kvm -cpu qemu64,+vmx ...

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

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

Кто-то спросит, а как там обстоят дела с производительностью. А я отвечу - производительность страдает. Вложенная виртуализация дает заметное снижение производительности. Поэтому использовать вложенную виртуализацию рекомендуется только в экспериментальных стендах.

На главную "Virtualizing Linux"