Нет, нельзя! FC-карточка - это хост (или клиент, как тебе удобно).

Теоритически можно что-то раздавать только через IP over Fiber Channel, но я бы таким даже не стал морочиться.

Про IPoverFC я знаю, но мне нужно чисто для бута. А вообще в случае FC вообще экспорта образов ни у кого нету? Т.е. из массива дисков могут быть только диски экспортированы? Просто я видел, например, хранилища SATA->FC, почему тогда нельзя сделать так же и экспорт образов? (это не к моим карточкам относится, а вообще... к энтерпрайзным FC-хранищам за 100500 тонн нефти.)

Нет, нельзя! FC-карточка - это хост (или клиент, как тебе удобно).

Ответ неправильный. FC-карточка - это микрокомпьютер с микрокодом. Какой микрокод зальешь - тем и будет. Зальешь обычный - будет инициатором, зальешь специальный - будет таргетом.

Какой умный анонимус!

FC-карточка - это микрокомпьютер с микрокодом.

Отчасти верно, хотя такой же перл можно отмочить, и про видео-карточки.

Остальное сказки. И где взять микрокод для инициатора для какой-нибудь дешевого Qlogic? Как его прошить?

Тебя не смущает, что у инициатора плата больше в цать раз как минимум?

Вообще, экспортируются LUN'ы. Про образы не понял - расшифруй.

Здесь описана процедура, с перепрошивкой, перекомпиляцией и прочими радостями:

http://scst.sourceforge.net/qla2x00t-howto.html

Интересно, а что ты слышал про IP over FC ? Очень интересно. В свое время нужно было, но реализацию увидел только в Solaris.

Интересно, а что ты слышал про IP over FC ?

Слышал, что в проприетарных дровах qlogic оно реализовано. И ещё слышал, что нужно конкретное ядро для них.
А ещё слышал, что IPoFC и отрытые дрова для части qlogic'ов сейчас запили в ядро, но я ничего не тестил ещё пока. Мне интересен только вопрос бута, на туннелироние IP в данном случае мне пофиг, потому что я там максимум гигабит смогу вытащить (в pci будут втыкаться).

Вообще, экспортируются LUN'ы. Про образы не понял - расшифруй.

Очевидно, эмуляция LUN. Как в iSCSI и подобных технологиях.

http://scst.sourceforge.net/qla2x00t-howto.html

Обосратушки ^____^ !!! Я так рад. У меня как-раз старинные qlogic ISP2312, они же и есть 23xx, верно? Будет просто прекрасно, если оно заработает.

спасибо!

Отпишись о результатах, плиз.

Остальное сказки.

Сказки говоришь? Ню-ню :)

Аватарка правильная, чо!

ты по ссылке ходил? где там микрокод и прошивка контроллера о которых ты вещал?

ISP23xx

у мну в данный момент нет подобных картчоек для бесчеловечных опытов, но могут появиться когда старые спарки потрошить начнут люди.:-) а что это такое - я себе вполне представляю.:)

http://linux-iscsi.org/wiki/Main_Page

Эм? И в ведре поддержка есть. И iSCSI, и FC, и чего хотите. Сделал на ней загрузку ХРени по сети. Пара месяцев - полет нормальный.

ты по ссылке ходил? где там микрокод и прошивка контроллера о которых ты вещал?

Судя по всему, можно и так получить прямой доступ к FC-сети (примерно как ethernet), поэтому не нужно никакой альтернативной прошивки заливать, достаточно просто написать соответствующее ПО, эмулирующее таргет.

А XP через iSCSI или FC? Только XP грузите? С установкой были проблемы (касаемо PXE или необходимости дров). Манул сохранился? Схему примерно запишите. Тут же есть много вариантов: бездисковая устновка, бездисковая загрузка, загрузка загрузчика с флешки и т.д.

target

я думаю ты прав.

http://scst.sourceforge.net/qla2x00t-howto.html

https://scst.svn.sourceforge.net/svnroot/scst/trunk/
Меня тут смущает, что ISP2XXX тут отдельно от 2XXX. Это вообще разные контроллеры, чтоли? Например, на ftp://ftp.qlogic.com/outgoing/linux/firmware/ нет никакого разделения. Что это значит, не подскажите?

По iSCSI. Полная сетевая загрузка. PXE сетевуха получает IP и chainload'ом через tftp в ipxe, далее в dhcp уже ipxe получает IP снова, получает реквизитытаргета (в том числе пароль) и грузит ХРень. Саму по себе ХРень изначально ставил на винт, установил все драйверы-софт-апдейты, после чего Microsoft iSCSI Initiator с загрузкой из сетки. Вот примерно этот мануал скурил http://etherboot.org/wiki/sanboot/winnt_iscsi . Дальше из полученного винта через dd делаем образину в файл на сервере и настраиваем таргет. Дока по настройке linux-iscsi - на том самом сайте.

_ПРЕДПОЧТИТЕЛЬНЕЕ_ использовать ipxe + linux-iscsi таргет! gpxe + иные реализации таргетов (например, iscsitarget) на версиях ядра 3.2.х и выше если и собираются, то глючат (у меня даже и не собирались, даже с дебиановскими патчами).

Думаю, что для реализации с FC должно быть примерно то же самое, с той лишь разницей, где бы взять аналог Microsoft iSCSI Initiator.... Конфиг dhcpd: # dhcpd.conf
#
# Configuration file for ISC dhcpd (see 'man dhcpd.conf')
#
option space ipxe;
option ipxe-encap-opts code 175 = encapsulate ipxe;
option ipxe.priority code 1 = signed integer 8;
option ipxe.keep-san code 8 = unsigned integer 8;
option ipxe.skip-san-boot code 9 = unsigned integer 8;
option ipxe.syslogs code 85 = string;
option ipxe.cert code 91 = string;
option ipxe.privkey code 92 = string;
option ipxe.crosscert code 93 = string;
option ipxe.no-pxedhcp code 176 = unsigned integer 8;
option ipxe.bus-id code 177 = string;
option ipxe.bios-drive code 189 = unsigned integer 8;
option ipxe.username code 190 = string;
option ipxe.password code 191 = string;
option ipxe.reverse-username code 192 = string;
option ipxe.reverse-password code 193 = string;
option ipxe.version code 235 = string;
option iscsi-initiator-iqn code 203 = string;
option ipxe.pxeext code 16 = unsigned integer 8;
option ipxe.iscsi code 17 = unsigned integer 8;
option ipxe.aoe code 18 = unsigned integer 8;
option ipxe.http code 19 = unsigned integer 8;
option ipxe.https code 20 = unsigned integer 8;
option ipxe.tftp code 21 = unsigned integer 8;
option ipxe.ftp code 22 = unsigned integer 8;
option ipxe.dns code 23 = unsigned integer 8;
option ipxe.bzimage code 24 = unsigned integer 8;
option ipxe.multiboot code 25 = unsigned integer 8;
option ipxe.slam code 26 = unsigned integer 8;
option ipxe.srp code 27 = unsigned integer 8;
option ipxe.nbi code 32 = unsigned integer 8;
option ipxe.pxe code 33 = unsigned integer 8;
option ipxe.elf code 34 = unsigned integer 8;
option ipxe.comboot code 35 = unsigned integer 8;
option ipxe.efi code 36 = unsigned integer 8;
option ipxe.fcoe code 37 = unsigned integer 8;
subnet 10.10.100.0 netmask 255.255.255.0 {
option routers 10.10.100.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.10.100.255;
option domain-name «domain.com»;
option domain-name-servers 1.1.1.1, 2.2.2.2;
option time-offset 14400;
default-lease-time 600;
max-lease-time 7200;
range 10.10.100.100 10.10.100.200;
host nettop {
option host-name "--nettop--";
hardware ethernet E0:69:95:E5:23:9B;
fixed-address 10.10.100.200;
if exists user-class and option user-class = «iPXE» {
filename "";
option ipxe.no-pxedhcp 1;
option ipxe.username «iqn.2012-09.com.domain:--nettop--»;
option ipxe.password «HOSTPASSWORD»;
option iscsi-initiator-iqn «iqn.2012-09.com.domain:--nettop--»;
option ipxe.keep-san 1;
option ipxe.iscsi 1;
option root-path «iscsi:10.10.100.1::::iqn.2003-01.org.linux-iscsi.ftp.x8664:sn.e4c4b2b6f4a9»;
} else {
filename «undionly.kpxe»;
}
}
}

Про FC ты ошибаешься (теоретические знания и чтение документации от HP, пока не проверял). Там для бута ты просто заходишь при загрузке в меню (как в рейд-контроллере), выбираешь таргет (порт, HBA, LUN) и все. Далее устанавливаешь винду с DVD, скармливая ей драйвер FC-карты (так же, как скармливаются драйвера рейд-контроллеров), не-бут таргеры должны быть также видны в утилите разметке дисков. Далее ставишь винду, вынимаешь DVD, все работает. Т.е. работать (со стороны винды) не сложнее, чем с рейд-контроллером. Именно поэтому я и хочу юзать FC, а не iSCSI, т.к. я читал примерно то, что Вы сказали (я думал, что Вы и FC и iSCSI юзали), мало того в случае линукса (если есть файл прошивки в /lib/firmware) вообще ничего не нужно для установки.

Просто мне нужно ставить винду будет достаточно часто и таку свистопляску с iSCSI устраивать мне совсем не хочется. Хочется как можно более прозрачного решения. К сожалению, все никак нет времени, что затестить программную реализацию FC-target.

И да: в случае с семеркой iSCSI Initiator не нужен для iSCSI установки. Можно установить все напрямую, только надо ip, таргет и пароль через dhcp передать. И он просто как обычный диск при устанвке будет видится.

Ну а для последующей подгрузки ядра - iPXE и его набор.

А чем FC _принципиально_ проще? Проблема тут (как и с iSCSI, кстати), в том, что полученная с DHCP/биоса инфа для загрузки используется именно так же, как это делается scsi контроллером (перехватом прерывания в биосе). Но вот дрова ОС работают с таргетом самостоятельно, а не через биос (хотя с FC - это смотря как реализовано оно...). И конфиг таргета оно будет использовать не тот, который в DHCP/биосе написан, а как в конфиге драйвера забито. То есть, LUN/IQN, пароль, что-там-еще-хочется, который был указан при первоначальной установке/настройке ОС. Соответственно, разливать на всю контору дефолтную образину с полочки, как с акрониса не получится.

Это я знаю. Как раз изначально экспериментировал с ХРенью именно чтобы реализовать самый сложный вариант. Вообще, мне очень нравится идея бездисковой загрузки. Оно очень удобно для админа. Но вот реальный минус с «заранее» заданным IQN как-то напрягает.

А чем FC _принципиально_ проще? Проблема тут (как и с iSCSI, кстати), в том, что полученная с DHCP/биоса инфа для загрузки используется именно так же, как это делается scsi контроллером (перехватом прерывания в биосе). Но вот дрова ОС работают с таргетом самостоятельно, а не через биос (хотя с FC - это смотря как реализовано оно...). И конфиг таргета оно будет использовать не тот, который в DHCP/биосе написан, а как в конфиге драйвера забито. То есть, LUN/IQN, пароль, что-там-еще-хочется, который был указан при первоначальной установке/настройке ОС. Соответственно, разливать на всю контору дефолтную образину с полочки, как с акрониса не получится.

(Я буду рассматривать всё только с точки зрения инициатора).

ЩИТО!?? Вы совершенно не правы по поводу FC. Он НАМНОГО проще, чем iSCSI, т.к. ОС сразу (на самом деле, обычно, через дрова, в которых огромный стек, но это не интересует) видит ВСЕ блочные устройства (LUN), которые только есть в SAN-сети. Именно поэтому в винде есть средства предотвращения монтирования занятых дисков, присвоение диска и т.п. И именно из-за этого в нормальном энтерпрайзе используются FC-свитчи с WWN-фильтрацией или фильтрацией по портам (для нищебродов), чтобы ни один комп не мог получить доступ к ненужным ему дискам. И именно поэтому в кластерных системах с SAN необходим фенсинг.
Ещё раз: для ОС FC-карта есть тоже самое, что и SATA-контроллер с кучей дисков. Вопросы же его тонкой конфигурации и того, на уровне драйверов или микропроцессора карты происходит обработка (и там и там на самом деле, а сколько будет перенесено в карточку зависит от толщины кошелька) - это не значимый вопрос, т.к. в любом случае после драйвера мы видим RAID-контроллер и диски, представляемые через него.

iSCSI - это совершенно другая технология, полностью программная (хотя есть iSCSI-платки (даже встроенные в некоторые серверные матери от интела), которые могут как RAID-контроллер представляться ОСи, но это уже целый комп со своим процом, оперативкой и огроменной ОСью, так что не будем об этом). Именно из-за своей полностью программой природы с ним столько траха, т.к. все ОСи изначально делали для загрузки с контроллера дисков (которым, как мы помним, FC так же является), а не старта большей части системы (IP-стрек, получение DHCP, подгрузка iSCSI-подсистемы, подключение к серверу, залупливание образа, монтирование ФС) ещё до возможности обращения к диску.

Разница между FC и iSCSI - как между жестким диском по USB и образом диска, который смонтировали на локальный комп с шары другого компа.

И конфиг таргета оно будет использовать не тот, который в DHCP/биосе написан, а как в конфиге драйвера забито.

Вы про FC сейчас? Вы представьте упрощенный механизм загрузки у себя в голове лучше:
1. BIOS (один из контроллеров) грузит загрузчик, который грузит ядро (возможно с параметрами, но, обычно, не в случае винды)
2. У нас ядро, которому особо ничего не передали при запуске. Оно (в случае винды) будет грузится (root-device) с того диска, который ей указали при установке. Вот оно и будет грузится с iSCSI/FC, который был при установке.

Я только Вашей логики не пойму. Конечно, часто загрузчик (особенно в случае винды) ставится на один диск с системой, но это совершенно не обязательно. Ядру пофиг, кто и как загрузит его в память и передаст управление. Вы можете установить загрузчик (если не на том же контроллере, то, возможно, потребуется как-то вынести ядро отдельно и грузить его хитрым способом) с ядром на один FC-диск, указанный для бута в его биосе (или вообще на встроенный SATA-диск), а саму винду - на другой.

То есть, LUN/IQN, пароль, что-там-еще-хочется, который был указан при первоначальной установке/настройке ОС. Соответственно, разливать на всю контору дефолтную образину с полочки, как с акрониса не получится

Неа, и в случае iSCSI, и в случае FC можно грузить компы-клоны без дисков в энтерпрайзе без каких-либо дополнительных действий на них.

В случае iSCSI не могу сказать, как именно ОСь (в данном случае семерка, с XP всё ясно, там нужно всё гвоздями прибить ещё до переноса на iSCSI) будет определять что и откуда ей брать iSCSI-target уже после установки. Если там сделано так же, как и в случае установки, то можно просто по DHCP передавать ей другие таргеты, главное чтобы UUID'ы разделов нужные были. Если же нет, то могу предложить вариант с паравиртуализацией: с каждой машины с XP траффик будет перенаправляться (на основании mac-фильтра источника, с подменой IP, т.к. у каждой виртуалки будет свой IP) в openvz-контейнер с своей копией iSCSI-таргета.

По моему такое техническое решение очевидно и напрашивается само собой.
И да - быть может такой сценарий уже был предусмотрен и mac-фильтрация поддерживается в таргете из коробки, но это я хз, и сомнительно.

В случае FC нужно просто на уровне портов/WWM всё фильтровать, тупо не давая машине не нужных дисков и всё.

Но вот реальный минус с «заранее» заданным IQN как-то напрягает.

Нисколько не проблема: iptables+openvz, как выше я писал.

iptables+openvz

Тогда уж лично мне проще вообще с iscsi не морочаться. Грузиться в NFSroot и по NFSу жеж отдавать в vmware образ венды. :) А то и не по NFSу, а скопировать образ венды в рамдиск и грузить венду из рамдиска. :) Но вообще, хотелось нативно, а не через виртуализации.

Тогда уж лично мне проще вообще с iscsi не морочаться. Грузиться в NFSroot и по NFSу жеж отдавать в vmware образ венды. :) А то и не по NFSу, а скопировать образ венды в рамдиск и грузить венду из рамдиска. :) Но вообще, хотелось нативно, а не через виртуализации.

В виртуализацией хоть уши в зад затолкать можно, мы то тут говорим именно про нативное железо.

С контейнерами для iSCSI не вижу никаких проблем - для создания нового диска для вин-машины твой скрипт просто разворачивает openvz-образ из архива (или просто копирует), правит имя и ip, добавляет строчку переадресации по mac в нужную виртуалку и NAT. Всё. На вход только имя (хотя можно его маку приравнять) и mac вин-машины.

Там в мануале написано. То что по ссылке не читаем?

Анонинимус, покажи строчку в которой шьется firmware в карту. Вместе посмеемся.

у меня Win7 на домашнем пк для игрушек и т.д. полностью на iSCSI работает. проблем никаких не было, кроме кривого билда офф. исошника от MS.

Да пожалуйста. http://scst.sourceforge.net/qla2x00t-howto.html - см. 1-ый пункт.

Советую почитать про SCST и LIO.

Ты правда понимаешь смысл проприетарных блобов, которые лежат в /lib/firmware? И почему далеко не все идут в составе дистрибутива?

Изначально ты говорил:

FC-карточка - это микрокомпьютер с микрокодом. Какой микрокод зальешь - тем и будет.

Так вот поздравляю, микрокод (вот именно тот блоб) заливается именно тот, который нужен именно для этой карты, иначе она просто не заведется, вообще.

Советую почитать про SCST и LIO.

Я тебе тоже рекомендую почитать, потому что ты вообще не догоняешь принцип работы этих дополнительных прослоек.

Да ладно вам, не умничайте. Вы сначала вообще сказали что этого сделать нельзя.

Анонимус, а ты хочешь поумничать на топике 2012 года?