Когда GPU "забывает" кто он такой после перезагрузки
Вы настроили passthrough RTX Pro в Proxmox, всё работает. Запускаете CUDA-приложения, тестируете llama.cpp - карта отвечает. Перезагружаете виртуальную машину для обновления ядра или просто потому что так положено. И тут начинается цирк. Команда nvidia-smi возвращает "NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver". Или вообще ничего не возвращает. Или показывает карту, но CUDA-приложения падают с ошибками. Знакомо? Добро пожаловать в клуб.
Почему так происходит? Механика проблемы
Когда вы настраиваете passthrough впервые, вы проходите через стандартный гайд: включаете IOMMU, blacklist-ите драйвер, добавляете vfio-pci в initramfs. При первой загрузке VM Proxmox корректно перехватывает GPU и передаёт его гостевой системе. Но после перезагрузки виртуальной машины происходит тонкий сбой в последовательности инициализации устройств.
Основных причин три, и они часто работают вместе:
- Неправильный порядок загрузки модулей ядра - vfio-pci должен загрузиться ДО nvidia драйвера хоста
- Проблемы с reset domain - RTX Pro после использования в VM не полностью сбрасывается
- Конфликт с управлением питанием PCIe - карта "засыпает" и не просыпается при следующей загрузке
Диагностика: с чего начинать искать проблему
Прежде чем что-то исправлять, нужно понять, где именно сломалось. Запускаем диагностику с хостовой системы (Proxmox).
1 Проверяем, кто владеет GPU ДО запуска VM
После перезагрузки хоста, но ДО запуска виртуальной машины, выполняем команду lspci -nnk для своей карты. Ищем строки напротив устройства:
| Что видим | Что это значит | Действие |
|---|---|---|
| Kernel driver in use: vfio-pci | Всё ок, GPU захвачен vfio | Проблема в гостевой системе |
| Kernel driver in use: nvidia | Драйвер хоста перехватил карту | Нужно исправлять blacklist и порядок модулей |
| Kernel driver in use: nouveau | Сработал open-source драйвер | Срочно blacklist nouveau |
| Kernel driver in use: (none) | Карта не инициализирована | Проблема с vfio-pci или PCIe |
2 Проверяем dmesg после запуска VM
Запускаем виртуальную машину и сразу смотрим dmesg -w на хосте. Ищем ключевые слова: vfio, reset, PCI, ACS. Самые частые ошибки:
- "vfio-pci 0000:01:00.0: cannot reset device" - карта не сбрасывается
- "No IOMMU groups found" - забыли включить IOMMU в BIOS/UEFI
- "ACS P2P upstream forwarding" - проблема с изоляцией PCIe
3 Проверяем гостевую систему
Внутри виртуальной машины смотрим lspci -v. Должны видеть NVIDIA Corporation device с правильным ID. Если карта видна, но драйвер не работает - проверьте, совпадает ли PCIe ID в конфигурации Proxmox с реальным ID карты.
Решение: пошаговый план на каждый случай
Теперь, когда знаем где искать, исправляем. Начнём с самых частых проблем.
Случай 1: Драйвер хоста перехватывает карту
Самая распространённая ситуация. После перезагрузки хоста nvidia драйвер успевает загрузиться раньше vfio-pci. Исправляем:
Шаг 1: Убеждаемся в правильном blacklist
В файле /etc/modprobe.d/blacklist.conf должны быть строки:
blacklist nouveau
blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
blacklist nvidia-uvm
Но этого недостаточно. Blacklist работает только для автоматической загрузки модулей. Если какой-то другой модуль или система инициализации загружает nvidia драйвер - blacklist бессилен.
Шаг 2: Принудительно загружаем vfio-pci первым
В /etc/modprobe.d/vfio.conf добавляем привязку конкретного устройства к vfio-pci. Берём PCIe ID своей карты (например, 10de:1b38) и добавляем:
options vfio-pci ids=10de:1b38 disable_vga=1
Ключевой момент: в /etc/modules добавляем vfio-pci ПЕРВОЙ строкой, даже перед vfio и vfio_iommu_type1. Порядок имеет значение.
Шаг 3: Обновляем initramfs и перезагружаем хост
update-initramfs -u -k all и ребут. После перезагрузки проверяем lspci -nnk. Должно быть Kernel driver in use: vfio-pci.
Случай 2: Проблема с reset domain (самая противная)
Вы видите в dmesg ошибку сброса устройства. RTX Pro после работы в виртуальной машине не хочет возвращаться в исходное состояние. Решение - принудительный сброс через sysfs.
Шаг 1: Проверяем, поддерживает ли карта Function Level Reset (FLR)
Смотрим capabilities карты: lspci -vvv -s 01:00.0 | grep -A5 -i reset. Если видите FLR - это хорошо. Но часто на RTX Pro FLR работает криво.
Шаг 2: Добавляем параметр ядра для vfio-pci
В том же /etc/modprobe.d/vfio.conf добавляем:
options vfio-pci ids=10de:1b38 disable_vga=1 reset_method=flr
Если не помогает, пробуем reset_method=device_specific или даже reset_method=bus (осторожно, может затронуть другие устройства).
Шаг 3: Ядерный метод - ручной сброс через /sys
Создаём скрипт /usr/local/bin/reset-gpu.sh:
#!/bin/bash
DEVICE="0000:01:00.0"
echo 1 > /sys/bus/pci/devices/$DEVICE/remove
sleep 2
echo 1 > /sys/bus/pci/rescan
И добавляем его выполнение ПЕРЕД запуском виртуальной машины. В Proxmox это можно сделать через hookscript или просто вручную перед запуском VM.
Случай 3: Конфликт с управлением питанием PCIe
Карта уходит в глубокий сон (ASPM) и не просыпается. Особенно актуально для серверных материнских плат, которые агрессивно экономят энергию.
Решение: Отключаем ASPM на уровне ядра
В загрузочных параметрах ядра Proxmox (в /etc/default/grub) добавляем:
pcie_aspm=off
Или, если хотите более тонкое управление, можно отключить ASPM только для конкретного устройства через sysfs после загрузки.
Проверка решения: как убедиться, что всё работает
После применения всех исправлений проводим полный цикл тестирования:
- Перезагружаем хост Proxmox
- Проверяем lspci -nnk | grep -A5 "NVIDIA" - драйвер должен быть vfio-pci
- Запускаем виртуальную машину
- Внутри VM проверяем nvidia-smi - должен показывать карту
- Тестируем CUDA приложение (можно простым nvidia-smi -q)
- Останавливаем VM
- Запускаем VM снова - всё должно работать без ручного вмешательства
Если на шаге 7 снова возникает проблема - возвращаемся к диагностике. Скорее всего, у вас комбинированная проблема из нескольких описанных случаев.
Особенности для LLM и ИИ-нагрузок
Когда вы используете passthrough для запуска llama.cpp или других LLM-инструментов, есть дополнительные нюансы:
- Память BAR - RTX Pro имеет большой BAR (Base Address Register). Убедитесь, что в конфигурации VM достаточно PCIe памяти. Добавьте в конфиг VM: args: -cpu 'host,+kvm-pv-eoi,+kvm-pv-ipi,+kvm-asyncpf,+kvm-steal-time'
- NUMA привязка - Если у вас несколько CPU сокетов, привязывайте GPU и vCPU к одному NUMA узлу. Иначе производительность упадёт в разы.
- Температурный мониторинг - В виртуальной машине nvidia-smi может не показывать температуру. Это нормально для passthrough. Мониторьте температуру с хоста.
Что делать, если ничего не помогает
Бывает. Особенно со свежими версиями RTX Pro и старыми ядрами Proxmox. Экстренные меры:
Обновление ядра Proxmox
Стандартное ядро Proxmox (5.15) иногда плохо дружит с новым железом. Установите ядро 6.2 или новее через pve-kernel-6.2. Проверьте, поддерживает ли ваша версия Proxmox новое ядро.
Проверка BIOS/UEFI настроек
Зайдите в BIOS и проверьте:
- IOMMU включён (AMD-Vi для AMD, VT-d для Intel)
- Above 4G Decoding включён
- SR-IOV отключён (если не используете)
- PCIe ARI Support отключён
Альтернатива: LXC с GPU
Если passthrough категорически не работает, рассмотрите запуск через LXC-контейнер. Для LLM это часто проще и стабильнее, хоть и с небольшим overhead.
Профилактика будущих проблем
Чтобы не сталкиваться с этой проблемой после каждого обновления:
- Держите резервную копию рабочих конфигов /etc/modprobe.d/
- После обновления ядра всегда запускайте update-initramfs
- Используйте мониторинг - скрипт, который проверяет состояние GPU перед запуском VM
- Рассмотрите использование GPU partitioning (vGPU) если ваша карта поддерживает
Самая частая ошибка, которую я вижу у людей - они пытаются исправить симптомы, а не причину. Видят, что nvidia-smi не работает в VM, и начинают переустанавливать драйверы в гостевой системе. А проблема почти всегда на стороне хоста. Запомните: если passthrough работал, а после перезагрузки перестал - 99% что сломалось на уровне Proxmox, а не внутри виртуальной машины.
И последнее: если у вас несколько GPU и вы планируете масштабировать ИИ-инфраструктуру, изучите тему NVLink. Для двух карт это может дать существенный прирост, как описано в статье про NVLink для RTX 3090. Хотя с passthrough NVLink работает не всегда стабильно - это уже тема для отдельного разговора.
