Supermicro для ESXi и Proxmox: как проверить совместимость до покупки?
Совместимость Supermicro с ESXi или Proxmox проверяют по полной конфигурации: модель системы, версия гипервизора, CPU, сетевые адаптеры, контроллеры хранения, драйверы и прошивки. Успешная загрузка установщика подтверждает только начало проверки. Она не доказывает поддержку всех компонентов, устойчивую работу ВМ и возможность получить необходимую помощь при сбое.
До покупки нужен воспроизводимый комплект доказательств: точная спецификация, подходящие записи совместимости, условия поддержки и пилот с нужными функциями. Такая проверка полезнее общего обещания «Supermicro работает с VMware» или «Linux запускается на любом сервере».
Чем отличаются «устанавливается», «сертифицирован» и «поддерживается»?
Эти состояния дают разные уровни уверенности. «Устанавливается» означает, что ОС прошла определённую проверку запуска на оборудовании. Сертификация — результат установленной разработчиком процедуры для конкретного продукта. Поддержка — обязательства сторон при обращении, которые могут зависеть от версии, сборки и договора.
В матрице Supermicro есть уровни OS Installed — базовая проверка установки, OS Certified — сертификация тестами разработчика ОС, и Validated — сочетание этих проверок. Их нельзя превращать в одно обещание «всё поддерживается». Отдельно учитывают путь хранения, с которого выполнялась проверка.
| Доказательство | Что позволяет заключить | Чего не подтверждает |
|---|---|---|
| Установщик завершил работу | Базовая установка с выбранными устройствами прошла | Официальную поддержку и стабильность всех рабочих сценариев |
| Система есть в матрице для версии ОС | Есть запись с указанным уровнем и условиями | Любую замену NIC/HBA или произвольную новую версию |
| Компонент есть в списке совместимости | Подтверждена указанная комбинация устройства, драйвера и прошивки | Сертификацию всей сборки |
| Пилот прошёл рабочие тесты | Проверены перечисленные сценарии и параметры | Отсутствие всех будущих ошибок и новую официальную сертификацию |
| Есть договор поддержки | Определены обязанности по включённым продуктам | Поддержку исключённых версий и неоговорённых компонентов |
Отсутствие записи не доказывает, что оборудование обязательно не заработает. Но если закупка требует формального подтверждения, отсутствие записи нельзя заменять рассказом о похожем сервере. Нужно получить подходящее подтверждение или изменить состав решения.
Что собрать в спецификацию до проверки?
- Система: полный SKU сервера, плата и ревизия, если она существенна для подтверждения.
- CPU: точная модель и семейство, архитектура и доступные функции виртуализации.
- ПО: ESXi или Proxmox VE с версией, обновлением и сборкой; для Proxmox — также ядро используемого образа.
- Сеть: модель каждого NIC, PCI-идентификаторы, интерфейсы, требуемая скорость и используемые драйверы.
- Хранение: HBA/RAID, режим контроллера, диски, boot device, прошивки и схема подключения.
- Платформа: BIOS, BMC, настройки загрузки, IOMMU и необходимые параметры.
- Дополнительные функции: passthrough, SR-IOV, миграция, HA, внешнее хранилище и резервное копирование.
Коммерческий SKU barebone не всегда описывает установленную PCIe-карту. Поэтому «сервер есть в HCL» и «все добавленные устройства подходят» — две отдельные проверки. Замена компонента на «аналог» после согласования также требует повторной сверки.
Как проверить Supermicro для VMware ESXi?
Проверка начинается с точной версии ESXi, которую предстоит использовать. Затем находят систему в Broadcom Compatibility Guide и сверяют применимые записи совместимости производителя. После этого отдельно проверяют I/O-устройства, накопители и другие компоненты, для которых есть требования выбранной архитектуры.
- Зафиксируйте целевую версию: название основной ветки не заменяет обновление и сборку проекта.
- Найдите точную систему: учитывайте CPU и ограничения записи, а не только похожий номер модели.
- Проверьте NIC и storage: модель, идентификаторы PCI, подходящий драйвер и firmware.
- Сверьте рекомендуемые пакеты: BIOS и прошивки должны соответствовать подтверждённому сочетанию, а не просто быть самыми новыми.
- Проверьте дополнительные продукты: для vSAN, passthrough и других функций могут понадобиться отдельные условия.
- Сохраните результат: запись, дату, версию и ограничения вместе с BOM заказа.
Для адаптеров полезны Vendor ID, Device ID, Sub-Vendor ID и Sub-Device ID. Одно маркетинговое имя семейства может охватывать несколько устройств. Сверяйте совпадение всех необходимых идентификаторов и проверяемой комбинации драйвера и прошивки.
Не обновляйте firmware автоматически «до последней» после пилота. Подтверждённая комбинация может требовать другой версии. Если конфигурация меняется, результат прежней проверки перестаёт полностью описывать новую сборку.
Как различать запись системы и запись устройства в Compatibility Guide?
Проверка системы отвечает за аппаратную платформу в условиях записи. Проверка I/O-устройства отвечает за конкретный адаптер и сочетание его драйвера с firmware. Успех первой не отменяет вторую, особенно если NIC или HBA добавлены интегратором. Устройство похожего семейства также может иметь другую идентификацию и ограничения.
Сохраните не только название результата, но и его параметры: модель, применимый релиз, CPU при наличии такого условия, идентификаторы и допустимую связку версий. Затем сопоставьте их с BOM поставки. Если предложение содержит «NIC 10 Гбит/с, модель уточняется», полноценная проверка ещё не выполнена. Скорость интерфейса не определяет драйверную совместимость.
Отдельные продукты могут требовать собственных записей и профилей. Проверка базового ESXi не подтверждает всю конфигурацию vSAN или иной специализированной функции. Если она обязательна, укажите её до выбора дисков и контроллеров. Обсуждение только версии гипервизора оставляет этот риск незамеченным.
Что делать, если подходящей записи нет?
Разделите формальное требование и техническую возможность. Для среды, где требуется подтверждённая поддержка, запросите применимое письменное подтверждение или измените состав. Для тестового стенда можно исследовать работу устройства, понимая ограничения. Удачная установка не превращает непроверенную производственную конфигурацию в сертифицированную.
Не компенсируйте отсутствие записи отключением нужной функции. Если для запуска пришлось убрать SR-IOV или заменить защищённый путь хранения упрощённым, результат уже относится к другому набору требований. Изменение может быть допустимым, но его нужно согласовать и отразить в спецификации.
Нужно ли проверять VMware по плате или по серверу?
Для комплектной серверной системы основная проверка относится к системе и её конфигурации. Материнская плата внутри может помогать идентифицировать платформу, но запись по одной плате не обязательно подтверждает самосборный сервер с другими NIC, HBA и схемой хранения.
Для сборки на отдельной плате особенно важно получить полный список компонентов и границу ответственности интегратора. Например, Supermicro MBD-H12SSL-I-B — аппаратная основа, а не универсальный сертификат ESXi или Proxmox для любой сборки. Совместимость проверяют вместе с CPU, картами, загрузочным устройством и ПО.
Запись о Windows Server, Ubuntu или другой ОС не превращается в подтверждение ESXi. Матрицы разных продуктов решают разные задачи, даже если используются те же процессор и плата.
Как проверить Supermicro для Proxmox VE?
Для Proxmox нужна пригодность оборудования к выбранному релизу и его Linux-ядру, а также к используемой архитектуре хранения и виртуализации. Отсутствие слова Proxmox в общей таблице ОС не является доказательством невозможности установки. Но и установленный Debian на похожей системе не даёт автоматической гарантии для полного набора функций Proxmox VE.
Проверьте требования CPU, драйверы NIC/HBA в используемом ядре, загрузку, видимость накопителей, мониторинг и состояние поддержки. Для полной x86-виртуализации нужны подходящие функции Intel VT или AMD-V. Для PCI passthrough дополнительно необходимы VT-d или AMD-Vi/IOMMU и пригодная схема групп устройств.
Хранилище выбирают в соответствии с выбранным backend. ZFS и Ceph требуют подходящего доступа к физическим дискам; скрывать их за аппаратным RAID как за единым томом — другая архитектура. Для LVM на аппаратном RAID требования отличаются. Нельзя утверждать, что один режим контроллера оптимален для всех вариантов.
Не используйте минимальные ресурсы тестовой установки как готовую конфигурацию production. Само наличие веб-интерфейса не проверяет запас памяти, дисковую задержку и восстановление. Эти величины определяются нагрузкой, а не названием гипервизора.
Подписка на Proxmox и аппаратная гарантия также не превращаются в один договор. Уточните, кто работает с драйверной проблемой, кто меняет контроллер и какие условия предъявляются к версии ПО. Если интегратор обещает поддержку сборки, её объём нужно записать явно.
Как собрать инвентаризацию ESXi и Proxmox для проверки?
Если есть образец сервера, начните с фактического состава. Названия в коммерческом предложении полезны, но не заменяют идентификаторы устройств и установленные версии. Инвентаризацию сохраняют до изменений, после пилота и при приёмке поставки. Так проще заметить несогласованную замену или обновление.
Примеры команд только для чтения на ESXi
vmware -vl
esxcli hardware pci list
esxcli network nic list
esxcli storage core adapter list
Эти команды помогают получить версию хоста, PCI-устройства, сетевые интерфейсы и адаптеры хранения в поддерживающих их версиях ESXi. Состав доступного вывода проверяют для установленного релиза. Они не меняют настройки, но сами по себе не подтверждают совместимость. Полученные идентификаторы и версии нужно сопоставить с применимыми записями.
Примеры инвентаризации на Proxmox VE
pveversion -v
uname -r
lspci -vnn
lspci -nnk
Здесь фиксируются версии пакетов и ядра, устройства и используемые драйверы. BIOS и firmware адаптеров дополняют из подходящих интерфейсов управления и поддерживаемых средств производителя. Имя модуля Linux не является номером firmware, а имя сетевого интерфейса не заменяет модель NIC.
Используйте разрешённый административный доступ и не публикуйте полный отчёт без проверки содержимого. Для технической сверки обычно нужны версии и устройства, а не пароли и закрытая схема сети. Если действующего хоста пока нет, запросите аналогичный набор у поставщика для тестируемой сборки.
| Поле в отчёте | Пример формата записи | Почему нельзя пропустить |
|---|---|---|
| Гипервизор | Название, релиз, обновление и build | Основная ветка без сборки описывает слишком широкий набор |
| Ядро Proxmox | Полная версия загруженного ядра | Установленный пакет и реально загруженное ядро могут различаться |
| PCI-устройство | Модель, VID/DID и subsystem identifiers | Похожие названия не подтверждают одинаковое устройство |
| Драйвер и firmware | Два отдельных значения для каждого адаптера | Одна версия не описывает всю проверяемую связку |
| Настройки BIOS | Загрузка, виртуализация и обязательные функции | Изменённый режим может повлиять на результат |
| Тестовый сценарий | Нагрузка, длительность, критерий и журнал | Нельзя восстановить смысл записи «тест пройден» |
Почему сетевой адаптер — один из главных пунктов проверки?
Без подходящего драйвера NIC установщик может не дать рабочего подключения, даже если CPU и память полностью распознаны. Но отсутствие проблем при установке ещё не проверяет VLAN, MTU, bonding, пропускную способность и устойчивость соединения после перезагрузки.
Согласуйте требуемые порты, модули, DAC/оптику и коммутатор. Обозначение 10GbE или 25GbE описывает интерфейс, но не совместимость конкретного трансивера и драйвера. Для проекта с несколькими путями отдельно проверьте отключение каждого из них на подготовленном стенде.
SR-IOV требует поддержки адаптера, firmware, BIOS и гипервизора; PCI passthrough требует подходящих IOMMU-групп. Возможность назначить устройство одной ВМ не доказывает, что оно может безопасно использоваться так же в другой конфигурации. Если эти функции обязательны, их включают в пилот, а не оставляют «на потом».
Как проверить диски, HBA, RAID и загрузочное устройство?
Опишите весь путь: накопитель → backplane → кабель → CPU или контроллер → драйвер → хранилище гипервизора. Похожий разъём не подтверждает одинаковый SATA/SAS/NVMe-протокол, а видимый контроллер не гарантирует доступность всех заказанных отсеков.
Отдельно проверьте устройство для ОС гипервизора и массив данных ВМ. Требования к загрузочному носителю, объёму и устойчивости записи зависят от релиза. Исторический совет ставить любую новую систему на USB-флешку нельзя применять без актуальной проверки.
На стенде проверяют видимость дисков, режим контроллера, состояние кэша и наличие защиты, если она нужна. Для системы с прямым доступом к дискам важны корректные идентификаторы и диагностические показатели каждого устройства. Для аппаратного RAID нужен подходящий инструмент мониторинга, чтобы отказ диска не остался незамеченным.
Проектирование разных слоёв хранения подробно разбирает статья о NVMe и SAS для виртуализации. Если оборудование уже куплено, но установщик не видит диски, переходите к диагностике обнаружения устройств; здесь задача — предупредить несовместимость до заказа.
Как проверить не только хост, но и гостевые системы?
Аппаратная совместимость хоста не подтверждает работу каждого гостевого приложения. Для ВМ нужны поддерживаемая гостевая ОС, подходящие виртуальные устройства, драйверы и инструменты интеграции. После перехода с другой среды могут измениться контроллер диска, сетевой адаптер, режим UEFI и способ загрузки.
Перед миграцией выберите несколько представительных ВМ: обычную служебную систему, чувствительную к задержке базу и гостя со специфическим устройством. Проверьте загрузку, сеть, службу времени, резервирование и прикладной результат. Одна пустая тестовая Linux-ВМ не характеризует весь рабочий парк.
Чем обычная ВМ отличается от гостя с passthrough?
При обычной виртуализации гость работает через виртуальные устройства. При PCI passthrough он получает конкретное физическое устройство, что меняет требования к изоляции, драйверам и переносимости. Нужны подходящие IOMMU-группы и проверенная возможность использовать устройство в выбранной ВМ. Наличие AMD-V или Intel VT само по себе не закрывает эти условия.
У группы могут быть связанные функции устройства и элементы шины. Важно, чтобы схема назначения сохраняла требуемую изоляцию и не забирала у хоста необходимый ресурс. Не используйте обходные настройки разделения групп как автоматическое доказательство аппаратной пригодности. Для производственной закупки лучше подтвердить нужную топологию до оплаты.
Проверьте поведение устройства после остановки и повторного запуска гостя, а также после перезагрузки хоста. Успешный первый старт не описывает повторную инициализацию. Для каждого обязательного устройства сохраняют отдельный результат. Миграцию такой ВМ не считают доступной без проверки конкретной поддерживаемой реализации.
Как выбрать CPU-профиль для миграции?
Гостю может быть доступен набор функций физического CPU либо согласованная модель виртуального процессора. Чем точнее профиль повторяет конкретный хост, тем больше внимания требует перемещение на другую платформу. Для разнородного кластера заранее проверяют общий подходящий набор функций и возможность выполнять нужные приложения.
Если новое поколение добавляется к старому, испытайте миграцию в обе стороны для представительных ВМ. Совпадение числа ядер не определяет совместимость инструкций. Профиль нужно выбирать вместе с требованиями приложения, а не только ради удобства перемещения. Отключение нужной приложению возможности способно решить одну проблему и создать другую.
Какие настройки BIOS и firmware нужны для пилота?
Фиксируют режим загрузки UEFI/Legacy, состояние Secure Boot, функции виртуализации, IOMMU, режимы контроллеров и остальные параметры, существенные для проекта. Не все пункты нужно обязательно включать: значение определяется гипервизором и требуемыми функциями.
Secure Boot проверяют вместе с образом и драйверами, а не отключают автоматически при первой ошибке. Необъяснённое обходное действие в пилоте может скрыть проблему, которая появится при обновлении или вводе политики безопасности.
BIOS, BMC, firmware NIC/HBA и пакеты драйверов сохраняют как версионный комплект. Запишите исходные настройки и изменения. Процедуру обновления выполняют отдельно по руководству по BIOS Supermicro, не превращая проверку совместимости в случайное обновление всех компонентов.
Как проверить кластер, миграцию и дополнительные функции?
Совместимость каждого хоста нужна, но недостаточна. Для миграции проверяют доступный гостевым системам CPU-профиль, версии узлов, сеть и хранилище. Разные поколения CPU могут потребовать согласованного набора виртуальных функций; один успешно запущенный гость не доказывает возможность его перемещения.
ВМ с переданным физическим устройством может иметь ограничения миграции. HA также не появляется только от объединения нескольких серверов в интерфейсе: нужны соответствующая конфигурация, доступные данные и достаточные ресурсы после отказа. Расчёт этого запаса относится к планированию CPU/RAM и N+1.
Пилот кластера должен воспроизвести нужные события: плановую миграцию, обслуживание узла, потерю сетевого пути и восстановление ВМ из копии. Отказовые действия выполняют в подготовленной тестовой среде, где они не затронут боевые данные.
Почему проверка обновления важна ещё до закупки?
Сервер покупают на срок, превышающий одну установку. Если подтверждённая конфигурация работает только на старом неподходящем релизе, это существенное ограничение. До заказа проверьте выбранную текущую версию и план поддерживаемого обновления: систему, CPU, адаптеры, firmware, гостевые ОС и обязательные функции.
Для ESXi повторно сверяют записи под целевую версию и связки драйверов. Для Proxmox проверяют релиз, ядро и зависимые пакеты, особенно если используются сторонние модули или специфические устройства. Обновление firmware и обновление гипервизора — разные изменения. Их совместный результат нельзя считать проверенным по отдельным успешным тестам.
Что должно входить в план возврата?
Сохраните конфигурацию, подходящие пакеты и проверенные резервные копии ВМ. Уточните, какие компоненты действительно допускают возврат к прошлой версии. Откат firmware или преобразованного формата хранения может быть ограничен. Обещание «если что, вернём назад» не заменяет проверяемую процедуру.
Для ответственного проекта полезен отдельный тестовый хост или пилотный узел, на котором проверяют обновление до переноса основной нагрузки. Если тест показывает проблему, есть время изменить пакет или компонент. Нельзя считать резервной копией конфигурации гипервизора полную резервную копию данных всех гостей: это разные наборы.
Как принимать замену «на аналог»?
В спецификации укажите параметры, которые требуют пересогласования: NIC/HBA, их идентификаторы, boot device, firmware и существенные настройки. Если поставщик заменил адаптер на более быстрый, это не освобождает от проверки. Новый драйвер, другой трансивер или изменённая поддержка могут повлиять на результат.
Зафиксируйте короткую процедуру: описание замены, сверка применимых записей, повторный тест затронутых функций и обновление BOM. Для серийной партии проверьте, что остальные узлы соответствуют пилоту. Серверы с одинаковым товарным именем не обязательно имеют одинаковые добавленные компоненты.
Какой минимальный приёмочный пилот согласовать?
| Проверка | Критерий | Артефакт результата |
|---|---|---|
| Установка и перезапуск | Загрузка с выбранного устройства без необъяснённых ошибок | Версия образа, сборка, BIOS и карта устройств |
| Сеть | Все требуемые порты, VLAN и пути работают | Драйверы, firmware, параметры и результаты |
| Хранение | Доступны заказанные диски, режимы и диагностика | Модели, контроллеры, пути и журналы |
| Рабочие ВМ | Прикладной сценарий укладывается в согласованные задержки | Нагрузка, длительность, измерения и ошибки |
| Дополнительные функции | Работают обязательные passthrough/SR-IOV/миграция | Список проверенных сочетаний и ограничений |
| Восстановление | Копия возвращает нужную ВМ и данные в заданный срок | Фактическое время, объём и процедура |
| Обновление и поддержка | Есть допустимый план следующего обновления и ответственные | Зафиксированные версии и границы договора |
Длительность подбирают под цикл нагрузки. Несколько минут теста не описывают ночной бэкап и длительное заполнение хранилища. Например, можно согласовать сутки устойчивой смешанной нагрузки и отдельную проверку восстановления; это проектное требование, а не универсальная сертификационная процедура.
Как выбрать содержательные критерии успешного пилота?
Критерий должен связывать действие с результатом. Вместо «сеть работает» — все заказанные порты доступны, нужные VLAN проходят, согласованный путь переключается и после перезапуска настройки сохраняются. Вместо «диски видны» — все отсеки доступны в заданном режиме, диагностика и предупреждения поступают ответственному.
Для производительности укажите входные данные, одновременность и допустимые задержки приложения. Если тесты сравнивают разные объёмы данных или кэш, числа нельзя считать равными условиями. Измеряйте также медленные операции и результат во время резервирования. Поток коротких запросов и длительное последовательное копирование проверяют разные свойства.
Отказовой тест включает не только продолжение работы, но и обнаружение события, уведомление и возврат к штатному состоянию. Иначе система может пережить отключение пути, а администратор не узнать, что резерв больше недоступен. Такие проверки проводят на подготовленном стенде по согласованной процедуре.
Пример последовательности для двухузлового проекта
- Сверить оба узла с подтверждённой BOM и сохранить версии.
- Установить выбранный гипервизор и проверить все устройства каждого хоста.
- Запустить представительные ВМ и проверить приложения и копии.
- Проверить нужную миграцию и плановое обслуживание одного узла.
- На тестовой среде выполнить согласованные проверки сетевого пути и восстановления.
- Повторить проверку после предусмотренного обновления либо зафиксировать его отдельный план.
- Сохранить итог, ограничения и действия при замене компонентов.
Эта последовательность не обещает HA автоматически и не задаёт количество ВМ. Ресурсный запас рассчитывают отдельно, а здесь подтверждают, что выбранные функции совместимы и выполняются на поставляемом оборудовании. Даже хороший пилот оставляет необходимость мониторинга и дальнейшего обслуживания.
Как определить границу поддержки между поставщиками?
Назначьте ответственного за первичный разбор. Аппаратный поставщик может отвечать за замену детали, поддержка гипервизора — за свой продукт, интегратор — за согласованную сборку и настройки. Без такого разделения инцидент легко превращается в пересылку обращений между сторонами.
Уточните доступность необходимых пакетов, лицензий и каналов поддержки для вашей организации. Наличие записи совместимости не гарантирует возможность приобрести все услуги в конкретной поставке. Эти условия подтверждают отдельно и фиксируют вместе с датой предложения, не подменяя их общим утверждением о бренде.
Что должно быть в заказе, чтобы проверка не потерялась при поставке?
Включите точную версию гипервизора, запрет несогласованной замены ключевых устройств, комплект firmware/драйверов, параметры пилота и критерии результата. Если допускается аналог, укажите, как заново подтверждается его пригодность. Формулировка «или эквивалент» без проверки может обнулить выполненную работу.
Полезный запрос: «Требуется конфигурация Supermicro для выбранной версии ESXi/Proxmox; приложить подтверждение применимых записей совместимости, список NIC/HBA и firmware, условия поддержки и протокол установки, нагрузки и восстановления». Затем отдельно уточняют лицензии ОС и управления: BMC-ключ не заменяет лицензию гипервизора.
Сравнить комплектные системы можно в разделе готовых серверов Supermicro, аппаратные основы — в разделе серверных платформ. Выбор конкретной модели должен завершаться подтверждённой спецификацией, а не обещанием совместимости бренда.
Какие скрытые несоответствия находят после успешной установки?
Сетевая карта видна, но обязательный режим не проверен
Установщик может использовать один порт, а рабочая схема — другой, агрегацию, VLAN, увеличенный MTU или SR-IOV. Для каждого обязательного режима нужен свой результат. Проверьте согласованный клиентский и серверный путь, а также работу после перезапуска. Наличие линка не подтверждает необходимую пропускную способность и устойчивость.
Если используются DAC или оптика, сверяют сами модули и коммутатор. Переход на более быструю карту может потребовать других кабелей и трансиверов. Эти компоненты включают в BOM и пилот. Иначе серверная совместимость будет проверена, а сеть на площадке останется незавершённой.
Контроллер работает, но отказ диска не обнаруживается
Гипервизор может видеть только логическое устройство аппаратного RAID. Это допустимо в подходящей архитектуре, но состояние физических накопителей должно контролироваться поддерживаемым способом. Проверьте доступные средства диагностики, уведомление и процедуру замены. «Datastore доступен» не описывает состояние его избыточности.
Для прямого доступа к дискам проверяют отдельные идентификаторы, диагностические показатели и соответствие выбранному backend. Нельзя считать аппаратный RAID и HBA одинаковыми только потому, что оба подключают накопители. Если режим был изменён после пилота, заново проверяют затронутые функции.
ВМ восстановилась, но приложение не вернулось в работу
Резервная копия дисков не гарантирует полноту прикладного восстановления. Важны согласованность данных, зависимости, сеть, учётные записи и проверка пользователем. Для приёмки поднимите представительный сервис в подготовленном сегменте, убедитесь в его работоспособности и зафиксируйте фактическое время.
Не подключайте тестовую копию к рабочей сети без предусмотренной процедуры: совпадающие адреса и активные задания могут мешать исходной системе. Это условие самого теста, которое следует согласовать до запуска. Результат должен подтверждать восстановление, не создавая новый инцидент.
Новая версия ядра изменила работу дополнительного модуля
Если устройство использует модуль, который не входит в обычный комплект выбранной среды, обновление требует отдельного внимания. Зафиксируйте источник, версию и поддерживаемый порядок обслуживания. Установка сегодня не доказывает, что следующий релиз автоматически сохранит эту связку.
Для производственной закупки оцените возможность использовать поддерживаемое устройство без дополнительных зависимостей либо обеспечьте ясную ответственность за их сопровождение. Не считайте ручную установку неизвестного пакета полноценным решением совместимости на весь срок. При этом сам факт дополнительного драйвера не означает неисправность: важны его применимость и поддержка.
Как не потерять совместимость после ремонта?
Восстановление аппаратной исправности и сохранение проверенной сборки — разные проверки. После замены платы или адаптера сверьте ревизию, идентификаторы, firmware и настройки. Если они изменились, выполните применимую часть пилота до возврата чувствительной нагрузки.
Храните эталонную BOM и версионный комплект рядом с документацией сервиса. В реестре отмечайте каждую замену и дату. Так обращение в поддержку начинается с фактического состояния, а не с исходного предложения, которое давно перестало описывать сервер.
Как сформулировать итог совместимости?
Корректная запись содержит систему, состав, релиз, проверенные функции, использованные подтверждения и ограничения. Например: «На перечисленной конфигурации и указанной сборке выполнены установка, рабочий тест, миграция и восстановление; применимые записи сверены на дату проверки». Такая формулировка полезнее абсолютного обещания для всего бренда.
Если какая-то функция не тестировалась, укажите это отдельно. Если закупка требует официальной сертификации, прикладывают соответствующую запись, а не называют собственный пилот сертификатом. Это позволяет заказчику понять, какое доказательство уже есть и что ещё нужно до оплаты.
Частые вопросы о Supermicro, ESXi и Proxmox
Если ESXi уже работает на старой версии, можно установить любую новую?
Нет. Поддержка системы, CPU, NIC и storage меняется между версиями. Перед обновлением заново сверяют целевой релиз и сохраняют план возврата.
Отсутствие Proxmox в матрице Supermicro означает несовместимость?
Не обязательно. Нужны проверка требований выбранного релиза и драйверов, пилот и ясные условия поддержки. При закупке с формальными требованиями отдельно получают необходимое подтверждение.
Можно ли считать форумный отзыв сертификатом?
Нет. Отзыв помогает найти конкретный риск и сценарий теста, но конфигурация и версии автора могут отличаться. Он дополняет проверку, а не заменяет её.
Что делать, если систему заменили после пилота?
Сверить состав поставки с проверенной BOM. Для изменённых устройств и версий повторить применимые проверки до переноса рабочей нагрузки.