Команда qm set 101 --scsi1 /dev/disk/by-id/ata-WDC_WD40EFRX-... завершается ошибкой «не могу открыть устройство» чаще всего по одной причине: диск уже примонтирован на самом хосте Proxmox или занят программным RAID/LVM гипервизора. Проброс физического диска в виртуальную машину — рабочая задача при переносе NAS в виртуалку, подключении диска с данными к Windows-гостю или организации прямого доступа к массиву, и первым делом нужно проверить, свободен ли диск на уровне хоста.
В этой статье разберём три рабочих способа проброса: через virtio-blk/scsi по ID диска, через PCI passthrough всего контроллера (HBA или SATA) и через монтирование раздела в LXC-контейнер. Каждый метод имеет свои ограничения по SMART, производительности и миграции ВМ — выбор зависит от того, что важнее: простота или полный контроль гостевой системы над накопителем.
Когда нужен проброс диска, а когда — обычный виртуальный диск
Прежде чем настраивать passthrough, стоит ответить себе на вопрос: действительно ли нужен прямой доступ к железу? Обычный виртуальный диск (qcow2, raw или zvol) покрывает большинство сценариев и даёт снапшоты, тонкое выделение места и живую миграцию. Проброс оправдан в ограниченном числе случаев.
- 💾 Диск уже содержит данные (например, с NAS на TrueNAS или массив ZFS), которые нельзя потерять или перенести.
- 📊 Гостевой системе нужен прямой доступ к SMART для мониторинга здоровья накопителя.
- ⚡ Требуется максимальная производительность без накладных расходов файловой системы хоста.
- 🔧 Виртуальная машина управляет RAID-контроллером или HBA напрямую (классический сценарий для виртуального NAS).
Обратная сторона: при пробросе целого диска теряются снапшоты этого тома, а при пробросе контроллера — живая миграция ВМ между узлами кластера становится невозможной. Это осознанный компромисс, и его нужно принимать до начала настройки.
Подготовка: определяем диск и проверяем, что он свободен
Начните с идентификации накопителя. Использовать имена вида /dev/sdb для проброса нельзя — они могут измениться после перезагрузки или добавления нового диска. Правильный путь — стабильный идентификатор из каталога /dev/disk/by-id/:
ls -l /dev/disk/by-id/ | grep -v partВ выводе найдите строку вида ata-WDC_WD40EFRX-68N32N0_WD-WCC7K... или nvme-Samsung_SSD_970_EVO_... — это и есть стабильное имя, привязанное к серийному номеру устройства. Оно не изменится при перестановке диска в другой порт.
Далее убедитесь, что диск не используется хостом. Проверьте вывод команд lsblk и mount | grep sdX: если разделы диска примонтированы или входят в пул ZFS/LVM гипервизора, проброс приведёт к конфликту и риску повреждения данных. Размонтируйте разделы и уберите их из /etc/fstab, если они там прописаны.
⚠️ Внимание: никогда не пробрасывайте в ВМ диск, на котором установлен сам Proxmox или который входит в пул хранения хоста (pve/data, rpool). Это гарантированно разрушит метаданные хранилища и приведёт к потере всех виртуальных машин на нём.
Способ 1: проброс отдельного диска через qm set
Самый простой и популярный метод — проброс блочного устройства через команду qm set. Диск подключается к ВМ как виртуальное устройство SCSI, VirtIO или SATA, но чтение и запись идут напрямую на физический накопитель, минуя файловую систему хоста. Выполняется одной командой на хосте:
qm set 101 --scsi1 /dev/disk/by-id/ata-WDC_WD40EFRX-68N32N0_WD-WCC7KXXXXXXЗдесь 101 — ID виртуальной машины, а --scsi1 — тип и номер порта. Доступны варианты --scsiN, --virtioN, --sataN и --ideN. Для Linux-гостей оптимален SCSI с включённым discard=on (проброс TRIM), для Windows без установленных драйверов VirtIO проще начать с SATA. Пример с дополнительными параметрами:
qm set 101 --scsi1 /dev/disk/by-id/ata-XXX,discard=on,ssd=1☑️ Проверка перед пробросом диска
После выполнения команды запустите ВМ и проверьте внутри гостя появление диска: в Linux — через lsblk, в Windows — через «Управление дисками». Если диск не виден, проверьте, не занят ли порт scsi1 другим устройством, и загляните в конфигурацию ВМ: cat /etc/pve/qemu-server/101.conf.
Способ 2: PCI passthrough всего контроллера
Если виртуальной машине нужен полный контроль над дисками — включая SMART, низкоуровневое управление и создание собственного RAID — пробрасывается не диск, а целый SATA- или HBA-контроллер по шине PCI. Это стандартный подход для виртуальных NAS на TrueNAS: гостевая система видит накопители как «родные» и управляет ими напрямую.
Для этого способа обязательны аппаратные условия: поддержка IOMMU процессором и материнской платой (Intel VT-d или AMD-Vi) и её включение в BIOS/UEFI. Затем нужно активировать IOMMU в загрузчике хоста, добавив параметр ядра. Для систем на GRUB с Intel-процессором правится /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"Для AMD параметр — amd_iommu=on. После правки выполните update-grub (или proxmox-boot-tool refresh для систем на systemd-boot) и перезагрузите хост. Проверка, что IOMMU заработал: команда dmesg | grep -e DMAR -e IOMMU должна показать строки инициализации. Затем найдите контроллер через lspci и добавьте его в ВМ через веб-интерфейс: ВМ → Hardware → Add → PCI Device.
⚠️ Внимание: проброс встроенного SATA-контроллера отдаст виртуальной машине ВСЕ диски, висящие на этом контроллере, включая системный диск хоста, если он подключён туда же. Перед настройкой проверьте через lspci и lsblk, какие устройства принадлежат выбранному PCI-устройству, и убедитесь, что оно находится в отдельной IOMMU-группе.
Способ 3: проброс в LXC-контейнер
Для контейнеров LXC механика другая: там нет эмуляции блочных устройств, поэтому диск либо монтируется на хосте и пробрасывается как каталог (bind mount), либо — в привилегированных контейнерах — пробрасывается само устройство через lxc.cgroup2.devices.allow и mknod. Первый вариант проще и безопаснее.
Примонтируйте раздел диска на хосте, например в /mnt/data, и добавьте в конфигурацию контейнера /etc/pve/lxc/100.conf строку вида:
mp0: /mnt/data,mp=/mnt/dataУчтите важный нюанс: в непривилегированных контейнерах действует маппинг UID/GID, поэтому файлы, созданные внутри контейнера, на хосте будут принадлежать смещённым идентификаторам. Для общего доступа обычно настраивают группу с соответствующими правами на хосте. Прямой проброс устройства в контейнер технически возможен, но снижает изоляцию и рекомендуется только для доверенных привилегированных контейнеров.
Сравнение способов проброса
| Критерий | qm set (по ID) | PCI passthrough | LXC bind mount |
|---|---|---|---|
| Сложность настройки | Низкая, одна команда | Высокая, нужен IOMMU | Средняя |
| Доступ к SMART в госте | Частичный/нет | Полный | Нет |
| Снапшоты диска | Не поддерживаются | Не поддерживаются | Зависит от ФС хоста |
| Живая миграция ВМ | Невозможна | Невозможна | Невозможна |
| Типичный сценарий | Диск с данными в ВМ | Виртуальный NAS (TrueNAS) | Медиасервер, общие файлы |
Живая миграция невозможна ни в одном из вариантов, потому что диск физически привязан к конкретному серверу. Это фундаментальное ограничение любого проброса локального оборудования, а не недостаток конкретного метода.
Почему при пробросе через qm set не работает SMART в гостевой системе
Команды SMART (ATA pass-through) эмулируются QEMU лишь частично и зависят от типа шины и прошивки диска. Для надёжного мониторинга запускайте smartctl на хосте Proxmox — он видит физический накопитель напрямую. Либо используйте PCI passthrough контроллера, при котором гость получает настоящий доступ к устройству.
Типичные ошибки и их решение
Самая частая проблема — ВМ не стартует после добавления диска с ошибкой доступа к устройству. Причины обычно три: диск примонтирован на хосте, указано имя /dev/sdX вместо стабильного by-id, либо порт (scsi1 и т.п.) уже занят. Проверяйте конфиг ВМ и вывод lsblk на хосте.
Вторая группа проблем касается PCI passthrough: контроллер не появляется в госте или хост теряет диски после перезагрузки. Здесь проверяйте, что IOMMU включён и в BIOS, и в параметрах ядра, что устройство находится в собственной IOMMU-группе (команда find /sys/kernel/iommu_groups/ -type l покажет группировку), и что нужные модули vfio загружены. Точные требования зависят от версии Proxmox и оборудования — сверяйтесь с официальной документацией Proxmox VE по PCI passthrough.
⚠️ Внимание: после проброса диска в ВМ хост Proxmox больше не должен обращаться к этому накопителю. Одновременная запись с хоста и из гостевой системы разрушит файловую систему — уберите диск из всех автомонтирований и пулов хранения хоста.
Часто задаваемые вопросы
Можно ли пробросить в ВМ только один раздел диска, а не весь накопитель?
Да, команда qm set принимает и разделы — например, /dev/disk/by-id/ata-XXX-part1. Однако гостевая система увидит его как целый диск без таблицы разделов, что подходит не для всех сценариев. Чаще пробрасывают накопитель целиком.
Будет ли работать TRIM для SSD при пробросе через qm set?
Да, если добавить параметр discard=on при подключении диска и использовать шину SCSI или VirtIO. Гостевая ОС также должна поддерживать и отправлять команды TRIM.
Почему после перезагрузки хоста ВМ подхватила чужой диск?
Почти наверняка в конфигурации использовано имя вида /dev/sdb, которое переназначилось. Замените его на стабильный идентификатор из /dev/disk/by-id/, привязанный к серийному номеру накопителя.
Можно ли пробросить диск в ВМ через веб-интерфейс Proxmox?
Проброс отдельного диска по by-id выполняется только из командной строки хоста через qm set — в веб-интерфейсе такой опции нет. А вот PCI-устройства (контроллеры) добавляются через графический интерфейс: Hardware → Add → PCI Device.
Теряются ли данные на диске при пробросе в виртуальную машину?
Сама операция проброса данные не удаляет — диск подключается «как есть». Риск появляется только при ошибочных действиях: инициализации диска в гостевой ОС, одновременном монтировании на хосте или случайном форматировании. Перед первым подключением сделайте резервную копию важных данных.