Сценарий «KVM внутри VDS» встречается в тестовых стендах, лабораториях, CI/CD-пайплайнах, при необходимости быстро поднять несколько изолированных окружений без отдельного «железа». Технически это nested virtualization: гипервизор запускается внутри виртуальной машины провайдера и, в свою очередь, создает гостевые VM.
Ключевая сложность такого подхода – зависимость от лимитов провайдера виртуального сервера: разрешена ли передача аппаратной виртуализации (VT-x/AMD-V) во внутреннюю VM, доступен ли /dev/kvm, допускаются ли дополнительные MAC-адреса и режим promiscuous на виртуальной сетевой карте. Ниже описана практическая схема развертывания Oracle Linux в роли KVM-хоста внутри VDS с libvirt, настройкой bridge и проверками, позволяющими быстро понять, упирается ли задача в ограничения площадки.
Что важно уточнить до настройки: VDS, nested virtualization и «сетевые правила»
Запуск KVM возможен только на «полновиртуализированных» VPS/VDS (обычно KVM/VMware/Hyper-V). На контейнерных VPS (OpenVZ/LXC) гипервизор внутри не работает по определению – отсутствует доступ к аппаратной виртуализации и устройству /dev/kvm. Быстрая первичная проверка типа виртуализации:
systemd-detect-virt -v
systemd-detect-virt —vm
Если вывод указывает на container-тип (например, openvz, lxc), дальнейшие шаги по KVM не имеют смысла – потребуется именно VDS.
Nested virtualization зависит не от Oracle Linux, а от платформы провайдера. На стороне «железного» хоста (L0. гипервизор должен уметь и разрешать проброс VT-x/AMD-V в гостевую VM (L1). Без этого QEMU внутри VDS переключится на программную эмуляцию (TCG) или не запустится вовсе.
Сеть внутри VDS – отдельный слой ограничений. Для «честного» bridge в сторону провайдера (чтобы гостевые VM имели собственные MAC и получали адреса напрямую) часто требуется:
- разрешение на несколько MAC-адресов за одним портом (anti-spoofing/MAC filter)
- разрешение promiscuous mode (или аналогичных настроек в виртуальном коммутаторе)
- иногда – отключение/настройка port security на стороне облачной сети
Если провайдер жестко разрешает только один MAC на интерфейсе VDS, классический bridge станет «немым»: ARP/DHCP от гостевых VM уйдет в никуда. В таких условиях обычно остается NAT, маршрутизация через один MAC или внешний оверлей (VPN/VXLAN).
Встречаются площадки, где nested virtualization доступна не на всех линейках виртуальных серверов и отмечается отдельной опцией – например, в части тарифов и описаний у VPS.house подобные ограничения могут быть вынесены в условия сервиса. Независимо от конкретного провайдера, полезно заранее получить ответы на четыре вопроса: доступен ли KVM, разрешен ли bridge (несколько MAC), выдаются ли дополнительные публичные IP, есть ли запреты на загрузку модулей и работу с /dev/kvm.
Проверка nested virtualization на виртуальном сервере: признаки, тесты, интерпретация
Проверка выполняется в два этапа: наличие виртуализационных флагов CPU и фактическая работоспособность KVM-ускорения.
1. Есть ли VT-x/AMD-V внутри VDS
Для x86_64 признаки аппаратной виртуализации – флаги vmx (Intel) или svm (AMD):
lscpu | egrep -i ‘Virtualization|Hypervisor’
grep -E ‘vmx|svm’ /proc/cpuinfo | head
Отсутствие vmx/svm почти всегда означает: nested virtualization не включена на стороне провайдера (или платформа не поддерживает проброс). Иногда встречается ситуация, когда флаги видны, но /dev/kvm не создается – тогда переход к следующему шагу обязателен.
2. Доступен ли /dev/kvm и загружаются ли модули
На корректно работающем KVM-хосте в системе есть символьное устройство /dev/kvm:
ls -l /dev/kvm
Если файла нет, полезно проверить загрузку модулей и сообщения ядра:
sudo modprobe kvm
sudo modprobe kvm_intel 2>/dev/null || true
sudo modprobe kvm_amd 2>/dev/null || true
lsmod | grep -E ‘^kvm’
dmesg | grep -i kvm | tail -n 50
Типовые варианты:
- Модули загружаются, /dev/kvm есть – базовая предпосылка выполнена
- modprobe возвращает «Operation not supported» – провайдер не отдает аппаратную виртуализацию в VDS, либо ядро собрано/ограничено нетипично (редко для полноценных VDS)
- Флаги vmx/svm есть, но /dev/kvm нет – возможна блокировка устройства или нестандартные ограничения платформы; без /dev/kvm ускорения не будет
3. virt-host-validate: быстрый сводный отчет
Утилита virt-host-validate из пакетов libvirt помогает собрать диагностику в одном месте:
sudo virt-host-validate qemu
В VDS часть пунктов может быть помечена как WARN из‑за особенностей вложенной среды (например, IOMMU). Критичны именно проверки KVM: отсутствие доступа к /dev/kvm или принудительный переход на TCG.
Если nested virtualization недоступна, корректное решение – уточнение у провайдера возможности включить эту опцию или переход на другой тип виртуального сервера. Формулировки и ограничения обычно фиксируются в документации/правилах использования, пример такого раздела встречается в условиях аренды VDS у некоторых сервисов.
Установка KVM и libvirt на Oracle Linux 8/9: минимальный набор и запуск служб
Oracle Linux совместим с RHEL-подходами: пакеты KVM/QEMU и libvirt ставятся штатно через DNF. Перед установкой полезно обновить систему и убедиться, что включены репозитории BaseOS/AppStream (на минимальных образах каналы виртуализации иногда отключены).
Обновление системы:
sudo dnf -y update
Установка компонентов KVM/libvirt:
sudo dnf -y install qemu-kvm libvirt libvirt-daemon-kvm virt-install
Дополнительные инструменты (по ситуации):
- qemu-img (обычно входит в qemu-kvm) – управление образами дисков
- libvirt-client – утилиты virsh, virt-host-validate (во многих сборках ставится автоматически)
- bridge-utils – чаще не нужен, так как актуальные инструменты – ip и NetworkManager
Запуск и автозапуск libvirt:
sudo systemctl enable —now libvirtd
sudo systemctl status libvirtd —no-pager
Проверка доступа через virsh:
sudo virsh version
sudo virsh list —all
Oracle Linux обычно работает с SELinux в режиме enforcing. В типовой установке libvirt и QEMU поддерживаются политиками SELinux «из коробки». Если используются нестандартные каталоги для образов (не /var/lib/libvirt), может потребоваться корректировка контекстов (semanage fcontext и restorecon), иначе VM не сможет открыть диски.
Сеть для VM внутри VDS: NAT, bridge и macvtap в условиях ограничений провайдера
Сетевую схему рационально выбирать исходя из того, что именно требуется от гостевых VM: доступ «наружу», входящий доступ с интернета, отдельные публичные адреса или только внутренний сегмент. На VDS чаще всего используются три модели.
Вариант A: NAT через libvirt (почти всегда работает)
Это наиболее предсказуемый вариант для аренды VPS/VDS. Libvirt создает виртуальную сеть (обычно virbr0), раздает адреса по DHCP и выполняет NAT через основной интерфейс VDS. Гостевые VM получают исходящий доступ в интернет, но входящие подключения требуют проброса портов.
Проверка наличия сети по умолчанию:
sudo virsh net-list —all
Если сеть default существует, но не активна:
sudo virsh net-start default
sudo virsh net-autostart default
Плюсы: не зависит от MAC-фильтрации провайдера, не требует promiscuous mode, быстро поднимается.
Минусы: публичные адреса и L2-доступ «как отдельная машина в сети провайдера» недоступны без дополнительных настроек.
Вариант B: bridge на внешний интерфейс (работает только при разрешенных нескольких MAC)
Классический bridge (например, br0) подключает TAP-интерфейсы VM к тому же L2-сегменту, где находится VDS. В идеальном случае гостевые VM получают адреса так же, как отдельный физический сервер: через DHCP провайдера или со статикой, а маршрутизация выполняется «снаружи».
Критичное условие: провайдер должен принимать трафик с нескольких MAC-адресов, уходящих через один интерфейс VDS. Если включен anti-spoof и разрешен только один MAC, bridge не даст результата – гостевые VM не смогут обмениваться ARP и не получат связности.
Особенность VDS: администрирование обычно идет по SSH, поэтому перенос IP с физического интерфейса (например, ens3) на bridge требует аккуратности. Без out-of-band консоли (VNC/Serial/Rescue) легко потерять доступ. Распространенная практика – держать вторую SSH-сессию для отката и заранее подготовить план возврата конфигурации.
Пример настройки bridge через NetworkManager (типовой статический адрес /24):
# Определение интерфейса
ip -br a
# Создание bridge br0 (адрес/шлюз заменить на значения VDS)
sudo nmcli con add type bridge ifname br0 con-name br0 stp no ipv4.method manual ipv4.addresses 198.51.100.10/24 ipv4.gateway 198.51.100.1 ipv4.dns «1.1.1.1 8.8.8.8»
# Подключение внешнего интерфейса как slave (имя ens3 заменить)
sudo nmcli con add type ethernet ifname ens3 con-name ens3-slave master br0
# Поднятие соединений (имена соединений могут отличаться)
sudo nmcli con up br0
sudo nmcli con up ens3-slave
Если адрес выдан как /32 (часто в VDS): у шлюза может не быть «общей подсети» с адресом. В таком случае требуется маршрут к шлюзу как к хосту и onlink-маршрут по умолчанию. Реализация зависит от конкретной схемы провайдера и NetworkManager, поэтому корректнее сначала проверить вручную через ip route, а затем закреплять в NM-профиле.
Проверка после переноса адреса:
ip a show br0
ip r
ping -c 3 198.51.100.1
ping -c 3 1.1.1.1
Если связность пропала, выполняется откат: вернуть IP на исходный профиль интерфейса и поднять исходное соединение. Команды отката зависят от того, как назывался исходный connection в NetworkManager (nmcli con show).
Вариант C: macvtap (меньше действий на хосте, но те же ограничения по MAC)
Macvtap позволяет подключить VM напрямую к физическому интерфейсу без создания отдельного bridge. В libvirt обычно используется режим bridge или vepa. С точки зрения провайдера трафик все равно пойдет с «чужих» MAC-адресов, поэтому anti-spoof остается стоп-фактором.
Ограничение macvtap, о котором часто забывают: хост (сам VDS) может не иметь прямой L2-связности с гостевыми VM на macvtap на том же интерфейсе. Для управления гостями это обходится отдельным внутренним NAT/вторым интерфейсом или маршрутизацией.
Как выбрать схему: короткая логика принятия решения
- Требуется просто запуск VM «для себя», нужен исходящий доступ – NAT от libvirt дает наименьшее число зависимостей
- Нужны публичные адреса «на каждую VM» и провайдер разрешает несколько MAC – bridge или macvtap
- Провайдер запрещает несколько MAC, но нужны входящие подключения – NAT + проброс портов, либо routed-схема при наличии дополнительных IP и поддержки маршрутизации на стороне провайдера
Подключение libvirt к bridge и создание первой VM
После установки libvirt удобнее начинать с минимальной VM и убедиться, что ускорение KVM действительно используется. Далее добавляется сеть (NAT или bridge) и только после этого – «боевые» шаблоны.
Хранилище и формат диска
По умолчанию libvirt размещает образы в /var/lib/libvirt/images. Для тестов удобно использовать qcow2 (поддерживает снапшоты и тонкое выделение). При высоких I/O-нагрузках и ограничениях по CPU на VDS иногда выгоднее raw, но он потребует больше места.
Создание qcow2-образа на 20 ГБ:
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/testvm.qcow2 20G
Создание VM через virt-install (пример для NAT)
Пример ниже рассчитан на headless-сервер (без графики) и установку из ISO. ISO можно заранее загрузить в каталог, доступный libvirt.
sudo virt-install \
—name testvm \
—memory 2048 \
—vcpus 2 \
—disk path=/var/lib/libvirt/images/testvm.qcow2,bus=virtio \
—cdrom /var/lib/libvirt/boot/linux.iso \
—network network=default,model=virtio \
—graphics none \
—console pty,target_type=serial \
—boot useserial=on
Подключение к консоли:
sudo virsh console testvm
Создание VM в bridge-схеме
Если подготовлен bridge br0, достаточно указать его в параметрах сети:
sudo virt-install \
—name testvm-br \
—memory 2048 \
—vcpus 2 \
—disk path=/var/lib/libvirt/images/testvm-br.qcow2,size=20,bus=virtio \
—location /var/lib/libvirt/boot/linux.iso \
—network bridge=br0,model=virtio \
—graphics none \
—console pty,target_type=serial \
—extra-args «console=ttyS0,115200n8»
Для вложенной виртуализации часто полезно использовать CPU-режим, близкий к «пробросу возможностей»:
- host-passthrough – максимально близко к текущему vCPU VDS
- host-model – компромиссная модель, иногда более стабильная при переносимости
В libvirt это задается параметром —cpu (для virt-install) или через XML домена. Если провайдер скрывает часть флагов CPU, некоторые гостевые ОС могут корректнее работать на host-model, но для задач, завязанных на конкретные инструкции, обычно требуется host-passthrough.
Как убедиться, что VM действительно работает на KVM, а не на эмуляции TCG
Вложенная среда легко маскирует проблему: VM «запускается», но производительность оказывается неприемлемой из‑за программной эмуляции. Несколько проверяемых признаков:
1. Тип домена в libvirt
sudo virsh dumpxml testvm | grep -E ‘<domain|type=’
Ожидается домен типа kvm (пример: <domain type=’kvm’>). Если указан qemu, ускорение KVM не используется.
2. Командная строка QEMU и наличие /dev/kvm
Запущенный процесс qemu обычно содержит признаки KVM-акселерации:
ps aux | grep -E ‘qemu-system|qemu-kvm’ | grep -v grep
Дополнительно проверяется наличие /dev/kvm и права доступа. На сервере, где управление ведется не от root, может потребоваться включение пользователя в группу, имеющую доступ к /dev/kvm, или работа через sudo virsh.
3. Косвенные признаки в логах
Логи домена в /var/log/libvirt/qemu/ иногда содержат подсказки, почему KVM отключен (например, «failed to initialize KVM»). Поиск по строкам:
sudo grep -i ‘kvm’ /var/log/libvirt/qemu/testvm.log | tail -n 50
Типовые проблемы в VDS-сценарии и быстрые действия
Проблема: vmx/svm отсутствует, /dev/kvm не появляется
- Причина: nested virtualization отключена на стороне провайдера или текущий тип VPS – контейнерный
- Проверка: systemd-detect-virt, lscpu, virt-host-validate qemu
- Решение: включение nested virtualization (если доступно) или смена платформы/типа услуги. Иного программного обхода нет
Проблема: VM запускается, но очень медленно
- Частая причина: QEMU перешел в TCG из‑за отсутствия KVM
- Проверка: virsh dumpxml (domain type), логи libvirt, наличие /dev/kvm
- Решение: восстановить доступ к KVM (на стороне провайдера/конфигурации), иначе производительность будет близка к эмуляции
Проблема: bridge поднят, но гостевые VM не получают DHCP/нет ARP
- Причина: MAC-фильтрация или port security у провайдера – принимается только MAC основного интерфейса VDS
- Проверка: tcpdump -eni br0 arp и tcpdump -eni ens3 arp (если tcpdump установлен), сравнение MAC в исходящих кадрах
- Решение: перейти на NAT/routed-схему или согласовать у провайдера режим, допускающий несколько MAC (иногда называется «promiscuous mode», «MAC spoofing», «порт без защиты»)
Проблема: после настройки bridge потерян SSH-доступ
- Причина: IP/маршрут/шлюз перенесены некорректно, профиль NM не поднялся
- Практика: выполнять перенос IP на bridge только при наличии консоли провайдера или заранее подготовленного отката, держать второй SSH-сеанс, проверять маршруты сразу после применения
Проблема: конфликт с firewalld/nftables и libvirt NAT
- Симптом: VM получает адрес, но нет выхода в интернет
- Проверка: включен ли форвардинг (sysctl net.ipv4.ip_forward), есть ли правила NAT в nft/iptables
- Решение: использовать стандартную сеть libvirt default (она сама создает правила), не отключать подсистемы, от которых зависит libvirt (в частности, фильтрацию/форвардинг). При нестандартных firewall-настройках потребуется явное разрешение форвардинга между virbr0 и внешним интерфейсом
Чек-лист перед эксплуатацией KVM внутри VDS
- Nested virtualization: присутствуют vmx/svm, есть /dev/kvm, virt-host-validate qemu не показывает FAIL по KVM
- Ресурсы: запас по RAM и диску с учетом того, что VDS уже ограничен квотами провайдера; qcow2 не отменяет фактических лимитов по месту
- CPU: при необходимости задан —cpu host-model или host-passthrough; учтено, что производительность nested KVM обычно ниже «первого уровня»
- Сеть: выбран NAT или bridge в зависимости от MAC-ограничений; bridge используется только при подтвержденном разрешении нескольких MAC/промискуитета
- Управление: libvirt не открыт в сеть по TCP без необходимости; доступ осуществляется локально (UNIX socket) или через защищенный канал
- Время: настроен NTP/chrony на хосте и гостях – вложенная виртуализация чувствительна к дрейфу времени
Итог
Oracle Linux подходит для роли KVM-хоста внутри VDS благодаря привычной экосистеме пакетов RHEL-типа и штатной поддержке libvirt/QEMU. Однако успех сценария определяется не столько ОС, сколько возможностями провайдера: пробросом VT-x/AMD-V в VDS и сетевыми правилами (MAC spoofing, promiscuous mode, дополнительные IP). Практический подход – сначала подтвердить nested virtualization и доступ к /dev/kvm, затем поднять libvirt, выбрать сетевую схему (NAT как наиболее совместимую или bridge при разрешенных нескольких MAC) и только после этого масштабировать стенд.
