LINUX.ORG.RU
решено ФорумAdmin

Виртуалы не видят друг друга o_O

 ,


1

1

Запускаю две qemu kvm, я их пингую, они меня пингуют, они пингуют интернет, но внезапно, они не видят друг друга в рамках своей же локальной сети построенной на бридже. Может я что-то упустил...

Запускаем две KVM отличающиеся только именами интерфейсов.

for TAP in tap0 tap1; do

  qemu-system-x86_64 -bios OVMF.fd \
    -enable-kvm \
    -snapshot \
    -boot c \
    -drive file=CRUX.qemu-image.raw,format=raw \
    -nic tap,ifname=$TAP

done

Как положено qemu дёргает /etc/qemu-{ifup,ifdown}, содержания:

#!/bin/bash

NETWORK_BRIDGE="br0"
NETWORK_INTERFACE="$1"

/sbin/ip link set $NETWORK_INTERFACE master $NETWORK_BRIDGE
/sbin/ip link set $NETWORK_INTERFACE up

На хост системе в ifconfig виднеются два сетевых интерфейса, tap0 и tap1, без IP-адресов, но в режиме UP, будем считать что так быть и должно(?).

br0 это виртуальный сетевой интерфейс (бридж), который поднимается при запуске хост системы в /etc/rc.local

ip link add br0 type bridge
ip link set br0 up
ip addr add 10.0.0.1/8 dev br0 broadcast +

Которому, конечно, присваивается огроменная подсеть для моего подкроватного энтерпрайза уровня локалхост.

ISC DHCP раздаёт адреса в этой подсети.

subnet 10.0.0.0 netmask 255.0.0.0 {
  option domain-name "VirtualMachine";
  option domain-name-servers 10.0.0.1;
  option routers 10.0.0.1;

  range 10.0.0.2 10.255.255.254;
}

Простым запуском qemu без всяких параметров можно убедиться что оно работает, нажать Ctrl + B для захода в консоль SeaBIOS'а и выполнить dhcp, и убедиться что IP-адрес выдал именно наш DHCP, работающий на br0.

Ну и iptables, в том же /etc/rc.local, который всё это дело маршрутизирует.

WAN=enp2s0 # интерфейс с интернетами провайдера

iptables -P FORWARD DROP
iptables -t filter -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A FORWARD -i br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -o $WAN -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

Так почему же виртуальные машины не видят друг друга, но видят интернет, и я вижу их с хост системы?

★★★★★

Внезапно! Оказывается машины не видят друг друга из-за одинаковых MAC-адресов, которые QEMU выдаёт по-умолчанию, всем одинаковые... Нафига? Ну да хер с ним. Пусть выдаёт.

Добавил параметр mac в опцию -nic tap,ifname=$TAP,mac=00:00:00:${RANDOM:0:2}:${RANDOM:1:2}:${RANDOM:2:2} и всё заработало.

Гы!

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от Spoofing

Есть мнение, что стоит посмотреть в сторону libvirt ( графическая морда virt-manager, консольная - virsh )

А по сетям в сторону openvswitch

router ★★★★★
()
Ответ на: комментарий от router

а расскажите пожалуйста зачем оно нужно.

я в автозапуск засунул такое for i in $(seq 1 100500); do qemu-system-x86_64 -nic tap -display none -daemonize; done

оно мне запускает мильён виртуалок. вру, не мильён, всего-лишь 100500.

вы спросите, а где же -drive? а нинужно! почему? потому что всё настроено чтобы работало автоматически!

-nic tap запускает интерфейс tapX, скрипт ifup который дёргает сам qemu (из коробки) добавляет этот tapX в бридж, на бридже висит dhcp который раздаёт айпишники, значит на самом старте qemu со своим seabios уже получает айпишник. что она делает дальше? пытается загрузиться по сети! и получает всё необходимое из сетевых настроек того же dhcp, затем грузит образ c tftp и вуаля, 100500 рабочих и уже настроенных виртуалок!

люблю, когда программы всё делают сами, только настроить их в соответствии со стандартами. когда не нужно передавать кучу параметров в командой строке, а если существует инфраструктура и она настроена правильно — всё просто работает. в данном случае qemu запускается по сути без параметров, подхватывает настройки сети и дальше пошло-поехало.

посоветуйте пожалуйста если знаете, чем это всё дело теперь оркестрировать? 100500 виртуалок. :)

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от Spoofing

вы спросите, а где же -drive? а нинужно! почему? потому что всё настроено чтобы работало автоматически!

Данные хранить тоже не нужно? Или там еще и хранилище по сети цепляется?

deadNightTiger ★★★★★
()
Ответ на: комментарий от router

пикрелейтед http://dump.bitcheese.net/files/jahonik/scrot.png

посмотрел этот openvswitch, даже пересобрал ядро включив [M] openvswitch, скачал сорцы, собрал...

и оно работает. но какой-то разницы или удовлетворения по сравнению с обычным linux bridge я не ощутил. я наверное ретроград, но чем решение проще тем оно вернее, имхо.

кстати тут как раз описан мой случай. удобно. http://docs.openvswitch.org/en/latest/howto/kvm/

linux bridge в линуксах из коробки. openvswitch это не только модуль ядра, который кстати не захотел быть не-модулем, а ещё и пакет отдельных утилит, который требует python как минимум для сборки (у меня требовал python-six). ну такое себе.

это я всё придираюсь.

вот прям чтобы офигеть какой must have в openvswitch я не увидел. всё что надо — умеют делать и так linux bridge.

virt-manager требует qt4, придётся собирать и тащить в свой уютненький CRUX... ладно, посмотрим.

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от Spoofing

вот прям чтобы офигеть какой must have в openvswitch я не увидел. всё что надо — умеют делать и так linux bridge.

сотню виртуалок, на каждую по сотне правил (ip/eb)tables и результат будет заметен невооруженным глазом :)

ktk ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.