Preface
Жил-был на сервере Xen hypervisor, виртуальные машины крутил, по сети трафик гонял, ни о чём не думал.
Сеть жила через xenbr0, который обьединял eth0 и виртуальные интерфейсы.
Кроме eth0 был на сервере ещё один интерфейс — eth1. Который за ненадобностью не использовался.
И вот в связи с умиранием роутера — решил админ через eth1 пускать свою локалку в Сеть.
Недолго думая поднял eth1, воткнул провайдерский шнурок, байтики потекли — хорошо…
Но случилось страшное — ребут. После ребута xenbr0 напрочь отказался подниматься, мотивируя это тем, что интерфейс ppp0 занят…
«При чём здесь ppp0» — подумаете вы — и будете правы.
Админ тоже так же подумал. И начал маны читать и в скриптах ксеновских ковыряться.
Вот что наковырял
Схема сети у Xen простая, как дверь.
При старте xend дёргает скрипт (по-умолчанию — /etc/xen/scripts/network-bridge), который делает следующее:
1. Создаёт мост xenbr0
2. Тушит физический eth0
3. Копирует IP и MAC физического eth0 на виртуальный интерфейс veth0
4. Переименовывает физический eth0 в peth0
5. Виртуальный veth0 переименовывает в eth0
6. peth0 и vif0.0 цепляет на xenbr0
7. Поднимает xenbr0, peth0, eth0 и vif0.0
Это в теории. А на практике скрипт почему-то пытался все действия произвести с ppp0.
Происходит это потому, что скрипт по-умолчанию работает с интерфейсом, который у нас default route.
Ладно, не беда, добрые разработчики предусмотрели это — /etc/xen/scripts/network-bridge можно запускать с параметрами.
Примерно так:
/etc/xen/scripts/network-bridge start bridge=xenbr0 netdev=eth0
То есть жёстко задавать интерфейс, через который мы будем работать. Причём у меня скрипт почему-то отказался тушить eth0 сам — пришлось ему помогать руками…
Исходя из вышенаписанного — решение проблемы оказалось довольно простым.
Практика
Тушим eth0
ifconfig eth0 down
Конфигурим мост
/etc/xen/scripts/network-bridge start bridge=xenbr0 netdev=eth0
Поднимаем мост (скрипт почему-то и этого не сделал)
ifconfig xenbr0 up
Всё, байтики от виртуальных машин пошли в локальную сеть и интернет.