[Comm] OpenVZ @ server-4.0.1 - большие проблемы

[Comm] OpenVZ @ server-4.0.1 - большие проблемы

[seriv]

(posted to community@ and sysadmins@)

Прошу помощи.

Раньше ни разу не требовалось организолыввать VEs соединённые с двумя разными сетями. В моём случае - это локальная сеть с 10.*.*.* адресами и WAN, честные статические ipv4 адреса. Установлен Server-4.0.1 + updates.

Я попробовал делать всё согласно описанному в http://www.freesource.info/wiki/SergeyLebedev/EisSystem/RootSystemEIS& - то есть с помощью bridges. Устроил vzbr0, отнял у eth0 его ipv3address заменив на 0.0.0.0 и передал этот адрес интерфейсу vzbr0. 

Потом устроил default route для vzbr0.

Всё пробовал и /sbin/service/network restart отрабатывало замечаательно, вплоть до того что при помощи скриптов из 
http://wiki.openvz.org/Using_private_IPs_for_Hardware_Nodes (конкретнее - скрипта /usr/sbin/vznetcfg.custom) e моём VE создавался интерфейс eth0, добавлялся к bridge vzbr0, устраивались routes.

Затем, перед тем как доделать то же самое для другой сети, решил дпя проверки перезагрузить сервер. И он не появился в сети! 

Спустя несколько дней к нему поехали на colocation, попытались перезагрузиться и вручную запустить сеть и sshd чтобы я мог увидеть что случилось и поправить. Увы, сервер расположен не в моей часовой зоне, и видимо ночью я соображаю плохо.

Первое что я осознал - это что мои bridge devices vzbr0 и vzbr1 дописаны в /etc/iftable и забирают у eth0/eth1 карточки по макадресам, так что eth0/eth1 подняться не удеётся вовсе. Так что /sbin/ifconfig eth0 10.16.0.12 говорит 'fetching interface information - device not found'

Попросил перезагрузиться в runlevel 1. Потом ifconfig, service sshd start. После этого смог соединиться удалённо. Обнаружил vzbr{0,1} в /etc/iftable Решив вначале создать для сбе "гарантии" против повторных таких проблем. Написал сходу что-то типа (сейчас по памяти воспроизвожу):
---
#!/bin/bash
## /root/bin/10.sh - script to bring up interface up if it ifrenamed to anything but vzbr*

NAME=`ifconfig -a | grep '00:04:05:06:07:08' |grep -v '^vzbr' | awk '{print $1}'` 

if ! ping -c 1 -I $NAME >/dev/null 2>&1 
then
   ifconfig $NAME 10.16.0.12/24
fi
---
(вместо реального макадреса написал произвольную последовательность цифр).

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

Сделал такой же скрипт для WAN.

И перезагрузил опять мошину. Это было вчера. Теперь вот надо будет опять организовывать чтобы к ней поехали и восстанавливали вручную.


   Прошу подсказать, как надо настраивать OpenVZ, etcnet и bridges в такой ситуации. Прошу покритиковать то что я делал

-- 

   Сергей Иванов.

Re: [Comm] OpenVZ @ server-4.0.1 - большие проблемы

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Mon, Feb 11, 2008 at 10:25:50AM -0500, seriv@parkheights.dyndns.org wrote:
> Первое что я осознал - это что мои bridge devices vzbr0 и vzbr1 дописаны
> в /etc/iftable и забирают у eth0/eth1 карточки по макадресам, так что
> eth0/eth1 подняться не удеётся вовсе. Так что /sbin/ifconfig eth0
> 10.16.0.12 говорит 'fetching interface information - device not found'

В подобных случаях лучше привязывать имена физических интерфейсов не к
mac, а к другим параметрам - например, к businfo (в большинстве случаев
получается привязка к слоту, хотя иногда businfo всё-таки может меняться -
например, при добавлении карты с мостом PCI-PCI).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]