Incus или LXD: что ставить на Ubuntu VPS

Incus или LXD: короткий ответ

Incus или LXD на новом Ubuntu VPS? В 2026 году почти всегда Incus. Это тот же менеджер системных контейнеров и виртуальных машин. Его ведут люди, которые когда-то создали LXD. Он ставится обычным apt и берёт образы с общего сервера linuxcontainers.org. LXD стоит выбрать в двух случаях: вам нужна коммерческая поддержка Canonical, или ваша инфраструктура уже работает на snap-пакетах и образах ubuntu:.

Если вы уже поставили Incus по нашему руководству по системным контейнерам Incus на VPS, переделывать ничего не нужно. Ниже объясняется, откуда взялись два проекта, чем они отличаются на практике сегодня и в каком случае ответ будет другим.

Для тех, кто пришёл из Proxmox: где здесь LXC

На Proxmox вы запускали контейнеры командой pct. Под ней работает LXC: низкоуровневая библиотека liblxc и набор утилит lxc-*. Incus и LXD построены на той же основе. Контейнеры запускает liblxc, виртуальные машины запускает QEMU, а демон добавляет REST API, пулы хранения, сети, профили и каталог образов. На одном Ubuntu VPS Incus даёт примерно то же, что Proxmox даёт на целом физическом узле, только без веб-панели по умолчанию. Чем такой подход отличается от отдельного гипервизора, разобрано в статье Proxmox или обычный VPS. Чем системный контейнер отличается от полной виртуальной машины, объясняет сравнение KVM, Xen и LXC на VPS.

Есть одна ловушка с именами. Клиент LXD называется lxc. Это не утилиты LXC из мира Proxmox, а клиент демона LXD, и контейнеры, созданные через lxc-create, он не видит. У Incus клиент называется incus, поэтому там путаницы нет.

Ещё одно замечание до выбора. Контейнеры работают на любом KVM VPS. Виртуальным машинам внутри Incus или LXD нужно устройство /dev/kvm, а на VPS оно есть только при включённой вложенной виртуализации на VPS. Это ограничение одинаково для обоих проектов, поэтому на выбор между ними оно не влияет.

Откуда два проекта: история раскола по датам

Каждую дату ниже я проверил по объявлениям на linuxcontainers.org и по публикациям Canonical.

• 4 июля 2023 года. Canonical объявила, что LXD уходит из проекта Linux Containers и становится собственным проектом компании. До этого LXD больше восьми лет развивался внутри сообщества, рядом с LXC.
• 7 августа 2023 года. Linux Containers объявил Incus. Это форк LXD, который Aleksa Sarai сделал сразу после выпуска LXD 5.16. Проект Linux Containers принял Incus к себе и передал ему инфраструктуру, которая раньше обслуживала LXD.
• 12 декабря 2023 года. Перед выпуском LXD 5.20 Canonical перевела свой код в LXD с лицензии Apache 2.0 на AGPLv3 (GNU Affero General Public License). Для всех новых изменений она ввела CLA (contributor license agreement, соглашение с участником проекта). Код сообщества, написанный раньше, остался под Apache 2.0, поэтому LXD теперь распространяется под смесью двух лицензий. Incus остался под Apache 2.0.
• 16 декабря 2023 года. Linux Containers опубликовал график отключения пользователей LXD от сервера образов images.linuxcontainers.org. Доступ сокращали по шагам начиная с 1 января 2024 года. С 1 мая 2024 года его потеряли все пользователи LXD. Уже запущенные экземпляры это не затронуло.
• 3 апреля 2024 года. Canonical объявила собственный сервер образов images.lxd.canonical.com. Начиная с LXD 5.21.1 клиент lxc получает его как remote (удалённый источник образов) с именем images:.

Зачем вам эта история? Каждая из этих дат превратилась в отличие, которое видно прямо в терминале. Ниже они разобраны по очереди.

Как ставится каждый: snap против пакетов дистрибутива

LXD на Ubuntu распространяется только как snap. В архиве Ubuntu есть пакет lxd-installer, но это обёртка: при первом вызове lxc она устанавливает snap. Snap обновляется сам, по расписанию, а вы управляете этим через каналы и окна обновлений. Как ограничить это на сервере, описано в статье об управлении обновлениями snap на Ubuntu Server.

snap info lxd
sudo snap install lxd --channel=5.21/stable

snap info lxd выводит список каналов. Канал состоит из ветки (track) и уровня стабильности, например 5.21/stable. Без флага --channel snap ставит ветку по умолчанию. По документации Canonical на 4 октября 2026 года она указывает на LTS 5.21. Указывайте канал явно, тогда вы точно знаете, что стоит на сервере.

Incus ставится обычным deb-пакетом. Источников два: архив Ubuntu (раздел universe) и репозиторий Zabbly, который поддерживает Stéphane Graber, один из ведущих разработчиков Incus.

Что предлагает архив Ubuntu

apt-cache policy incus

Строка Candidate: показывает версию, которую поставит apt install incus. Я проверил публичный архив Ubuntu (Launchpad и packages.ubuntu.com) 4 октября 2026 года. Результат такой:

• Ubuntu 24.04: 6.0.0-1ubuntu0.3 из universe и noble-updates. Это первый выпуск ветки 6.0 LTS, к которому Ubuntu добавляет только исправления безопасности.
• Ubuntu 26.04: 6.0.5-8 из universe.

Обе версии относятся к Incus 6.0 LTS. Новых функций там не будет, и для LTS это нормально. Но разрыв в 24.04 большой: апстрим довёл эту ветку как минимум до 6.0.6, а в архиве осталась 6.0.0. Я смотрел архив через веб-интерфейс, а не в живой системе. Выполните команду сами: если после этой даты вышло обновление, строка Candidate: у вас будет новее.

Что предлагает Zabbly

Репозиторий Zabbly собирает Incus для Ubuntu 22.04, 24.04 и 26.04, а также для Debian 12 и 13, на архитектурах amd64 и arm64. В нём несколько веток: stable с ежемесячными выпусками, lts-6.0, lts-7.0 и daily для тестов. Ключ и файл источника из официального README выглядят так (здесь выбрана ветка lts-6.0):

curl -fsSL https://pkgs.zabbly.com/key.asc | gpg --show-keys --fingerprint
sudo mkdir -p /etc/apt/keyrings/
sudo curl -fsSL https://pkgs.zabbly.com/key.asc -o /etc/apt/keyrings/zabbly.asc
sudo sh -c 'cat <<EOF > /etc/apt/sources.list.d/zabbly-incus-lts-6.0.sources
Enabled: yes
Types: deb
URIs: https://pkgs.zabbly.com/incus/lts-6.0
Suites: $(. /etc/os-release && echo ${VERSION_CODENAME})
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/zabbly.asc

EOF'
sudo apt-get update
apt-cache policy incus

Первая команда должна показать отпечаток ключа 4EFC 5906 96CB 15B8 7C73 A3AD 82CC 8797 C838 DCFD. Если отпечаток другой, остановитесь и не добавляйте репозиторий. После apt-get update строка Candidate: должна указывать на pkgs.zabbly.com. Номера версий в Zabbly меняются каждый месяц, поэтому здесь я их не привожу: смотрите их в выводе apt-cache policy. Для ветки stable или lts-7.0 замените lts-6.0 в имени файла и в строке URIs.

Файл записан в формате deb822. Если тот же репозиторий уже прописан строкой в старом sources.list, apt увидит его дважды. Как это распознать и исправить, разобрано в статье об ошибке дублей в источниках apt формата deb822.

Ловушка с ядром на Ubuntu 24.04

Incus 7.0 LTS поднял минимальную версию ядра Linux до 6.12, а поддержку cgroup v1 и xtables убрал полностью. Ubuntu 24.04 с ядром GA (general availability, исходное ядро выпуска) работает на Linux 6.8. Значит, ветка lts-7.0 на таком сервере не подходит. Вариантов два: оставаться на lts-6.0 или перейти на ядро HWE (hardware enablement), которое в 24.04 уже новее 6.12. Чем эти ядра отличаются и чем рискует переход, объясняет статья про ядра HWE и GA на Ubuntu Server. Ядро Ubuntu 26.04 этому требованию соответствует.

Какие образы видит каждый

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

У Incus remote images: указывает на images.linuxcontainers.org. Там лежат образы Ubuntu, Debian, Alpine, Rocky, Arch и многих других систем, для контейнеров и для виртуальных машин.

incus remote list
incus image list images: debian
incus launch images:ubuntu/24.04 web1

incus remote list должен показать строку images с адресом https://images.linuxcontainers.org. Ubuntu для Incus тоже берётся отсюда, по имени вида images:ubuntu/24.04.

У LXD с 1 мая 2024 года доступа к images.linuxcontainers.org нет. У него свои источники: ubuntu: и ubuntu-daily: с официальными облачными образами Canonical. В версиях начиная с 5.21.1 к ним добавлен images:, который ведёт на images.lxd.canonical.com.

lxc remote list
lxc launch ubuntu:24.04 web1

Сама Canonical называет образы на images.lxd.canonical.com неофициальными: это удобство для тестов, а для работы она советует официальные образы дистрибутивов. В объявлении от апреля 2024 года контейнеры там собирались для amd64 и arm64, а виртуальные машины только для amd64. Отсюда практическое следствие. Старая статья с командой lxc launch images:debian/12 на LXD теперь обращается к другому серверу, и наличие конкретного образа зависит от каталога Canonical.

Ритм выпусков и ветки LTS

Incus. Новая функциональная версия выходит примерно раз в месяц, и каждая поддерживается около месяца. Для сервера, который должен работать годами, есть LTS. Incus 6.0 LTS вышел в апреле 2024 года и поддерживается до июня 2029 года. Incus 7.0 LTS вышел 5 мая 2026 года и поддерживается до июня 2031 года. Первые два года 7.0 получает исправления ошибок и небольшие улучшения, затем только исправления безопасности. Обновиться до 7.0 можно с 6.0.6 LTS или с 6.23.

LXD. Ветки живут в каналах snap. По документации Canonical на 4 октября 2026 года поддерживаются две LTS: 5.21 до июня 2029 года (полная поддержка) и 5.0 до июня 2027 года (только сопровождение). Функциональная ветка называется 6. Раз в два года текущая функциональная ветка становится LTS, и Canonical планировала сделать это с веткой 6 в 2026 году. На дату проверки документация всё ещё называет веткой по умолчанию 5.21.

На практике разница вот в чём. Incus из архива Ubuntu следует циклу самой ОС: версия меняется вместе с выпуском Ubuntu, а между выпусками приходят только исправления. LXD в snap живёт отдельно от ОС. Его ветку выбираете вы, а обновления внутри ветки приходят автоматически.

Перенос с LXD на Incus: что делает lxd-to-incus

Если LXD уже работает и вы решили перейти, у Incus есть инструмент lxd-to-incus. Он переносит всю базу данных и все пулы хранения LXD в Incus на том же сервере. После переноса экземпляры, сети, профили и тома выглядят так же, как раньше. В анонсе Incus 7.0 сказано, что инструмент проверен на версиях LXD от 4.0 LTS до последнего исправления 5.21.

Чего он не переносит: настройки клиента. Удалённые серверы и псевдонимы из ~/snap/lxd/common/config/ или ~/.config/lxc/ нужно скопировать в ~/.config/incus/ вручную. Группа доступа тоже меняется: вместо lxd у Incus группа incus-admin.

Обратного пути нет. Документация Incus называет перенос разрушительным с точки зрения LXD. После него демон LXD может не запуститься, а lxc list покажет пустой список. Инструмента для переноса назад нет. Откатиться можно только из резервной копии, сделанной до переноса.

Что сохранить до переноса

1. Снимок всего VPS в панели провайдера. Это самый быстрый способ вернуть сервер в исходное состояние.
2. Экспорт каждого важного экземпляра в файл вне пула хранения.
3. Текстовую копию конфигурации, чтобы после переноса сравнить её с результатом.
4. Список пользователей группы lxd.

sudo lxc list
sudo lxc export web1 /root/web1-before-incus.tar.gz
sudo sh -c '{ lxc storage list; lxc network list; lxc profile show default; } > /root/lxd-config-before.txt'
getent group lxd

Обычный lxc snapshot здесь не защищает. Снимок лежит в том же пуле хранения, и lxd-to-incus переносит его вместе с экземпляром. Если перенос пойдёт не так, снимок пострадает вместе с ним.

Сам перенос

Установите Incus, но не инициализируйте его: не запускайте incus admin init. Инструменту нужен пустой Incus. В архиве Ubuntu сам lxd-to-incus лежит в отдельном пакете, и в двух выпусках этот пакет называется по-разному:

# Ubuntu 24.04
sudo apt install incus incus-tools
# Ubuntu 26.04
sudo apt install incus incus-extra

Если вы ставите Incus из Zabbly, проверьте, что команда появилась: command -v lxd-to-incus должен вывести путь. Документация Incus советует переносить на самую свежую стабильную версию Incus, поэтому на 24.04 лучше брать Incus из Zabbly, а не 6.0.0 из архива.

Перед запуском оба демона должны отвечать:

sudo incus info
sudo lxc info
sudo lxd-to-incus

lxd-to-incus проверяет обе стороны, показывает, что собирается сделать, и спрашивает подтверждение. Флаг --yes убирает вопрос, но в первый раз прочитайте его сами. Флаг --ignore-version-check отключает проверку версии LXD. Он убирает только проверку, а не риск, поэтому на рабочем сервере без копии его не используйте.

После переноса уберите LXD, чтобы два демона не делили сервер:

sudo snap remove --purge lxd
sudo apt remove lxd-installer
sudo usermod -aG incus-admin "$USER"

lxd-installer стоит удалить, потому что иначе первый же случайный вызов lxc снова поставит snap LXD. Членство в группе применяется при входе в систему, поэтому выйдите и зайдите снова. Затем выполните incus list. Там должны быть те же экземпляры, что в выводе lxc list до переноса, а сети и пулы должны совпадать с /root/lxd-config-before.txt.

Решение: что ставить на свой VPS

Новый сервер на Ubuntu 26.04. Ставьте Incus из архива: sudo apt install incus. Вы получаете 6.0 LTS с поддержкой до 2029 года без внешних репозиториев и без snap.

Новый сервер на Ubuntu 24.04. Ставьте Incus из Zabbly, ветку lts-6.0. Версия 6.0.0 из архива слишком старая. Ветка lts-7.0 подойдёт только после перехода на ядро HWE.

Нужны новые функции каждый месяц. Zabbly, ветка stable. Обновляйтесь каждый месяц, потому что старый выпуск этой ветки поддерживается недолго.

LXD 5.21 уже работает в продакшене. Спешить не нужно: эта ветка поддерживается до июня 2029 года. Планируйте перенос на спокойное окно, когда будут готовы снимок VPS и экспорт экземпляров.

Вам нужна поддержка Canonical. Если вы покупаете Ubuntu Pro или строите MicroCloud, оставайтесь на LXD. Лицензия AGPLv3 и CLA важны только тем, кто меняет код LXD или встраивает его в свой продукт.

Вы на ветке LXD 6. Перенос возможен, но в анонсе Incus 7.0 проверка заявлена только до 5.21. Сначала прогоните lxd-to-incus на копии VPS, восстановленной из снимка.

Если же вам на самом деле нужны не системные контейнеры, а контейнеры приложений с одним процессом внутри, ни Incus, ни LXD не нужны. Тогда читайте сравнение Podman и Docker на VPS.

FAQ

Можно ли поставить Incus и LXD на один сервер?

Можно, и на время переноса lxd-to-incus даже требует, чтобы работали оба демона. Постоянно держать их рядом не стоит. У каждого свой мост, свой DHCP-сервер и свои правила файрвола, и при проблеме с сетью вам придётся выяснять, чьё правило сработало. После переноса удалите snap LXD командой sudo snap remove --purge lxd и пакет lxd-installer.

Почему LXD не находит образ из старой инструкции с images:?

С 1 мая 2024 года LXD не имеет доступа к images.linuxcontainers.org. Начиная с LXD 5.21.1 remote images: в LXD ведёт на images.lxd.canonical.com, а это другой каталог. В объявлении Canonical от апреля 2024 года виртуальные машины там собирались только для amd64. Проверьте адрес командой lxc remote list. Если нужен конкретный образ из каталога linuxcontainers.org, его даёт Incus.

Можно ли вернуться на LXD после lxd-to-incus?

Инструмента для обратного переноса нет. Документация Incus называет перенос разрушительным для LXD: демон LXD после него может не запуститься, а lxc list будет пустым. Вернуться можно только из копии, сделанной заранее: из снимка VPS в панели провайдера или из файлов lxc export, сохранённых вне пула хранения.

Какую версию Incus ставить на Ubuntu 24.04?

В архиве Ubuntu 24.04 на 4 октября 2026 года лежит 6.0.0-1ubuntu0.3, первый выпуск ветки 6.0 LTS. Лучше подключить репозиторий Zabbly с веткой lts-6.0, где есть свежие исправления 6.0.x. Ветка lts-7.0 требует ядро Linux 6.12 или новее, а стандартное ядро 24.04 имеет версию 6.8, поэтому она подходит только с ядром HWE.

Нужен ли snap, чтобы пользоваться Incus?

Нет. Incus распространяется обычными deb-пакетами: из раздела universe архива Ubuntu или из репозитория Zabbly. Это главное практическое отличие от LXD, который на Ubuntu ставится только как snap и обновляется по расписанию snapd.