Вопрос или проблема
Я пытаюсь запустить узел вычислений OpenStack Nova в контейнере, чтобы загрузить сервер в вложенном контейнере.
Все работает хорошо, пока я не попрошу Nova в контроллере загрузить сервер. В процессе загрузки сервера в контейнере вычислений libvirt использует qemu-nbd для экспорта образа диска qcow2, загруженного из OpenStack Glance, в качестве предыдущего шага перед запуском вложенного контейнера. С конфигурацией lxc по умолчанию qemu-nbd не работает.
Я разобрался с файлом lxc.conf, чтобы разрешить использование qemu-nbd изнутри контейнера, но, похоже, я что-то упускаю, потому что даже если контейнер активирует узел /dev/nbd0, я не вижу записи /dev/nbd0p1, соответствующей разделу в образе диска qcow2.
Вот файл lxc.conf для моего контейнера Nova:
# Шаблон, используемый для создания этого контейнера: /usr/share/lxc/templates/lxc-download
# Параметры, переданные шаблону: -d ubuntu -r trusty -a i386
# Для дополнительных параметров конфигурации смотрите lxc.container.conf(5)
# Конфигурация дистрибутива
lxc.include = /usr/share/lxc/config/ubuntu.common.conf
lxc.arch = x86
# Конкретная конфигурация контейнера
lxc.rootfs = /var/lib/lxc/compute/rootfs
lxc.utsname = compute
# Сетевая конфигурация
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.hwaddr = 00:16:3e:90:16:e0
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0.1000
lxc.network.hwaddr = 00:16:3e:90:16:e1
# Это общий интерфейс
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0.2000
lxc.network.hwaddr = 00:16:3e:90:16:e2
# Добавлено, чтобы некоторые функции (iptables, nova-compute и т.д.) работали
lxc.mount.entry = /lib/modules/3.13.0-43-generic /var/lib/lxc/compute/rootfs/lib/modules/3.13.0-43-generic none ro,bind 0 0
# Добавлено, чтобы узел вычислений мог запускать LXC ВМ
lxc.mount.auto = cgroup
lxc.aa_profile = lxc-container-default-with-nesting
# Разрешить контейнеру выполнять mknod (нужно для qemu-nbd...)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
# Разрешить контейнеру использовать устройства nbd хоста
lxc.cgroup.devices.allow = b 43:* rwm # Каждое устройство nbd на хосте
Это можно легко проверить в командной строке. Предполагая, что у нас есть образ диска qcow в /root/cirros-0.3.3-i386-disk.img:
root@compute:~# qemu-nbd -c /dev/nbd0 cirros-0.3.3-i386-disk.img -f qcow2
root@compute:~# ls -d /sys/class/block/nbd0p1
/sys/class/block/nbd0 /sys/class/block/ndb0p1
root@compute:~# ls /dev/nbd0*
/dev/nbd0
Похоже, что блочное устройство существует в ядре, но узел устройства /dev/nbd0p1 не был создан. Кто-нибудь знает, что я упускаю в своей конфигурации контейнера?
П.С. Я знаю, что OpenStack Nova по умолчанию не работает с контейнерными ВМ, потребуется внести некоторые изменения в код Nova; но мне нужно преодолеть это препятствие сначала
Похоже, это работает для меня (загрузка экземпляра LXC, используя образ qcow2 cirros внутри хоста LXC внутри гостя KVM на уровне хоста KVM; релиз Icehouse).
Пришлось вручную создать несколько узлов nbd:
stack@ctl-template:~/devstack$ ls -l /dev/nbd*
brw-r--r-- 1 root root 43, 0 Apr 13 14:31 /dev/nbd0
brw-r--r-- 1 root root 43, 16 Apr 13 14:33 /dev/nbd1
brw-r--r-- 1 root root 43, 32 Apr 13 14:33 /dev/nbd2
brw-r--r-- 1 root root 43, 48 Apr 13 14:33 /dev/nbd3
brw-r--r-- 1 root root 43, 64 Apr 13 14:34 /dev/nbd4
nbd1 используется экземпляром:
stack@ctl-template:~/devstack$ dmesg | tail | grep nbd
[94516.110986] EXT4-fs (nbd1): монтирование файловой системы ext3 с использованием подсистемы ext4
[94516.205551] EXT4-fs (nbd1): смонтирована файловая система в режиме упорядоченных данных. Опции:
дополнительные устройства не созданы для разделов внутри образа:
stack@ctl-template:~/devstack$ ls /sys/class/block/
loop0 loop4 nbd0 nbd12 nbd2 nbd6 ram0 ram12 ram2 ram6 sr0 vda5
loop1 loop5 nbd1 nbd13 nbd3 nbd7 ram1 ram13 ram3 ram7 vda
loop2 loop6 nbd10 nbd14 nbd4 nbd8 ram10 ram14 ram4 ram8 vda1
loop3 loop7 nbd11 nbd15 nbd5 nbd9 ram11 ram15 ram5 ram9 vda2
Ответ или решение
Проблема монтирования qcow2 образа с использованием qemu-nbd в контейнере
Ваша задача заключается в настройке OpenStack Nova Compute Node для загрузки сервера в вложенном контейнере, что требует использования qemu-nbd для экспорта qcow2 образа. Рассмотрев вашу конфигурацию lxc и возникшую проблему с отсутствием устройства /dev/nbd0p1, давайте рассмотрим возможные решения и детали настройки.
Причины проблемы и их решение
-
Создание устройств NBD:
Убедитесь, что устройства NBD активны и созданы корректно на хосте. Проверить это можно с помощью команды:ls -l /dev/nbd*Если нужные устройства (например,
/dev/nbd0,/dev/nbd1и т.д.) отсутствуют, их можно создать вручную с помощью:sudo modprobe nbd max_part=8 -
Настройка доступа к устройствам NBD:
Убедитесь, что в вашем конфигурационном файлеlxc.confразрешён доступ к устройствам NBD:lxc.cgroup.devices.allow = b 43:* rwmЭто позволит контейнеру
Novaиспользовать устройства NBD. -
Использование
qemu-nbd:
Когда вы запускаете команду для подключения образа qcow2 к/dev/nbd0, убедитесь, что используете правильный формат и синтаксис. Команда должна выглядеть следующим образом:qemu-nbd -c /dev/nbd0 /root/cirros-0.3.3-i386-disk.imgПосле выполнения данной команды вы должны увидеть устройство
/dev/nbd0p1. -
Проблемы с созданием разделов:
Если устройство/dev/nbd0p1не создаётся при подключении, это может быть связано с отсутствием разбивки на разделы в образе. Вы можете проверить это с помощью команды:fdisk -l /root/cirros-0.3.3-i386-disk.imgЕсли раскладка разделов верна, а устройство не появляется, попробуйте использовать
kpartxдля создания разделов:kpartx -a /dev/nbd0Это создаст устройства
/dev/mapper/nbd0p1, которые можно использовать в системе. -
Перезапуск сервиса libvirt:
Иногда после изменения конфигурации может потребоваться перезапуск сервисаlibvirtвнутри контейнера, чтобы изменения вступили в силу:systemctl restart libvirtd
Заключение
Монтирование qcow2 образа с использованием qemu-nbd требует корректной настройки и доступа к устройствам на вашей системе. Следуя данным рекомендациям, вы сможете устранить возникшие проблемы и успешно запустить сервер в вашем окружении OpenStack. Если после применения всех этих изменений проблема остаётся, возможно, потребуется более глубокий анализ конфигурации сети или доступов на уровне системы.
Эта задача демонстрирует важность правильного управления контейнерами и настройкой виртуализации в рамках OpenStack, а также необходимость понимания и контроля за устройствами и ресурсами, необходимыми для корректного функционирования облачной инфраструктуры.