smolvm

Доставляйте и запускайте программное обеспечение с изоляцией по умолчанию.

Это CLI-инструмент, который позволяет:

1. Управлять и запускать пользовательские Linux-виртуальные машины локально: холодный запуск за доли секунды, кроссплатформенность (macOS, Linux, Windows), эластичное использование памяти.
2. Упаковывать виртуальную машину с сохранённым состоянием в один файл (.smolmachine) для восстановления на любой поддерживаемой платформе.

Установка

# установка (macOS + Linux)
curl -sSL https://smolmachines.com/install.sh | bash

# для кодинг-агентов — установка + просмотр всех команд
curl -sSL https://smolmachines.com/install.sh | bash && smolvm --help

Или скачайте из GitHub Releases и поместите в ~/.local/share/.

Windows: скачайте релиз windows-x86_64 (включает krun.dll + libkrunfw.dll), распакуйте его и запустите smolvm.exe. Требуется включённая функция Windows Hypervisor Platform (WHP).

Быстрый старт

# выполнить команду в эфемерной ВМ (удаляется после завершения)
smolvm machine run --net --image alpine -- sh -c "echo 'Hello world from a microVM' && uname -a"

# интерактивная оболочка
smolvm machine run --net -it --image alpine -- /bin/sh
# внутри ВМ: apk add sl && sl && exit

Smolfile

Smolfile описывает машину в формате TOML — аналог Dockerfile или cloud-init файла, но для целой ВМ: образ, ресурсы, сетевая политика, монтирования, порты и команды настройки в одном файле, который хранится в репозитории.

image = "python:3.12-alpine"
net = true
cpus = 4
memory = 4096

ports = ["8000:8000", "5173-5180:5173-5180"]
volumes = ["./src:/app"]
init = ["pip install -r /app/requirements.txt"]

[network]
allow_hosts = ["api.stripe.com", "pypi.org"]

[auth]
ssh_agent = true

smolvm machine create --name myvm -s Smolfile   # или --smolfile <PATH>
smolvm machine start --name myvm

Сопоставления портов принимают одиночный порт ("8080"), явное сопоставление ("8080:80") или диапазоны одинаковой длины один-к-одному ("5173-5180:5173-5180"). Машина может публиковать не более 64 конкретных сопоставлений.

Неизвестные ключи отклоняются, а не игнорируются, поэтому опечатка приведёт к ошибке на этапе создания, а не к молчаливому бездействию.

Основные ключи: image, cpus, memory, net, ports, volumes, env, init, workdir, gpu, cuda, docker_socket, storage, overlay, а также таблицы [network], [dev], [auth], [health], [restart], [service].

Снимок машины в переиспользуемый образ

Вам не нужен Dockerfile для сохранения окружения. Настройте машину как угодно — вручную или из Smolfile — затем упакуйте остановленную машину в артефакт .smolmachine и отправьте его в любой OCI-реестр:

smolvm machine shell --name myvm          # установка и настройка в интерактивном режиме
smolvm machine stop  --name myvm
smolvm pack create --from-vm myvm -o myvm
smolvm pack push --file myvm.smolmachine ghcr.io/you/myvm:v1

Любой желающий может затем скачать его и загрузить точно такую же машину:

smolvm pack pull ghcr.io/you/myvm:v1

Рабочие примеры Smolfile: python · node · docker-in-vm · local-llm · headless-browser · doom

Для чего это использовать

Песочница для недоверенного кода — запускайте недоверенные программы в ВМ с аппаратной изоляцией. Файловая система хоста, сеть и учётные данные отделены границей гипервизора.

# сеть отключена по умолчанию — недоверенный код не может связаться с внешним миром
smolvm machine run --image alpine -- nslookup example.com
# не работает — нет доступа к сети

# ограничьте исходящий трафик — разрешите только определённые хосты
smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -q -O /dev/null https://registry.npmjs.org
# работает — хост разрешён

smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -q -O /dev/null https://google.com
# не работает — нет в списке разрешённых

Упаковка в переносимые исполняемые файлы — превратите любую рабочую нагрузку в автономный бинарный файл. Все зависимости уже включены — без шага установки, без загрузок во время выполнения, загрузка менее чем за 200 мс.

smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version
# Python 3.12.x — изолированно, без pyenv/venv/conda

Использование локальных контейнерных образов — для CI, изолированных хостов и быстрой итерации. Передайте --image архив docker save / podman save, передайте его через stdin или укажите распакованную директорию rootfs. Работа с образами делегируется вашему контейнерному инструментарию; smolvm просто загружает результат.

# соберите локально, запустите в ВМ без push/pull
docker build -t myapp .
docker save myapp | smolvm machine run --image - -- ./app

# из файла архива (загрузка без сети)
smolvm machine run --image ./myapp.tar -- ./app

# из уже распакованной директории rootfs
smolvm machine run --image ./rootfs/ -- ./app

Постоянные машины для разработки — создавайте, останавливайте, запускайте. Установленные пакеты переживают перезагрузки.

smolvm machine create --net --name myvm
smolvm machine start --name myvm
smolvm machine exec --name myvm -- apk add sl
smolvm machine exec --name myvm -it -- /bin/sh
# внутри: sl, ls, uname -a — введите 'exit' для выхода
smolvm machine stop --name myvm

Используйте git и SSH без копирования приватных ключей в гостевую систему. Пробросьте SSH-агент хоста в ВМ. Гостевая система может запросить у агента подпись любым проброшенным ключом, пока доступен сокет, поэтому пробрасывайте его только в те рабочие нагрузки, которым доверяете. Требуется запущенный SSH-агент на хосте (проверка: ssh-add -l).

smolvm machine run --ssh-agent --net --image alpine -- sh -c "apk add -q openssh-client && ssh-add -l"
# выводит ключи хоста; материал приватных ключей остаётся в агенте хоста

smolvm machine exec --name myvm -- git clone [email protected]:org/private-repo.git

Объявление окружений в файле — см. Smolfile выше для воспроизводимой конфигурации машин, а также для создания снимка настроенной машины в переиспользуемый образ .smolmachine без написания Dockerfile.

Как это работает

Каждая рабочая нагрузка выполняется в ВМ с аппаратной виртуализацией и собственным гостевым ядром на Hypervisor.framework (macOS), KVM (Linux) или Windows Hypervisor Platform (Windows). libkrun — это VMM, а libkrunfw предоставляет гостевое ядро. Упакуйте всё в .smolmachine — и оно будет работать в любом месте, где архитектура хоста совпадает, без каких-либо зависимостей.

Образы используют формат OCI — тот же открытый стандарт, что и Docker. Любой образ с Docker Hub, ghcr.io или других OCI-реестров можно скачать и загрузить как microVM. Демон Docker не требуется.

По умолчанию: 4 vCPU, 8 ГиБ ОЗУ. Память эластична благодаря virtio balloon — хост выделяет только то, что гость реально использует, и автоматически возвращает остальное. Потоки vCPU засыпают в гипервизоре в простое, поэтому избыточное выделение ресурсов почти ничего не стоит. Переопределите с помощью --cpus и --mem.

Модель безопасности

smolvm усиливает границу гость/хост, предоставляя каждой рабочей нагрузке отдельную ВМ и гостевое ядро. Сам по себе он не является защищённой многопользовательской плоскостью управления:

• Процессы CLI smolvm и VMM выполняются с правами вызывающего пользователя хоста. Эта учётная запись, ОС хоста, бэкенд гипервизора, libkrun и smolvm входят в доверенную вычислительную базу.
• Директории хоста, переданные с помощью --volume, намеренно предоставляются гостю с запрошенным доступом. Не монтируйте секреты или чувствительные пути в недоверенную рабочую нагрузку.
• --ssh-agent не копирует материал приватных ключей в гостевую систему, но предоставляет гостю доступ к проброшенному сокету агента и, следовательно, возможность запрашивать подписи, пока ВМ работает.
• Сеть отключена по умолчанию. Включение --net, проброса портов или сервисов хоста расширяет доступную поверхность рабочей нагрузки.
• В автономном локальном использовании состояние и управляющие конечные точки smolvm ограничены окружением вызывающего пользователя. Для враждебных локальных сожителей добавьте разделение учётных записей на уровне хоста и ограничение ОС вокруг процесса VMM. Этот раздел не описывает отдельную облачную плоскость управления smolmachines или её гарантии изоляции арендаторов.
• Архивы релизов публикуют контрольные суммы SHA-256, и установщик отклоняет несоответствие, когда файл контрольной суммы доступен. Релизы в настоящее время не подписаны и не сопровождаются атрибутами происхождения, а установщик разрешает установку, если файл контрольной суммы не может быть загружен.

Относитесь к root в гостевой системе как к недоверенному. Граница ВМ ограничивает его прямой доступ к хосту, в то время как каждая явно проброшенная возможность, включая монтирования, сетевой доступ, порты и доступ к SSH-агенту, становится частью полномочий рабочей нагрузки.

Сравнение

Поддержка платформ

Известные ограничения

• Сеть подключается по желанию (--net при machine create). Только TCP/UDP, без ICMP.
• Монтирование томов: только директории (не отдельные файлы). Монтирование в /workspace (-v /host/dir:/workspace) имеет приоритет над рабочим пространством диска хранилища по умолчанию — используется ваша директория хоста.
• macOS: бинарный файл должен быть подписан с правами Hypervisor.framework (com.apple.security.hypervisor). Поставляемый релиз подписан; повторно подписанный или свежесобранный бинарный файл молча теряет это право, и каждый запуск ВМ завершается ошибкой krun_start_enter returned: -22 (EINVAL). Переподпишите (допустима ad-hoc подпись): codesign --force --sign - --entitlements hv.entitlements <smolvm-bin>, где hv.entitlements — это plist, содержащий <key>com.apple.security.hypervisor</key><true/>.
• --ssh-agent требует запущенный SSH-агент на хосте (должен быть установлен SSH_AUTH_SOCK).
• Ускорение GPU требует libkrun, собранный с GPU=1, а также virglrenderer и Vulkan-драйвер на хосте (см. Ускорение GPU ниже).
• Windows: --net работает так же, как на других платформах (virtio-net с пробросом входящих портов; TSI для ВМ только с исходящим трафиком), как и machine exec / интерактивные сессии и machine stats. Пока недоступно на Windows: ускорение GPU и machine fork / снимки. Для pack create требуется storage-template.ext4 / overlay-template.ext4 рядом с smolvm.exe (на Windows нет хостового mkfs.ext4).

Ускорение GPU

smolvm предоставляет гостям GPU хоста через virtio-gpu / Venus (Vulkan поверх virtio). Гостевые рабочие нагрузки видят реальное Vulkan-устройство; на Linux + Intel это отображается как:

ANGLE (Intel, Vulkan 1.4 (Virtio-GPU Venus (Intel(R) UHD Graphics ...)), venus)

Требования к хосту

macOS — virglrenderer и MoltenVK включены в дистрибутив smolvm. Дополнительные установки не требуются.

Linux — virglrenderer и хостовый Vulkan-драйвер должны быть установлены из системного менеджера пакетов:

virglrenderer зависит от libEGL и libdrm из стека драйверов GPU хоста — они аппаратно-специфичны и не могут быть включены в поставку. Любой Linux-хост с поддержкой GPU уже имеет их, установленные вместе с драйвером GPU.

Использование

# CLI
smolvm machine run --gpu --image alpine -- vulkaninfo --summary

# Smolfile
# gpu = true
# gpu_vram = 2048   # МиБ, по умолчанию 4096

Гостевой загрузчик Vulkan должен быть направлен на virtio ICD:

export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/virtio_icd.x86_64.json

Пример headless-браузера

См. examples/headless-browser/ для рабочей настройки Chromium с использованием ANGLE + Venus для аппаратно-ускоренного WebGL внутри headless-ВМ.

Удалённый вызов CUDA API

--gpu и --cuda предоставляют разные интерфейсы. --gpu предоставляет Vulkan через virtio-gpu / Venus; он не предоставляет CUDA. --cuda включает удалённый вызов CUDA API: гостевые заглушки без драйверов пересылают вызовы CUDA через vsock хостовому процессу, который выполняет их через драйвер NVIDIA хоста.

Удалённый вызов CUDA требует GPU NVIDIA и работающий драйвер NVIDIA на хосте. Это не проброс GPU: гость не получает ни физическое устройство, ни драйвер NVIDIA.

Linux-хосты с интенсивным форкингом должны использовать ядро, содержащее исправление KVM из основного дерева 916b7f4. Затронутые ядра могут периодически сообщать ENOMEM при первом KVM_RUN даже при достаточном объёме памяти хоста; smolvm снижает вероятность и заменяет отказавший рабочий процесс, но обновление ядра является окончательным исправлением.

Граница ВМ по-прежнему изолирует CPU, память и файловую систему рабочей нагрузки. Доступ к GPU опосредован процессами хоста и общим GPU хоста, поэтому изоляция GPU остаётся на уровне процессов, а не на уровне аппаратного обеспечения или ВМ. Не рассматривайте удалённый вызов CUDA как защищённую границу изоляции GPU для нескольких арендаторов.

См. Доступ к GPU через удалённый вызов API: как microVM без драйверов запускает CUDA для описания архитектуры, компромиссов и сравнения с пробросом.

Разработка

См. docs/DEVELOPMENT.md.

Apache-2.0 · сделано @binsquare · twitter · github