LXD: Выполнение изображения с внешней архитектурой
Я хочу использовать LXD для начальной загрузки корневой файловой системы для развертывания во встроенной системе ARM от моего хоста AMD64 рабочая человечность 16.04. Ранее, я сделал это со сценарием и chroot команда, но сценарий, который я использовал, была подвержена ошибкам и имела дурную привычку к удалению моих/dev записей.
Я смог скопировать изображение локально с помощью lxc image copy images:ubuntu/16.04/arm64 --alias=ubuntu-server-arm64, и установили qemu-user-static, но не могут на самом деле запустить контейнер из этого изображения. Я получаю следующую ошибку:
$ lxc launch ubuntu-server-arm64 bootstrap
Creating bootstrap
error: Requested architecture isn't supported by this host
Есть ли способ вынудить lxd проигнорировать несоответствие архитектуры и использование qemu-user-static выполнять дочерний контейнер?
2 ответа
По словам Stephane Graber, который отвечает за проект LXC/LXD (в ответ на запрос от меня на их сайте обсуждений):
qemu-user-static является binfmt помощником, который позволяет Вам сделать динамическое преобразование между архитектурой. Это эффективно позволяет Вам выполнить двоичные файлы для архитектуры кроме Вашей текущей.
qemu-user-static самостоятельно должен хорошо работать в контейнере и позволит Вам выполнить некоторые двоичные файлы внешней архитектуры в нем.
Попытка выполнить весь контейнер через qemu-user-static очень непрактична из-за некоторых больших ограничений qemu-user-static, например, что-либо, что полагается на ptrace (init системы и средства отладки), netlink (все сетевые инструменты и некоторые init системы), или поток (намного больше программного обеспечения) будет обычно терпеть полный провал.
Подход, который я реализовал назад в LXC, должен был создать смешанный контейнер, где большинство пакетов имело внешнюю архитектуру, но init система, сетевые инструменты, … имели собственную архитектуру. Это было своего рода работавшим, но также и не особенно полезное, не говоря уже об очень медленном.
Поскольку это эффективно неприемлемо, что касается нас, мы не предоставляем изображений внешней архитектуры для LXD. Вы могли однако создать свое собственное путем сборки rootfs внешней архитектуры, затем включая необходимые qemu-user-static двоичные файлы, замены любого двоичного файла, который не будет работать с эмуляцией и генерировать это как изображение LXD (отмечающий его с архитектурой, на которой это предназначается для работы, а не архитектура, которую это содержит).
Так, эффективно, попытка выполнить внешнюю архитектуру на LXD не поддерживается, и метод LXC был более или менее типом 'комбинированной среды' взлома.
Это кажется, что могло также быть сделано, но потребует, чтобы Вы создали rootfs внешней архитектуры и в основном создали 'изображение' сами, которое выполняет все это, которое по различным причинам могло быть головной болью и большой работой для выполнения.
Мне удалось заставить стороннюю архитектуру работать с LXD. Я взял образ ARMv7, создал из него squashfs, добавил qemu-arm-static в /usr/bin. Трюк, чтобы заставить его работать с LXD, заключался в том, чтобы в tar-архиве метаданных было указано, что образ x86_64 (или любая другая архитектура вашего хоста). Импорт и запуск этого образа работают, LXD считает, что это поддерживаемая архитектура (соответствует хосту) и что он может работать из-за qemu-arm-static и binfmt.
ALPINE_MIRROR_URL="http://ams.edge.kernel.org/alpine"
ALPINE_VERSION="3.11.5"
ALPINE_ARCH="armhf"
version=$(echo $ALPINE_VERSION | cut -d '.' -f 1-2)
curl -O ${ALPINE_MIRROR_URL}/v${version}/releases/${ALPINE_ARCH}/alpine-minirootfs-${ALPINE_VERSION}-${ALPINE_ARCH}.tar.gz
ROOTFS=alpine-rootfs
mkdir ${ROOTFS}
tar xzf alpine-minirootfs-${ALPINE_VERSION}-${ALPINE_ARCH}.tar.gz -C ${ROOTFS}
cp /usr/bin/qemu-arm-static ${ROOTFS}/usr/bin/
mksquashfs ${ROOTFS} rootfs.squashfs
lxc import meta.tar.xz rootfs.squashfs --alias crossx
lxc launch crossx x
lxc exec x -- uname -a
Linux x 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 armv7l Linux
lxc image ls
| crossx | 1e5e5a2dafb8 | no | Alpinelinux x86_64 (20200330_1354) | x86_64 | CONTAINER | 5.45MB | Apr 2, 2020 at 6:25pm (UTC) |
Вы можете видеть, что в последних двух командах контейнер действительно armv7l, но LXD думает, что это x86_64.