Доброго дня! Этап первый: Сделал все по http://wiki.openvz.org/DHCP Что-то мне подсказывает, что у меня не проходят пакеты или что-то работает не так. В контейнере, который общается с миром без проблем имеем: eth0 Link encap:Ethernet HWaddr 00:18:51:46:05:14 inet addr:195.xxx.xxx.7 Bcast:195.xxx.xxx.15 Mask:255.255.255.240 inet6 addr: fe80::218:51ff:fe46:514/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20360 errors:0 dropped:0 overruns:0 frame:0 TX packets:20540 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:7820921 (7.4 MiB) TX bytes:8543646 (8.1 MiB) дальше # cat /etc/dhcpd.conf # # DHCP Server Configuration file. # see /usr/share/doc/dhcp*/dhcpd.conf.sample # option domain-name "xxx.ru"; option domain-name-servers 128.xxx.xxx.185, 204.xxx.xxx.10; option routers 195.xxx.xxx.1; ddns-update-style none; server-name "DHCPserver"; server-identifier 195.xxx.xxx.7; default-lease-time 600; max-lease-time 7200; authoritative; log-facility local7; allow booting; allow bootp; subnet 195.xxx.xxx.0 netmask 255.255.255.240 { option subnet-mask 255.255.255.240; option broadcast-address 195.xxx.xxx.15; range 195.xxx.xxx.11 195.xxx.xxx.14; # next-server 195.xxx.xxx.1; # Linux filename "pxelinux.0"; ## FreeBSD # filename "pxeboot"; # option root-path "/var/freebsdboot"; # NFS root path } Этап второй (Проверяем работу DHCP сервер): Отдельный физический сервер с: DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:15:17:b4:0f:78 ONBOOT=yes Запросы отсылает; со статическим IP общается с миром. Но по DHCP не может получить настройки. Смотрел tcpdump на нем, запросы есть - ответов нет. На HN и VE с DHCP запросов tcpdump'ом не увидел. На HN: veth121.0 Link encap:Ethernet HWaddr 00:18:51:F1:A0:AB inet6 addr: fe80::218:51ff:fef1:a0ab/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20850 errors:0 dropped:0 overruns:0 frame:0 TX packets:20615 errors:0 dropped:2 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:8592032 (8.1 MiB) TX bytes:7848031 (7.4 MiB) vzbr0 Link encap:Ethernet HWaddr 00:18:51:F1:A0:AB inet6 addr: fe80::218:51ff:fef1:a0ab/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28655 errors:0 dropped:0 overruns:0 frame:0 TX packets:29274 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9059162 (8.6 MiB) TX bytes:11460552 (10.9 MiB) Может чего выпустил из виду? Не учел? Даже если PXE нельзя поднять на VPS, то как заставить работать DHCP? P.S. Видел конечно тему http://forum.openvz.org/index.php?t=msg&goto=35563&& amp; amp;srch=dhcp#msg_35563 с немецким немного туговато, так что могу только догадываться, что такое сделать невозможно... хотя возможно там обратная сторона вопроса! P.P.S. А все-таки PXE реально на VE поднять? P.P.P.S По материалам http://wiki.opennet.ru/NetworkBoot
Поправка на eth0 карте HN запросы есть: # tcpdump -nni eth0 udp and port 67 or 68 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 17:44:46.340824 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:15:17:b4:0f:7a, length: 300 17:44:57.340941 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:15:17:b4:0f:7a, length: 300 а вот на бридже их уже нет: # tcpdump -nni vzbr0 udp and port 67 or 68 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vzbr0, link-type EN10MB (Ethernet), capture size 96 bytes 0 packets captured 0 packets received by filter 0 packets dropped by kernel Может надо какую-нибудь опцию включить?
gralex wrote on Wed, 31 March 2010 16:08 как заставить работать DHCP? Ответ тут: http://forum.openvz.org/index.php?t=msg&th=5225&#msg _26543 решение (?): brctl addif vzbr0 eth0 На самом vzbr0 есть назначенный статический IP, по которому HN так же доступен! Чего-то опять не учел?! После добавления eth0 в бридж, пропадает сеть ((( При этом VE с veth121.0 доступен. А HN нет.
PXE мы все-таки решили держать на KVM-виртуалке veth тормозной какой-то и не очень производительный (субъективное впечатление) Для того, что бы в OVZ работала veth сеть, мы снимали IP, маску и прочее с eth[0-9] интерфейса, и настраивали сеть на самом бридже. Естественно, должны быть разрешены форварды
Благодарю за ответ! Уже тоже думали о таком варианте. Одно останавливает. Будет ли при этом работать сеть у других VE, которые используют обычные VENET? А какая KVM используется, если не секрет?
) Речь не об IP-KVM, а о гипервизоре, или Вы это и имели ввиду? Да, гипервизор и виртуалки на совсем другом сервере
Подумал как раз о IP-KVM. Сейчас некоторые идут с поддержкой virtual media (через USB) как раз для таких случаев. Но как их использовать под UNIX не понятно. Документация есть только под винду на моделях, которые у нас, поэтому особо разбираться в этой виртуал медиа не стали. Сейчас перечитал предыдущий пост и понял что выразился не точно. Имел в виду, если все с eth0 перенести на br0, будет ли при этом работать сеть у других VE, которые используют обычные VENET?
gralex wrote on Fri, 02 April 2010 11:43 Подумал как раз о IP-KVM. Сейчас некоторые идут с поддержкой virtual media (через USB) как раз для таких случаев. Но как их использовать под UNIX не понятно. Документация есть только под винду на моделях, которые у нас, поэтому особо разбираться в этой виртуал медиа не стали. Для удаленной установки в другой дата-центр (где-нибудь в Европе), мы как раз используем VirtualMedia в связке со сгенерированным Cobbler загрузочным диском (им же ставим по PXE) При этом технологии IPMI вообще безразлично, что за ОС установлена на сервере Кстати, в Linux IPMI, по большей части клиентская часть для того же мониторинга, без проблем поддерживается уже не один год. gralex wrote on Fri, 02 April 2010 11:43 Сейчас перечитал предыдущий пост и понял что выразился не точно. Имел в виду, если все с eth0 перенести на br0, будет ли при этом работать сеть у других VE, которые используют обычные VENET? Лучше использовать venet, он гораздо, имхо, стабильнее себя ведет при больших лоэдах. Ничто не запрещает коомбинировать venet и veth, мы так делали, пока не стандартизировали OVZ-серверы (теперь veth вообще не используем)
Благодарю за разъяснения. Будем изучать варианты. Сейчас только начали рассматривать варианты удаленной и автоматизированной установки ОС.
sHaggY_caT wrote on Fri, 02 April 2010 18:49 Для того, что бы в OVZ работала veth сеть, мы снимали IP, маску и прочее с eth[0-9] интерфейса, и настраивали сеть на самом бридже. Естественно, должны быть разрешены форварды Удалось все это дело запустить, благодарю. Один момент с наскоку не удалось решить. Если при рестарте HN/VE интерфейс veth в бридж добавляется скриптом отдельным. То чтобы добавить eth0 в бридж тоже есть скрипт? Или готовых решений нет?
Смотря какой дистрибутив используете. Для RH решение типовое - через /etc/sysconfig/network-scripts/ . Например, создать при загрузке бридж, присвоить ему IP и добавить в него eth0: ifcfg-br0: DEVICE=br0 TYPE=bridge ONBOOT=yes IPADDR=10.2.0.1 NETMASK=255.255.255.0 ifcfg-eth0: DEVICE=eth0 ONBOOT=yes BRIDGE=br0
Есть, конечно, вот пример для RHEL/CentOS/Fedora: [root@kvm-test01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 HWADDR=00:19:66:B2:FB:68 ONBOOT=yes BRIDGE=virbr1 [root@kvm-test01 ~]# cat /etc/sysconfig/network-scripts/ifcfg- ifcfg-eth0 ifcfg-lo ifcfg-virbr1 [root@kvm-test01 ~]# cat /etc/sysconfig/network-scripts/ifcfg-virbr1 DEVICE=virbr1 TYPE=Bridge ONBOOT=yes BOOTPROTO=static IPADDR=10.0.5.129 NETMASK=255.255.255.0 DNS1=10.0.5.17 [root@kvm-test01 ~]#
2 RXL_ Не заметила Ваш ответ...
sHaggY_caT wrote on Sun, 04 April 2010 12:08 2 RXL_ Не заметила Ваш ответ... Зато ответ получился вдвойне точный
sHaggY_caT, RXL_, благодарю за ответы Заметил одну вещь теперь при рестарте сети на HN, слетают маршруты для VE, которые используют venet. Это можно как-то исправить без добавления маршрутов в /etc/sysconfig/network-scripts/ ?
Маршруты удаляются, когда имеют зависимости от опускаемого интерфейса. Вполне логично, что если вы рестартуете service network, то рестартуют все интерфейсы, включая venet0. Зачем это вообще делать? - Перезапускайте конкретные интерфейсы посредством ifdown/ifup. Но если вам нужно прописывать маршруты при перезагрузке HN, то пишите их в /etc/sysconfig/network-scripts/route-${DEVICE}
В общем закончил все это дело по инструкции http://wiki.centos.org/EdHeron/PXESetup Без использования NFS, реализация которого в VE требует дополнительных усилий. HTTP/FTP проще поднять, чем NFS в VE))) RXL_, до использования бриджа маршруты не слетали при перезапуске сети.