Организация инфраструктуры виртуальных машин на базе libvirt

Материал из DvoWiki
Перейти к: навигация, поиск

Кратко о причинах использования виртуализации.

Подавляющее большинство маркетинговой информации о современных серверных платформах содержит в себе кричащие фразы о поддержке виртуализации. И вот, вы стали счастливым обладателем красивого ящика и перед вами встаёт вопрос целесообразности использования данной функции для вашего небольшого учреждения. Естественно, здесь не будет идти речи об организации кластерной облачной платформы, ибо масштабы не те, да и финансы не позволяют. Но, с другой стороны, даже если не замахиваться на столь обширные цели, свой выигрыш от виртуализации мы с вами можем получить. Здесь я представлю несколько доводов в пользу данной технологии.

  1. Утилизация ресурсов. Как правило, небольшая контора имеет не очень большой набор сервисов, обычно это сводится к Веб хостингу,

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

  1. Разделение сервисов из соображений безопасности. Допустим другую ситуацию, все ваши службы расположены на одной машине.

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

  1. Лёгкость обновления. В случае если вам необходимо обновить и оттестировать программное обеспечение на вашем сервере вы просто создаёте клон виртуальной машины,

делаете необходимые операции, синхронизируете данные, останавливайте старую копию, и вот у вас обновлённая система.

Системные требования

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

В качестве хостовой OC будем использовать Gentoo Linux. Для ленивых есть альтернативная замена в лице Calculate, которая является по сути своей stage-3 той же самой Gentoo. Гипервизором будет служить [KVM (for Kernel-based Virtual Machine)]. Для его активации нам потребуются ядерные модули kvm_intel, либо kvm_amd, для процессоров Intel или AMD соответственно. Для начала проверим, может быть он уже запущен:

$lsmod
kvm_intel              40269  0 

Если вы не видите чего-то подобного то, милости просим в

cd /usr/src/linux
make menuconfig

И далее проверяем, что нужный нам модуль модуль скомпилирован:

KernelScreenshot KVM.png

Для работы сети на понадобится также поддержка TUN/TAP интерфейса и Bridging, поэтому проверим в конфигурации ядра включёны ли они

(Drivers->Network device support)

KernelScreenshot TUN TAP.png

(Networking support->Networking options)

KernelScreenshot Bridging.png

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

make && make install && make modules install

Если директория boot находится на отдельном разделе, то перед началом компиляции необходимо подключить её следующей командой.

mount /boot

Необходимо убедится что необходимый нам модуль kvm_intel/kvm_amd загружается. Для этого необходимый нам модуль нужно прописать в /etc/conf.d/modules.

cat /etc/conf.d/modules
modules_2_6="kvm-intel"

Теперь можно приступать к непосредственной установке libvirt и вспомогательных программ.

Установка libvirt и окружения

Так как основной работой по управлению нашим парком виртуальных машин будет заниматься libvirt, то, для начала установим её.

emerge app-emulation/libvirt

После этого у нас есть два варианта, либо мы можем управлять всем из командной строки, либо воспользуемся графическими утилитами. Первые устанавливаются вместе с libvirt, и если вам для счастья ничего больше не надо, то можете смело приступать к работе. В качестве графического фронтенда будем использовать virt-manager, который также поддерживается RedHat и поэтому обладает пожалуй самой полной совместимостью с libvirt. Напомню лишь то, что virt-manager мы устанавливаем на клиентской машине, то есть компьютере, с которого вы будите управлять вашим парком VM.

emerge app-emulation/virt-manager

Настройка libvirt

Общие приготовления

По умолчанию в нашем gentoo окружении все настройки libvirt будут храниться в директории /etc/libvirt/.

Важно не забыть запустить сервер в режиме общения с внешним миром, для этого необходимо прописать параметр запуска listen в /etc/conf.d/libvirtd.

cat /etc/conf.d/libvirtd 
LIBVIRTD_OPTS="--listen"

Основные настройки libvirt находятся в директории /etc/libvirt/. Настройку системы мы начнём с выбора модели аутентификации к управляющему демону libvirt. В данной статье рассматривется аутентификация при помощи сертификатов. Это означает что на каждую клиентскую машину помещён сертификат, служащий для аутентификации этой машины. При использовании данного метода нам не требуется вводить пароль при каждом подключении, также такой вид аутентификации является криптографически стойким. Для данного вида аутентификации нам понадобятся сертификаты для серверной части и клиентские сертификаты. В нашей ситуации нет необходимости заказывать их из какого-нибудь центра сертификации, можно использовать просто самоподписанные.

Допустим у вас ещё нет своего CA (Certificate authority). Далее будут приведены команды которые вам будет необходимо запустить для генерации сертификатов и CA.

emerge dev-libs/openssl
cd /etc/ssl/misc
./CA.sh -newca
./CA.sh -newreq-nodes

Данные команды создадут нам CA, расположенный в папке demoCA, а также один запрос на создание сертификата, не защищённого паролем. Можно конечно создать и защищённый пролем, но тогда при каждом перезапуске системы, придётся вбивать пароль. Предполагается что этот сертификат будет нашим серверным сертификатом. Подпишем его нашим CA командой

./CA.sh -sign

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

mkdir /etc/ssl/libvirt
mv newcert.pem /etc/ssl/libvirt/server-cert.pem
mv newkey.pem /etc/ssl/libvirt/server-key.pem

Для удобства (да и для того чтобы это заработало) нужно скопировать в эту директорию ваш CA.

cp ./demoCA/cacert.pem /etc/ssl/libvirt/ca-cert.pem

Важно!!! Сохраните сертификаты именно под указанными в примере именами. Это условие связано с тем, что qemu будет искать файлы именно с этими именами, и в настройках я не нашёл способа поменять это поведение.

Libvirt демон

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

listen_tls = 1 #слушаем tls порт, все коммуникации будут проходить по защищённому каналу. 
tls_port = "16514"
listen_addr = "94.198.16.4" #адрес на который буде прослушивать демон
mdns_name = "your great virtual controller"
# Аутентификация уже происходит по сертификатам, поэтому мы не пишем в соответствующей секции файла
# TLS sockets already have encryption provided by the TLS
# layer, and limited authentication is done by certificates
# Пропишем пути до сертификатов
key_file = "/etc/ssl/libvirt/server-cert.pem"
cert_file = "/etc/ssl/libvirt/server-key.pem"
ca_file = "/etc/ssl/libvirt/ca-cert.pem"
#!!!Теперь важная часть в усилении вашейц безопастности, контроль отпечатков сертификатов пользователей
# которым разрешено подключаться в управляющему демону
tls_allowed_dn_list = ["C=RU,ST=SomeDistrict,L=Kukuevka,O=Govnozavod,OU=Govnoceh,CN=client.machine.name,EMAIL=your@email.ru"]
max_clients = 5

Qemu

После того как мы настроили libvirt демон, можно приступать к настройкам, специфичным для конкретных видов виртуальных машин. Так как предметом нашего разговора явлется Qemu, то описывается настрока именно этого гиперфизора. Настроки qemu хранятся в файле /etc/libvirt/qemu.conf.

vnc_listen = "94.198.16.4"
vnc_tls = 1
vnc_tls_x509_cert_dir = "/etc/ssl/libvirt"
vnc_tls_x509_verify = 1

Здесь прописаны настройки vnc соединения к гиперфизору, собственно ими можно и ограничиться.

Virt-Manager

В этом пункте мы рассмотрим настройки клиентской части, используемой для создания ,клонирования и контроля над виртуальными машинами. В качестве управляющей консоли мы будем использовать virt-manager.

emerge virt-manager.

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

./CA.sh -newreq-nodes
./CA.sh -sign

После создания сертификатов советую дать им имя машины на которую они будут устанавливаться и скапировать в какое-нибудь безопасное место в качестве бэкапа. После этого скопируте сертификаты и CA на клиентскую машину. В виду истоков из недр компании RedHat, пути для поиска сертификатов по умалчанию у virt-manager находятся в директории /etc/pki. Способа как-то изменить это не влезая в код я не нашёл, так что нам придётся создать всё вручную.

mkdir /etc/pki
mkdir /etc/pki/CA
mkdirhier /etc/pki/libvirt/private

Теперь наполним эти директории файлами

/etc/pki/CA/cacert.pem
/etc/pki/libvirt/clientcert.pem 
/etc/pki/libvirt/private/clientkey.pem

Имена файлов должны быть представленны именно такими, какими они представленны здесь. После присваемаем этим файлам права на запуск.

chmod a+x /etc/pki/CA/cacert.pem
chmod a+x /etc/pki/libvirt/clientcert.pem 
chmod a+x /etc/pki/libvirt/private/clientkey.pem

После этого можно запускать virt-manager и создавать ваши виртуальные машины.

Дополнительные программы

Ещё одна полезная штука для доступа к VNC дисплею виртуальной машины это virt-viewer. Вот пример доступа к удалённой виртуальной машине с помощью этой команды.

virt-viewer -c qemu+tls://your.server.ru/system YourVMName

Добавление серийной консоли для доступа к виртуальной машине

На хосте проверяем настройки запуска виртуальной машины

/etc/libvirt/qemu/some.xml

Должно содержать следующую запись

<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>

На гостевой системе

В файле

/boot/grub2/grub.cfg

Редирект загрузки (добавляем до строчек menuentry)

serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1

К параметрам запуска ядра

console=tty0 console=ttyS0,115200n8 earlyprint=serial,ttyS0,115200

В файле

/etc/inittab

добавляем запись

1:23:respawn:/sbin/agetty -h -L ttyS0 115200 vt100

После перезапуска гостя

На хостовой машине

virsh console gentoo-amd64-squid

Либо

virsh ttyconsole gentoo-amd64-squid

Должно показать что то типа /dev/pts/1

minicom -D /dev/pts/1

Эксплуатационные проблемы и их решения

Гости не запускаются запуститься при перезагрузке

Был обнаружен неприятный момент в работе. Гостевые системы в некоторых случаях не загружаются после перезагрузки машины хозяина. Та же проблема может наблюдаться и при простой перезагрузке демона libvirt. В замеченных случаях проблема состояла в том, что libvirt пытался загрузить сохранённые состояния гостевых систем из директории

/var/lib/libvirt/qemu/save/

При удалении файлов из этой шла загрузка системы в нормальном порядке.

Сертификаты созданные openssl не принимаются libvirt

У libvirt-1.0.3-r1 была обнаружена следующая проблема: при создание самоподписанного сертификаты при помощи openssl, libvirtd отказывается его принимать. В этом случае можно воспользоваться gnutls. Авторы libvirt его и рекомендуют использовать при генерации сертификатов. Ссылка [1].

Запуск QEMU c процессором как у хостовой машины.

При запуски qemu версии 1.4.0 была обнаружена следующая проблема - невозможность создать виртуальную машину с процессором как у хостовой машины. Для решения это проблемы нужно проверить скрипт

/usr/bin/qemu-kvm

И добавить к параметрам запуска qemu -

-enable-kvm -cpu host

Полезные ссылки

Официальный сайт libvirt

Хорошая статья по управлению libvirt из командной строки