
Как выяснилось по ходу пьесы, установить что-либо на Citrix XenServer довольно хлопотное занятие, а если уж надо собрать драйвер из сорцев, а именно это нам и понадобится, то это и подавно не выполнимая задача. Мое предположение, что сделано это не случайно, а из соображений безопасности и производительности хостовой системы, ведь каждый лишний пакет в системе требует накладных расходов и понижает безопасность системы в целом.
Предыстория (Кому не интересно, переходите к следующему разделу)
В уже далеком 2010 году, появилась у меня задача дома поднять сервер с несколькими виртуальными машинами, которые бы круглосуточно выполняли каждый свою не сложную задачу, а главное не мешали бы покою людей находящихся рядом с сей железякой. После длительного отбора (
Но со временем, как водится, этого стало не хватать, понадобилось больше ВМ, сказано — сделано, докуплены еще несколько Mac Mini с уже более внушительным конфигом, i7 2.0 (4 ядра 8 потоков), запихано в них по 16Gb Ram и все бы ничего, однако грустно стало как-то на одной машине запускать всего 2 ВМ, которым и надо — то 1 ядро и 1гб Ram решено было проштудировать интернет на поиск другого более интересного гипервизора, который позволил запускать … ну хотя бы не две ВМ.
За время изысканий были опробованы HyperV, ProxMox, но выбор остановился на Xen'е, а точнее на Xen Cloud Platform, которая к моему превеликому сожалению просуществовала не долго и как — то в один из дней я увидел сообщение, что XCP закрыт, а XenServer теперь бесплатен, делать нечего, переходим на XenServer. Дальше — больше, тк серверов пачка, хочется High Available, под эти дела куплен отдельный сервак Xeon e3-1240v2 c 16GB Ram на борту, в Hot Swap корзинах которого разместилась пачка HDD WD Red по 3TB, Nas4Free на флешке, поднят iSCSI таргет, настроены луны, собран Xen кластер, который умеет HA миграцию на ходу и прочие приятные плюшки, однако со временем стал я замечать, что для n вм'ов пропускного канала на 1Gb/s уже не хватает, при чем по нему бегали как сами образы ВМ из NAS'а в сервак, так и данные хранящиеся на том же NAS'е. Принято решение поставить разумный свитч, который умеет 802.3ad, и за тем на NAS'e дорастить количество ethernet каналов до 6x1GB/s, а на серверах до 2x1GB/s, но как только в руки попал Apple Thunderbolt Ethernet Adapter, тут и началось в колхозе утро, которое вылилось в эту статью на хабре…
Давайте уже приступим
И так мы имеем:
- Apple Thunderbolt Ethernet Adapter (MD463ZM), который является 10/100/1000BASE-T PCIe сетевой картой от Broadcom, модель NetXtreme BCM57762
- Материнскую плату с разъемом Thunderbolt (интерфейс является ни чем иным, как PCIe, только в виде провода)
- Компьютер под управлением Windows, для использования XenCenter
В нашем случае подопытным был Mac Mini Server mid 2011 с установленным на нем XenServer 6.2 и обновленный до SP1.
1. Подключаем адаптер к разъему, втыкаем сетевой кабель и перезагружаем сервер (без перезагрузки не определяется), проверяем, определился ли адаптер:
[root@xNode1 ~]# lspci
...
0a:00.0 PCI bridge: Intel Corporation DSL3510 Thunderbolt Controller [Cactus Ridge]
0b:00.0 PCI bridge: Intel Corporation DSL3510 Thunderbolt Controller [Cactus Ridge]
0c:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57762 Gigabit Ethernet PCIe
Для меня остается загадкой, почему Broadcom не стали включать поддержку данного адаптера в стандартном драйвере, но факт остается фактом, они этого не сделали, вероятнее всего по какой-то неведомой для нас договоренности с Apple.
2. Как уже говорилось ранее, установить что-либо на хостовой системе довольно проблематично, по той причине, что оттуда вырезаны все лишние пакеты и даже «make», а репо по умолчанию настроено на Citrix, нет можно конечно заблочить репо Citrix'а и пойти через baserepo, но это не наш случай, будем считать, что мы поддерживаем политику производителя и не хотим засорять / вредить нашей системе.
В Citrix сидят не дураки и на уровне с тем, что они очистили систему от «лишностей», они создали образ системы с таким же ядром и всем набором необходимых нам пакетов для сборки образов драйверов, которые потом можно без труда установить на хостовой системе. Называется этот зверь Driver Development Kit (DDK), скачать его можно тут: http://support.citrix.com/article/CTX139817 (на момент написания статьи актуальная версия 6.2 SP1). Этот iso-шник является ни чем иным, как образом виртуальной машины, правда для того, чтобы импортировать его на наш Xen сервер, нужно сначала смонтировать его в вашей операционной системе, после чего в Xen Center нажимаем правой клавишей мыши по нашему серверу и выбираем пункт импортировать. Для импорта необходимо на смонтированном образе выбрать файл ova.xml находящийся в папке ddk. (Не забудьте при импорте добавить ethernet интерфейс)
3. После того как образ был импортирован, мы назначили пароль руту, необходимо достать сам исходник драйвера, находится он тут: http://www.broadcom.com/support/ethernet_nic/netxtreme_desktop.php в самом низу, зовется Linux (tg3), для удобства хабро-жителей, я выложил уже правленый исходник: http://my-files.ru/Download/wqet0i/tg3-drv.zip.
Заливаем файл на DDK сервер, после чего распаковываем его:
[root@localhost ~]# wget http://my-files.ru/Download/wqet0i/tg3-drv.zip
...
2014-01-14 01:48:13 (776 KB/s) - `tg3-drv.zip` saved [349509/349509]
[root@localhost ~]# unzip tg3-drv.zip
Если вы используете оригинальный драйвер с сайта Broadcom
Вам необходимо отредактировать файл tg3.c, находящийся в архиве tg3-3.133d.tar.gz. Находим в файле строки:
и добавляем идентификатор нашего устройства 57762, в итоге должно получиться:
...
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57761)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57765)},
...
и добавляем идентификатор нашего устройства 57762, в итоге должно получиться:
...
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57761)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57762)},
{PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, TG3PCI_DEVICE_TIGON3_57765)},
...
Перед сборкой нам понадобится скрипт, который за нас произведет сборку образа драйвера. Исправленную мной версию скрипта можно взять http://my-files.ru/Download/ntqvvd/tg3-proj.zip, оригинал http://discussions.citrix.com/topic/301614-bcm5754-tg3-and-vlan-tagging-do-not-work-in-xs6/, пост 16 (необходима регистрация).
Скачиваем файл, после чего распаковываем его:
[root@localhost ~]# wget http://my-files.ru/Download/ntqvvd/tg3-proj.zip
...
2014-01-14 02:29:38 (72.6 MB/s) - `tg3-proj.zip` saved [1738/1738]
[root@localhost ~]# unzip tg3-proj.zip
Если вы используете оригинальный Скрипт
Вам необходимо отредактировать файл Makefile
Должно получиться:
Так же необходимо отредактировать файл tg3.spec
Должно получиться:
...
RPM_VERSION := 3.110g //меняем на версию нашего драйвера
...
build-iso: build-rpms
...
cd $(PACKAGE) && /usr/local/bin/build-supplemental-pack.sh --output=$(dir $(ISO)) ... // убиваем путь до файла
...
build-tarball: build-rpms
...
cd $(PACKAGE) && /usr/local/bin/build-supplemental-pack.sh --output=$(dir $(ISO)) ... // снова убиваем путь до файла
...
Должно получиться:
...
RPM_VERSION := 3.133d //меняем на версию нашего драйвера
...
build-iso: build-rpms
...
cd $(PACKAGE) && build-supplemental-pack.sh --output=$(dir $(ISO)) ... // убиваем путь до файла
...
build-tarball: build-rpms
...
cd $(PACKAGE) && build-supplemental-pack.sh --output=$(dir $(ISO)) ... // снова убиваем путь до файла
...
Так же необходимо отредактировать файл tg3.spec
...
Version: %{?version}%{!?version:3.110g} //меняем на версию нашего драйвера
...
Должно получиться:
...
Version: %{?version}%{!?version:3.133d}
...
4.Приступаем к сборке образа драйвера:
[root@localhost ~]# cd tg3-drv/
[root@localhost tg3-drv]# make tg3_flags.h
[root@localhost tg3-drv]# cd ..
[root@localhost ~]# mv tg3-drv tg3-3.133d
[root@localhost ~]# tar czvpf tg3-3.133d.tar.gz tg3-3.133d/
[root@localhost ~]# cp tg3-3.133d.tar.gz /usr/src/redhat/SOURCES/
Переведенными выше действиями мы подготовили исходники для сборки скриптом, теперь осталось только запустить скрипт, но перед запуском скрипта выставите актуальное время в образе, иначе скрипт завершится с предупреждением:
[root@localhost ~]# cd tg3-proj/
[root@localhost tg3-proj]# date 011311282014.30 //(месяц, день месяца, часы, минуты, 4 цифры года, секунды)
Mon Jan 13 11:28:30 EST 2014
[root@localhost tg3-proj]# make
...
Total translation table size: 0
Total rockridge attributes bytes: 780
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 21000
283 extents written (0 MB)
В папке появились файлы tg3.iso, tg3.iso.md5, tg3.metadata.md5 и пр, нас интересует только tg3.iso, его надо отправить на хостовой сервер, делается это при помощи команды scp, которая по ssh гоняет файлы:
[root@localhost tg3-proj]# scp tg3.iso root@192.168.0.2:/root/tg3.iso
5. Самое сложное уже позади, осталась только установка драйвера на хостовом сервере, для этого логинимся на сервер, можно через консоль в Xen Center и выполняем следующие действия:
mkdir -p /mnt/tmp
mount /root/tg3.iso /mnt/tmp -o loop,ro
cd /mnt/tmp/
./install.sh
cd /root/
umount /mnt/tmp
shutdown -r now
И так, финальный штрих после перезагрузки, адаптер у вас не появится в доступных устройствах, для того чтобы он появился, необходимо зайти в консоль сервера, вызвать менеджер через команду «xsconsole» и там в пункте «Network and Management Interface» выбрать пункт «Emergency Network Reset», после сброса параметров вашего адаптера и перезагрузки Thunderbolt Ethernet Adapter станет доступным для использования.
PS Для ленивых вот уже собранный и проверенный мной образ: тут.