У меня есть (после серьезной борьбы) бездисковый Server 2012, работающий через инициатор iSCSI программного обеспечения MS, загружаемый через gPXE, связанный с PXE сетевой карты.
Однако теперь, когда он загружается правильно, у меня возникла другая проблема (HBA-адаптеры iSCSI становятся все более привлекательными с каждым дерганием за волосы). Сервер имеет двойную сетевую карту, и Windows принимает только ту сетевую карту, которая подключена к SAN, оставляя меня без подключения к локальной сети!
Диспетчер устройств показывает обе сетевые карты, но тот, который предназначен для локальной сети, имеет восклицательный знак, а в свойствах указано «Это устройство не работает должным образом, поскольку Windows не может загрузить драйверы, необходимые для этого устройства. (Код 31)».
Окна очевидно делает иметь правильный драйвер, так как два порта идентичны, а другой работает; более того, если я установлю ту же ОС на то же оборудование, но на локальный жесткий диск, у нее не будет проблем с сетевой картой. Если я скажу ему поискать драйвер получше, он просто обернется и скажет, что с драйвером все в порядке, что неудивительно.
Я почти уверен, что знаю, что здесь происходит, благодаря предыдущей главе этого приключения.
Программа предварительной загрузки (в данном случае gPXE) должна записать iBFT (загрузочную таблицу микропрограмм iSCSI) в память, которая затем перехватывается ОС (в данном случае Windows). В этой таблице, помимо прочего, содержится список сетевых адаптеров. Для каждого он указывает шину PCI и номер устройства, MAC-адрес и IP-информацию.
Изучив его исходный код (а также с помощью небольшого инструмента, который я разработал для сброса iBFT), я знаю, что gPXE по замыслу / лени всегда записывает только одну сетевую карту в iBFT, хотя стандарт допускает около 240 из них. Даже если бы он написал несколько сетевых адаптеров, я все равно был бы в одной лодке, потому что другие проблемы с gPXE / iPXE вынудили меня использовать сборку только для UNDI, что означает, что он даже не знает о других сетевых адаптерах.
Я предполагаю, что здесь происходит то, что Windows смотрит на iBFT и - хотя она знает, что другая сетевая карта существует из ее собственной системы управления устройствами - решает, что ее нельзя использовать, потому что ее нет в iBFT. Я понятия не имею Зачем это сделает это.
Есть ли способ убедить Windows использовать другую сетевую карту, даже если ее нет в iBFT? Или есть какая-то программа предварительной загрузки iSCSI, которая действительно работает правильно? Или есть совсем другое объяснение?
Я наконец разобрался с этим и мне удалось заставить его работать. Тем не менее, в процессе я пришел к выводу, что функциональность загрузки iSCSI в Windows, gPXE и iPXE работает наполовину. Я поделюсь подходом, который сработал для меня, на случай, если он поможет кому-то еще, но имейте в виду некоторые предостережения:
Это плохое решение. Аппаратное решение, такое как iSCSI HBA, обеспечит лучшую производительность, надежность и будет намного проще в установке.
Это решение плохо масштабируется для крупных развертываний, в основном потому, что для его настройки требуется слишком много ручного труда на бездисковый сервер.
Это решение не так просто. Может быть более простое решение (кроме очевидного, используйте iSCSI HBA.) Если вы знаете такое решение, добавьте его, и я отмечу ваш ответ, если смогу его продублировать.
Это решение - уродливый, уродливый хакер. Используйте на свой риск!!
Прежде чем продолжить, я хочу уточнить, что всякий раз, когда я говорю «NIC», я имею в виду то, что Windows считает одним «устройством», но которое на самом деле может быть только одним из нескольких портов на реальной NIC. Эта терминология соответствует как самому стандарту iBFT, так и iPXE / gPXE.
Windows, когда загружается на инициаторе iSCSI, предъявляет некоторые очень привередливые требования к iBFT (таблица, которую «загрузочное решение iSCSI» записывает в память перед вызовом загрузчика Windows, которая сообщает ему, как получить доступ к iSCSI LU). Мне удалось собрать воедино некоторые правила (которые могут или не могут выполняться в вашей конкретной ситуации):
Если сетевая карта отсутствует в iBFT, Windows не будет работать с ней. Это проявит симптом, указанный в вопросе.
Список сетевых адаптеров в iBFT должен быть отсортирован в определенном порядке. У меня нет полной информации, так как у меня было только два порта NIC на тестовом сервере на одном NIC. Один был PCI 08:04.0 а другой был PCI 08:04.1. Если iBFT перечислил NIC в 08:04.1 перед тем в 08:04.0, Винда разозлилась. (Обратите внимание, что в стандартах нет ничего, требующего определенного порядка.)
Целевой объект iSCSI должен быть доступен из первый Сетевая карта указана в iBFT. Это может потребовать от вас переключения портов SAN и LAN из-за приведенного выше правила.
Если первая сетевая карта в iBFT не такая, какой была при первой установке Windows, произойдет сбой и произойдет перезагрузка. Для этого может потребоваться переустановка Windows, если изначально ваши настройки были неправильными. (Я не уверен, что означает «то же самое», но другой порт на той же сетевой карте определенно не был «таким же».)
Разделы NIC должны располагаться в памяти в том же порядке, в котором они перечислены в разделе управления, иначе Windows рассердится. (Обратите внимание, что стандарты не укажите, что порядок должен совпадать - опять же, Windows просто ленива.)
Первое правило - это загвоздка. Ни gPXE 1.0.0, ни обязательства его преемника iPXE от 31 января 2013 г. Когда-либо записывать несколько сетевых карт в iBFT, даже если они знают о нескольких сетевых адаптерах. Я проверил это, изучив их исходный код.
Мое хакерское решение заключалось в том, чтобы получить дерево исходных текстов iPXE и изменить программу так, чтобы она записывала вторую секцию NIC в iBFT, соответствующую другой NIC на моем сервере (NIC, которой я был не (загрузка с.) Я просто зашифровал MAC-адрес и PCI-адрес. Я обнаружил, что нет необходимости помещать IP-данные в раздел сетевой карты - просто оставьте все обнуленным, и Windows назначит его позже во время загрузки. (Обратите внимание, что IP делает должен быть написан для SAN NIC, но iPXE уже закодирован для этого.)
Используя #defineфактические адреса можно ввести в удобное место, вместо того, чтобы копаться в исходном коде каждый раз, когда вы захотите их изменить.
Если вы внесете это изменение, имейте в виду, что разделы NIC имеют байт индекса в заголовке. Код iPXE их не касается (хотя он указан в struct), потому что он никогда, никогда не записывает более одного сетевого адаптера, но если вы напишете второй сетевой адаптер, вам нужно будет установить его индексный байт на 1, иначе Windows не будет довольна.
Очевидным большим недостатком этого решения является то, что вам придется перекомпилировать iPXE для каждого сервера, хранить эти отдельные версии iPXE на сервере TFTP и настроить сервер PXE для выдачи различных программ загрузки на каждый из серверов.
Для первоначального изменения необходимы некоторые знания программирования на C, а также дистрибутив Linux и инструменты разработчика GNU. Указан формат iBFT Вот.
Я хотел бы просто опубликовать здесь свои изменения, но в итоге я изменил очень старую версию, которую сайт ipxe.org обманом заставил меня загрузить. (По-видимому, они никогда не помечают стабильные выпуски; с тех пор я узнал, что все выпуски в основной ветке являются стабильными.) Я бы не стал поощрять кого-либо использовать такую старую версию.
Последняя версия все еще имеет такое же ограничение. Я отправлю это в их список разработчиков, так что надеюсь, что это будет исправлено.