Под городами и весями понимаются серверные и десктопные заморочки.
Угораздило приобресть тут ноутбук vaio. Оказался крепышом - быстрый, много мозга. Поставил туда генту после недели с ней, хм, занятий.
Далее практически с пол-пинка удалось поднять Dom0, пригласить в гости две винды и гентушного же гостя. Был приятно удивлен быстродействием.
С сетью стандартно "серверно" - в Dom0 бридж с именем eth1, куда прицеплен физический peth1, и рождаются по надобности vifXX.X от виртуалок. Адреса раздаются внешним dhcp.
"Десктопно" eth1 контролируется wicd с графич рюшками, да и вайфай заодно. Все это работает в "дружественных" проводных сетях. Но, скажем гостиничный эзернет будет алчен, когда у него будут просить больше одного адреса, да и с вайфай не катит вообще - интерфейс другой. Вывод - надо поднимать собственный dhcp сервер в dom0. Скажем dnsmasq, чтоб два раза не вставать.
Но тогда уж логичней также завести на виртуальные машины свою собственную сеть с отдельным диапазоном IP на мосте (или мосту?) из только виртуальных адаптеров. И натить ее на "физику" по потребности.
Т.е. выходит, задача сводится к тому, как если на компе нет физических интерфейсов вообще. Логически выглядит стройно вроде, а вот практически с этим еще не сталкивался.
Кто-нибудь делал сие? На какие грабли наступал? И нет ли кусочка /etc/conf.d/net на поглядеть?
Разведение сетевых мостов (Xen - смычка города и деревни)
Модератор: Модераторы разделов
Re: Разведение сетевых мостов
современные тенденции в xen (4.1+) таковы, что мосты следует сооружать средствами dom0, а не скриптами xen в dom0. см это и это
в gentoo /etc/conf.d/net в моем случае (не ноутбук и статический адрес) выглядит так:
все это стартует через hotplug (из автоматики только rc-update add net.lo boot - это и так true, по умолчанию), а в /etc/rc.conf
все это не противоречит случаю, когда система запускается на baremetal, т.е не под управлением гипервизора. это важно для gentoo, т.к компилиться все-таки лучше без xen
из /etc/xen/xend-config.sxp убирается все, что касается сети:
а все domU стартуют со сконфигурированным в dom0 мостом
т.е в своем случае, я следую канонам xen только наполовину: сеть из скриптов вынес, но xend оставил (мне кажется что в новом xl пока много ошибок в смысле управления доменами и памятью). технически в gentoo это обозначает, что xen-tools собираются с USE=xend
дальше - теоретически: в случае с xen и ноутбука (с разными, динамически подключаемым интерфейсами), наверное нужно сделать как-то так (/etc/conf.d/net):
адрес моста получаем динамически, для чего wicd должен знать про интерфейс xenbr (вроде бы, в wicd это можно сделать). понятно, что должен работать аппаратный или программный rfkill, чтобы не допускать одновременной работы eth и wlan
для того, чтобы не городить всякие dnsmasq и прочую хрень для кормления сетью domU, надо пускть всех под nat (теоретически как это сделать понятно, но никогда в xen не пробовал)
думаю, что надо двигаться в таком направлении. хотя я (вроде как любитель xen), на ноутбуке ограничился virtualbox-bin (с PUEL license) для тех случаев когда все-таки надо запускать виртуализацию: в этой "коробочке-с-core-i7" слишком много вариантов с сетью (нужно помнить, что нередко используется ppp для gprs или модема, а также бывает нужна сеть через bluetooth). также важным является управление питанием и батарейкой - в частности. в случае xen, это (acpi power management) умеет и гипервизор, и dom0 (для ядер 3.0+). не подерутся ли? по этой же причине не уверен, на сколько стабильно все хозяйство хорошо будет уходить в suspend и адекватно просыпаться после оного. хорошей альтернативой vbox, является kvm (по крайней мере ядро умеет и виртуализировать, и управлять железкой "в одном флаконе". тоже никогда не пробовал на ноутбуке
вообще, интересно что у вас в конце концов получится. расскажете?
в gentoo /etc/conf.d/net в моем случае (не ноутбук и статический адрес) выглядит так:
Код: Выделить всё
dns_domain_lo="local"
#
config_eth0="null"
#
bridge_add_eth0="xenbr"
config_xenbr="10.24.14.10/24 brd 10.24.14.255"
brctl_xenbr="stp off"
dns_domain_xenbr="local"
dns_servers_xenbr="10.24.14.12 10.24.14.32"
routes_xenbr="default via 10.24.14.32"
все это стартует через hotplug (из автоматики только rc-update add net.lo boot - это и так true, по умолчанию), а в /etc/rc.conf
Код: Выделить всё
...
rc_hotplug="*"
...
все это не противоречит случаю, когда система запускается на baremetal, т.е не под управлением гипервизора. это важно для gentoo, т.к компилиться все-таки лучше без xen
из /etc/xen/xend-config.sxp убирается все, что касается сети:
Код: Выделить всё
...
#(network-script network-bridge)
#(vif-script vif-bridge)
...
а все domU стартуют со сконфигурированным в dom0 мостом
Код: Выделить всё
...
vif = [ 'mac=0a:11:10:24:14:16,bridge=xenbr' ]
...
т.е в своем случае, я следую канонам xen только наполовину: сеть из скриптов вынес, но xend оставил (мне кажется что в новом xl пока много ошибок в смысле управления доменами и памятью). технически в gentoo это обозначает, что xen-tools собираются с USE=xend
дальше - теоретически: в случае с xen и ноутбука (с разными, динамически подключаемым интерфейсами), наверное нужно сделать как-то так (/etc/conf.d/net):
Код: Выделить всё
dns_domain_lo="local"
#
config_eth0="null"
config_wlan0="null"
config_dummy0="null" # это для случая, когда сети в гостинице вообще не будет
#
bridge_add_eth0="xenbr"
bridge_add_wlan0="xenbr"
bridge_add_dummy0="xenbr"
config_xenbr="null"
brctl_xenbr="stp off"
адрес моста получаем динамически, для чего wicd должен знать про интерфейс xenbr (вроде бы, в wicd это можно сделать). понятно, что должен работать аппаратный или программный rfkill, чтобы не допускать одновременной работы eth и wlan
для того, чтобы не городить всякие dnsmasq и прочую хрень для кормления сетью domU, надо пускть всех под nat (теоретически как это сделать понятно, но никогда в xen не пробовал)
думаю, что надо двигаться в таком направлении. хотя я (вроде как любитель xen), на ноутбуке ограничился virtualbox-bin (с PUEL license) для тех случаев когда все-таки надо запускать виртуализацию: в этой "коробочке-с-core-i7" слишком много вариантов с сетью (нужно помнить, что нередко используется ppp для gprs или модема, а также бывает нужна сеть через bluetooth). также важным является управление питанием и батарейкой - в частности. в случае xen, это (acpi power management) умеет и гипервизор, и dom0 (для ядер 3.0+). не подерутся ли? по этой же причине не уверен, на сколько стабильно все хозяйство хорошо будет уходить в suspend и адекватно просыпаться после оного. хорошей альтернативой vbox, является kvm (по крайней мере ядро умеет и виртуализировать, и управлять железкой "в одном флаконе". тоже никогда не пробовал на ноутбуке
вообще, интересно что у вас в конце концов получится. расскажете?
Re: Разведение сетевых мостов
dimbor писал(а): ↑16.12.2011 03:12Под городами и весями понимаются серверные и десктопные заморочки.
Угораздило приобресть тут ноутбук vaio. Оказался крепышом - быстрый, много мозга. Поставил туда генту после недели с ней, хм, занятий.
Далее практически с пол-пинка удалось поднять Dom0, пригласить в гости две винды и гентушного же гостя. Был приятно удивлен быстродействием.
С сетью стандартно "серверно" - в Dom0 бридж с именем eth1, куда прицеплен физический peth1, и рождаются по надобности vifXX.X от виртуалок. Адреса раздаются внешним dhcp.
"Десктопно" eth1 контролируется wicd с графич рюшками, да и вайфай заодно. Все это работает в "дружественных" проводных сетях. Но, скажем гостиничный эзернет будет алчен, когда у него будут просить больше одного адреса, да и с вайфай не катит вообще - интерфейс другой. Вывод - надо поднимать собственный dhcp сервер в dom0. Скажем dnsmasq, чтоб два раза не вставать.
Но тогда уж логичней также завести на виртуальные машины свою собственную сеть с отдельным диапазоном IP на мосте (или мосту?) из только виртуальных адаптеров. И натить ее на "физику" по потребности.
Т.е. выходит, задача сводится к тому, как если на компе нет физических интерфейсов вообще. Логически выглядит стройно вроде, а вот практически с этим еще не сталкивался.
Кто-нибудь делал сие? На какие грабли наступал? И нет ли кусочка /etc/conf.d/net на поглядеть?
Безотносительно xen: я именно так и делал на ноутбуке: отдельный tap интерфейс, к которому привязываю бридж, куда прикрепляются сетевые интерфейсы виртуалок, где им всегда сухо и комфортно.
-
- Сообщения: 212
Re: Разведение сетевых мостов
Очень имхо. Касательно wifi и виртуальной сети. У wifi есть одна особенность требующая применения proxy arp в случае взаимодействия с сетью для виртуалок. Посмотреть рабочую конфигурацию можно в LXF98 , там правда для virtualbox, но это не существенно поскольку обходятся ограничения wifi . Для wired соединений применения arp proxy не требуется.
Linuxforum@conference.jabber.ru
Re: Разведение сетевых мостов
little Jon писал(а): ↑20.12.2011 23:50Очень имхо. Касательно wifi и виртуальной сети. У wifi есть одна особенность требующая применения proxy arp в случае взаимодействия с сетью для виртуалок. Посмотреть рабочую конфигурацию можно в LXF98 , там правда для virtualbox, но это не существенно поскольку обходятся ограничения wifi .
тоже imho: статья старовата. в 2009 про virtualbox ничего не слышал, и может быть, в то время он не поддерживал nat, поэтому приходилось выходить из положения таким образом. в xen nat поддерживался "из коробки", т.е скриптами xen-tools (на самом деле, поддержка nat в xen - это ничего необычного: просто набор masquerade-правил iptables, которые работали и до xen, - в ядрах 2.4, и еще раньше, когда это называлось ipfilter)
в настоящее время в vbox это делается мышью, например, таким кривоватым способом я пользуюсь конторским телефоном через cisco ip communicator (который есть только для винды и который мне еще не удалось запустить под wine): на linux запускается сеть (wifi или даже gprs/3g - т.е ppp), поверх этого - cisco vpn, затем виртуальная винда, работающая через nat и на ней - упомянутый коммуникатор
Для wired соединений применения arp proxy не требуется.
может требоваться по точно таким же причинам, если ваш компьютер привязан к провайдеру (корпоративному или домашнему) по mac-адресу. и также проблема решается nat'ом (хотя можно и proxy arp - никто этой технологии еще не отменял)
Re: Разведение сетевых мостов
Спасибо всем высказавшимся за нехилую информацию к размышлению.
На сей момент пытаюсь реализовать схему с двумя мостами и переключением между ними (например с помощью различных конфигов для одной виртуалки - не суть).
Первый, описанный в самом начале, хочется оставить из-за явного удобства на домашней сетке: Запускаю виртуалку, и она уже доступна по ip/domainname откель хош. Опять же с самбой при нахождении всего в одной подсети проблем нет, что тоже подкупает.
Также сделал мост eth2-dummy, пытаюсь завести на нем. Залез в дебри скрипта vif-bridge. Кой что там придется поправить, т.к. там завязано все на пару eth-peth. Сейчас пытаюсь дотумкать, при каких условиях action online не проходит. add проходит всегда, а online - в зависимости от каких-то глобальных ксеновских настроек
На сей момент пытаюсь реализовать схему с двумя мостами и переключением между ними (например с помощью различных конфигов для одной виртуалки - не суть).
Первый, описанный в самом начале, хочется оставить из-за явного удобства на домашней сетке: Запускаю виртуалку, и она уже доступна по ip/domainname откель хош. Опять же с самбой при нахождении всего в одной подсети проблем нет, что тоже подкупает.
Также сделал мост eth2-dummy, пытаюсь завести на нем. Залез в дебри скрипта vif-bridge. Кой что там придется поправить, т.к. там завязано все на пару eth-peth. Сейчас пытаюсь дотумкать, при каких условиях action online не проходит. add проходит всегда, а online - в зависимости от каких-то глобальных ксеновских настроек
Re: Разведение сетевых мостов
dimbor писал(а): ↑22.12.2011 13:47Также сделал мост eth2-dummy, пытаюсь завести на нем. Залез в дебри скрипта vif-bridge. Кой что там придется поправить, т.к. там завязано все на пару eth-peth. Сейчас пытаюсь дотумкать, при каких условиях action online не проходит. add проходит всегда, а online - в зависимости от каких-то глобальных ксеновских настроек
не получилось у меня обратить вас в свою веру: править vif-bridge не нужно
как говорилось, мост с физическим eth есть в любом случае, и он строится при старте системы, как показано в xen wiki (с поправкой на специфику конфигурации gentoo - /etc/conf.d/net). второй мост (у которого нет физических интерфейсов и который служит в моем случае для виртуальной кластерной конфигурации - всякие там ocfs2 и тп) - строится опять же при старте системы, когда работает xen:
Код: Выделить всё
$ cat /etc/local.d/xen.start
#!/bin/bash
#
if [ "x$RC_SYS" = "xXEN0" ]; then
/etc/init.d/xenstored start
rc=$?
if [ $rc -eq 0 ]; then
/etc/init.d/xenconsoled start
rc=$?
if [ $rc -eq 0 ]; then
/etc/init.d/xend start
rc=$?
if [ $rc -eq 0 ]; then
modprobe dummy
brctl addbr heartbeat
brctl addif heartbeat dummy0
ifconfig heartbeat up
fi
fi
fi
fi
true
комп - "игрушка", и на нем временами работает xen, kvm или просто linux. соответственно в local.d вынесены все сервисы, которые зависят от способа старта системы. на всякий случай поясню, что $RC_SYS это переменная openrc, ее значениее зависит от rc_sys (/etc/rc.conf). если rc_sys закомментировано, то openrc несложным способом угадывает значение переменной $RC_SYS; в случае старта dom0, значением будет XEN0. далее, запускаются управляющие демоны xen и строится второй мост. все просто, короче
в конфигурации domU говорится:
Код: Выделить всё
...
vif = [ 'mac=0a:11:10:24:14:16,bridge=xenbr',
'mac=0a:99:10:24:14:16,bridge=heartbeat' ]
...
все это занудство (наверняка можно сделать красивее и/или по-другому) приводится для того, чтобы доказать, что при вызове vif-bridge (который запускается xend всякий раз при старте domU) никогда не случается параметров online или offline: все нужные мосты построены и настроены без его помощи
hth
Re: Разведение сетевых мостов
Не покаешься - не спасешься, не согрешишь - не покаешься!
Теперь с таким-то руководством все должно получиться, спасибо.
Только вот, как я понял, показывая одновременно оба сетевых интерфейса гостю, обязанность разобраться, с каким работать, на оного же гостя и возлагается? В смысле ip, dns, default route.
Re: Разведение сетевых мостов
приведенный пример имел целью показать как можно стоить мосты без скриптов xen-tools и то, что мостов может быть больше одного (в моем случае один мост - с "физикой", а второй - логический, больше того, dom0 к нему, логически же, отношения вообще не имеет: у dummy0 нет ip адреса - мост нужен для связи domU между собой. такой вот логический heartbeat interface в играх с кластеризацией). также разумеется, что интерфейсы отдаются domU в сконфигурированном количестве, а то как они будут называться определеяется внутри domU (/etc/udev/rules.d/70-persistent-net.rules никто не отменял), равно и то, как они будут использоваться и работать
короче, свою конфигурацию вы придумываете сами