Проброс диска и USB в виртуалку: когда без этого никак

MAATRIX

Виртуальной машине обычно хватает файла-образа на хосте — это удобно, переносимо и просто бэкапится. Но иногда гостевой системе нужен не образ, а конкретное физическое устройство: диск целиком со всеми его контроллерными функциями или USB-донгл, который просто обязан воткнуться именно в эту VM. Разберём, когда это реально оправдано, как это делается технически и почему это заметно проще, чем проброс видеокарты.

Проброс диска: в чём разница с виртуальным образом

Когда вы создаёте виртуальный диск (qcow2, raw-файл или LVM-том), гипервизор эмулирует блочное устройство поверх файловой системы или логического тома хоста. Гостевая ОС видит обычный диск, но физически это слой абстракции: hypervisor перехватывает каждый запрос ввода-вывода, транслирует его в операции с файлом или томом. Для подавляющего большинства задач это ровно то, что нужно — гибко, переносимо, снимки состояния делаются штатными средствами.

Проброс физического диска (device passthrough, иногда через virtio-blk в режиме прямого доступа к /dev/sdX, либо через SCSI/NVMe passthrough) — это другое: вы отдаёте гостевой ОС не файл, а конкретный блочный девайс хоста целиком, со всеми его особенностями. Гость видит настоящий диск с его реальной моделью, серийным номером, поддержкой команд ATA/SCSI напрямую, а не через прослойку эмуляции.

Ключевое отличие от GPU passthrough: диск — гораздо более простое устройство с точки зрения передачи. У видеокарты десятки мегабайт MMIO-пространства, сложная модель прерываний, зависимость от группировки IOMMU с другими устройствами на той же шине. У диска, подключённого через SATA/SAS-контроллер или отдельный NVMe-накопитель, интерфейс взаимодействия узкий и предсказуемый — это одна из причин, почему проброс диска работает стабильнее и с гораздо меньшим набором нюансов, чем проброс GPU.

Когда физический диск реально нужен внутри VM

Разница с виртуальным диском не абстрактная — есть конкретные ситуации, где без прямого доступа к устройству не обойтись.

Файловое хранилище / NAS-функциональность внутри VM. Если вы поднимаете внутри виртуальной машины полноценный NAS (например, TrueNAS, OpenMediaVault или самодельный ZFS-пул), файловая система хранилища должна видеть настоящие физические диски, а не файлы поверх файловой системы хоста. Двойная прослойка (ZFS поверх qcow2 поверх ФС хоста) не просто избыточна — она ломает саму идею ZFS, которая рассчитывает на прямой контроль над физическим носителем: контрольные суммы, самостоятельное управление кэшем записи, работу с реальной геометрией диска. Для такого сценария диски пробрасываются в VM целиком, и NAS-система внутри работает с ними так, как будто она установлена на голом железе.

SMART-мониторинг диска изнутри гостя. Если вам нужно, чтобы гостевая ОС сама читала атрибуты SMART (температура, количество Reallocated Sectors, Power-On Hours) через smartctl, это требует прямого ATA/SCSI-канала к устройству. Виртуальный диск, эмулированный через virtio-blk, не транслирует SMART-команды — гость просто не увидит эту информацию, потому что для гипервизора это уже не физический диск, а файл. При пробросе физического устройства smartctl -a /dev/sdX внутри VM отработает так же, как на реальном сервере.

Управление RAID-контроллером изнутри VM. Если у вас есть аппаратный RAID-контроллер (например, LSI/Broadcom MegaRAID) и вы хотите, чтобы утилиты управления массивом (storcli, megacli, вендорские CLI) работали именно внутри виртуальной машины — целиком пробрасывается сам контроллер как PCI-устройство (это уже классический PCI passthrough, тот же механизм, что используется для GPU, но контроллер — устройство куда менее требовательное к группировке IOMMU). Гость получает полный доступ к железу и может опрашивать состояние дисков, пересобирать массив, менять уровень RAID — то есть делать всё то же, что при физическом доступе к серверу.

Во всех трёх случаях объединяющий фактор один: гостевой системе нужны не просто "какие-то блоки данных", а реальная семантика физического устройства — команды, атрибуты, поведение контроллера. Виртуальный диск этого не даёт в принципе, каким бы быстрым ни было хранилище хоста.

Проброс USB: сценарии из жизни

С USB история другая — это устройства, которые физически должны "принадлежать" одной конкретной виртуальной машине, потому что их идентичность как объекта важна для работы ПО или протокола.

Аппаратный ключ лицензирования (донгл). Многие профессиональные пакеты (САПР, инженерное ПО, специализированные бухгалтерские и производственные системы) до сих пор используют USB-донглы для проверки лицензии. Драйвер лицензирования на хосте эти донглы просто не увидит правильно эмулированными — программе внутри VM нужен именно физический USB-девайс с его VID/PID и внутренней логикой. Без проброса такого ключа лицензионное ПО в виртуалке просто не запустится или перейдёт в демо-режим.

USB-модем/донгл сотовой связи. Если сервер использует мобильный интернет как основной или резервный канал (частая ситуация для удалённых площадок или тестовых стендов), USB-модем 4G/5G нужно отдать конкретной VM, которая будет им управлять — поднимать PPP-соединение, слать AT-команды, следить за балансом через USSD. Эмулировать сетевую карту тут бессмысленно: модем — это не Ethernet-адаптер, а сложное составное USB-устройство с собственным протоколом управления.

Специализированное измерительное оборудование с USB-интерфейсом. Осциллографы, анализаторы спектра, лабораторные источники питания, промышленные контроллеры — всё это часто управляется по USB через вендорские SDK или LabVIEW/национал-инструментовские драйверы. Если вы держите систему сбора данных или испытательный стенд внутри виртуальной машины (например, для изоляции от остальной инфраструктуры или для снятия снапшота состояния перед серией измерений), прибор пробрасывается напрямую — иначе драйвер производителя просто не найдёт устройство.

Физический ключ безопасности. USB-токены и аппаратные ключи (для двухфакторной аутентификации, подписи документов, доступа к криптографическим операциям) должны быть видны гостевой ОС как реальное устройство с уникальным серийным номером — сервис проверки подлинности на это полагается. Проброс такого ключа в конкретную VM — стандартная практика для серверов, где разворачивается изолированное рабочее место с доступом к чувствительным операциям.

Общая черта всех четырёх сценариев: устройству важна его физическая идентичность — VID/PID, серийный номер, внутренний протокол. Программный аналог здесь либо не существует, либо не признаётся тем ПО, ради которого всё затевается.

Как это устроено технически — и почему тут проще, чем с GPU

Здесь стоит явно развести два механизма, которые часто путают.

Полный PCI/IOMMU passthrough. Это тот же принцип, что и при пробросе видеокарты: устройство (например, отдельный NVMe-накопитель на своей PCIe-линии или USB-контроллер целиком) отвязывается от драйвера хоста через vfio-pci и передаётся гостю как обособленное PCI-устройство. Такой подход нужен, если вы хотите отдать VM весь физический USB-контроллер (то есть все порты, которые к нему подключены, сразу) или отдельный NVMe-диск на PCIe. Требования к группировке IOMMU здесь остаются, но набор устройств на затронутой шине обычно куда меньше и предсказуемее, чем у видеокарты с её сопутствующим аудио-контроллером и десятками BAR-регионов.

Точечная эмуляция конкретного устройства через QEMU/libvirt — и это самый частый путь для USB, и именно то, что делает задачу принципиально проще GPU-проброса. QEMU умеет пробрасывать конкретное USB-устройство по его идентификатору (vendor ID/product ID) или по пути на шине хоста, не трогая остальной USB-контроллер и не требуя полного PCI passthrough. В libvirt это описывается блоком hostdev в XML-конфигурации домена с типом usb, где указывается <vendor id=.../><product id=.../> (либо адрес по bus/device). При использовании virt-manager то же самое делается в пару кликов через диалог "Add Hardware → USB Host Device" — интерфейс сам подставляет список подключённых к хосту USB-устройств.

Практическая разница с GPU-пробросом:

• IOMMU-группировка — для точечного USB passthrough через hostdev в большинстве случаев не требуется вообще: QEMU перехватывает трафик конкретного устройства на уровне USB-протокола, а не физической шины PCI.
• BIOS/UEFI-настройки — включение VT-d/AMD-Vi желательно в принципе для виртуализации, но жёсткой обязательности и "танцев с бубном" вокруг ACS-патчей, как для GPU, здесь обычно нет.
• Драйверные конфликты на хосте — для GPU нужно заранее убедиться, что видеокарта не подхвачена драйвером хоста (blacklist модуля, ранняя привязка к vfio-pci). Для точечного USB-устройства этого почти никогда не требуется — libvirt/QEMU сами договариваются с ядром хоста об отвязке интерфейса на момент старта VM.
• Hotplug — USB-устройство можно подключить и отключить от уже работающей VM командой virsh attach-device/virsh detach-device без перезагрузки гостя. Для GPU это либо невозможно, либо требует отдельной поддержки со стороны гостевой ОС.

Отдельно стоит SPICE USB redirection — ещё более лёгкий вариант, когда VM работает через графическую консоль (virt-viewer/SPICE-клиент): устройство подключается "на лету" прямо из клиента просмотра, без правки конфигурации домена. Удобно для разовых подключений (воткнуть токен на пять минут), но не годится, если устройство должно быть доступно VM постоянно и с автозапуска.

Точный синтаксис команд virsh nodedev-list и атрибутов XML здесь сознательно не приводим — он меняется между версиями libvirt/QEMU, и его удобнее смотреть в документации к вашей конкретной версии гипервизора. Концепция (точечный проброс по VID/PID против полного PCI passthrough) при этом не меняется уже много лет.

Проброс диска через libvirt: практический ориентир

Для физического диска типичный путь — не через /dev/sdX напрямую (эти имена нестабильны и могут поменяться после перезагрузки хоста при добавлении/удалении других накопителей), а через постоянный идентификатор:

ls -l /dev/disk/by-id/

В конфигурации домена диск описывается как disk с типом block, указывающий на путь /dev/disk/by-id/ata-... или /dev/disk/by-id/nvme-... — так гость всегда получает именно тот физический накопитель, который вы имели в виду, а не тот, что случайно оказался на месте /dev/sdb после очередной перезагрузки. Это простое правило снимает большую часть проблем, с которыми сталкиваются при пробросе дисков на практике.

Для NVMe-накопителей на отдельной PCIe-линии применим и полный PCI passthrough того же типа, что используется для GPU — но здесь IOMMU-группа обычно состоит из одного устройства, и сложностей с "соседями по группе", характерных для видеокарт на некоторых материнских платах, как правило не возникает.

Когда виртуальный диск на быстром хранилище хоста — лучше, чем проброс

Здесь стоит остановиться отдельно, потому что это самая частая ошибка при выборе решения. Проброс физического диска целиком — это не "более производительный вариант по умолчанию", это компромисс с конкретной ценой:

• диск полностью отбирается у хоста — им нельзя одновременно пользоваться для чего-то ещё, включить в общий RAID хоста или задействовать для снапшотов на уровне гипервизора;
• миграция VM на другой физический сервер (live migration) становится либо невозможной, либо требует ручной пересборки конфигурации на новом хосте с тем же физическим диском;
• бэкап такой VM больше не делается штатными средствами гипервизора (снапшот тома) — приходится настраивать резервное копирование изнутри гостя, как на физическом сервере;
• администрирование усложняется: диск исчезает из обзора хоста (lsblk на хосте его не покажет как доступный для монтирования), что иногда сбивает с толку следующего администратора, который не знает про passthrough-конфигурацию.

Если задача — просто "быстрый диск для базы данных" или "много места под файлы", это почти всегда решается обычным виртуальным диском на быстром NVMe-хранилище хоста: производительность virtio-blk на современном гипервизоре для подавляющего большинства нагрузок неотличима от прямого доступа, а гибкости — на порядок больше (снапшоты, миграция, изменение размера тома на лету). Проброс GPU оправдан, когда нужна конкретная вычислительная мощность карты; проброс диска оправдан, только когда нужна конкретная физическая семантика устройства — SMART, RAID-контроллер, ZFS с прямым доступом к носителю. Если ни один из этих пунктов не про вашу задачу — берите виртуальный диск и не усложняйте.

Полезный практический ориентир: если вы выбираете между KVM и LXC или между Proxmox и голым KVM именно ради простоты проброса устройств — учтите, что оба варианта поддерживают и hostdev для USB, и block passthrough для дисков: выбор платформы здесь определяется скорее удобством управления, чем принципиальной возможностью проброса.

Частые вопросы