LINUX.ORG.RU
ФорумAdmin

QEMU bridged networking

 , ,


0

2

Надо в домашней локальной сети поднять {git,ssh,web}-сервер внутри ВМ, но так, чтобы ВМ получила адрес из той же сети, что и хост. Причём адрес должен быть статическим (допустим, 192.168.1.10). Выполнил то, что описано здесь, и всё вроде бы работает, но возникает несколько вопросов. Во-первых, в этой документации, как и в некоторых других гайдах, сказано, что QEMU в данной случае должна запускаться с правами рута. Так ли это? Потому что даже с запуском от обычного пользователя всё работает вроде бы так же — пакеты бегают в обе стороны. И если рутовые права необязательны, то не лучше ли запускать QEMU через отдельного для этого дела сделанного юзера с ограниченными правами?

Во-вторых, запуская QEMU командой

qemu-system-x86_64 -enable-kvm -m 512M -boot d -cdrom image.iso -netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no -device e1000,netdev=mynet0,mac=14:88:14:88:14:87

я получаю IP-адрес по DHCP, а хотелось бы один и тот же статический иметь всегда (на который роутером перенаправляется трафик извне) — как это сделать?

я получаю IP-адрес по DHCP, а хотелось бы один и тот же статический иметь всегда (на который роутером перенаправляется трафик извне) — как это сделать?

Варианты:
1. На dhcp сервере привяжите нужный ip к маку vm
2. Урезать на dhcp сервере пул например до .200 и в vm прописать адрес выше .200 статикой.

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

Второй вариант предпочтительнее

и в vm прописать

а это делается только внутри самой ВМ средствами того же iproute, например? В смысле, не нужно qemu указывать ещё что-то или на хосте настраивать что-то дополнительно для tap или bridge интерфейсов? Если не нужно, то всё настроено уже, получается. Ручками только внутри ВМ прописать статику.

Буду благодарен, если ещё ткнёте на хороший текст с разъяснением принципов работы tun/tap, bridge interfaces.

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

У вас бридж как вы описали. Замените в конфиге своей VM получение с dhcp на статику. Этого достаточно.

tun/tap

А вот это «два разных человека». tun L3 а tap L2. В вашем случае используется tap который входит в бридж и с учетом того что он получает адрес по dhcp, у вас все настроено верно. Разницы между статиком и dhcp будет ровно ноль.

ЗЫ Я для кучи тестовых поддиванных VM-ок использую первый вариант. Просто удобнее, забыл IP всегда с конфиге можно посмотреть, я добавляю комменты «что это» :)

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

tun L3 а tap L2

Да, это я понимаю.

кучи тестовых поддиванных VM-ок

А запускаете ВМ-ки вы из под рута или нет? Почему-то везде пишется, что иначе не будет работать вариант с сетью с использованием tap (не будет прав на что?).

Ещё по ссылке с сайта qemu пишут:

Creating multiple bridges per interface is known (anecdotally) to be problematic; instead, create a tap for each virtual machine using a single bridge for each physical device to be used.

Т. е. если виртуальных машин несколько, то мне нужно сделать по tap интерфейсу на каждую, «соединить» их с мостом, причём один мост должен быть связан с не более чем одним физическим интерфейсом?

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

А запускаете ВМ-ки вы из под рута

Ага.

Почему-то везде пишется, что иначе не будет работать вариант с сетью с использованием tap (не будет прав на что?)

Добавление интерфейса в бридж если нужно автоматом.

Т. е. если виртуальных машин несколько, то мне нужно сделать по tap интерфейсу на каждую, «соединить» их с мостом, причём один мост должен быть связан с не более чем одним физическим интерфейсом?

Да. Но можно и не прописывать ifname=tap0. А прописать скрипты script= это на старт виртуалки, downscript= на остановку а в них прописать поднятие линка и добавление в бридж, и наоборот.
Как раз здесь мне кажется и зарыта собака в части требований рут прав. Но если вы за ранее поднимите интерфейсы возможно и без рута работать будет, честно говоря не пробовал.

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

Но если вы за ранее поднимите интерфейсы возможно и без рута работать будет, честно говоря не пробовал.

Да нормально работает. Если надо определенный набор виртуалок на хосте, когда интерфейсы не надо метать туда-сюда между бриджами, то почему бы и не сделать системно. А скрипты из script= так себе защита, по сути будет тот же sudo, а рисовать всякую защиту по поводу «это вызвано из бинаря qemu», «набор интерфейсов из допустимых», «конфигурация неошибочна» — можно долго, нудно и как-то беспонтово натурально.

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

А скрипты из script= так себе защита

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Только про удобство

Я думал, что будет удобно, но оказалось, что если скриптов парочка постоянных, то в систему удобнее, а если не постоянные, то удобнее действительно дать десяток tunctl -u user и sudo на brctl :)

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

Не очень понял, о как здесь защите речь.

А скрипты из script= так себе защита

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

ottomencke ()
Ответ на: комментарий от anc

Работает всё как будто бы нормально, перед стартом ВМ делаю:

ip link add br0 type bridge
ip tuntap add dev tap0 mode tap
ip link set dev tap0 master br0   # set br0 as the target bridge for tap0
ip link set dev ${IFACE} master br0   # set br0 as the target bridge for eth0
ip link set dev br0 up
ip a add dev br0 ${IPNMASK}
ip link set dev tap0 up

После выключения делаю:

ip link set dev tap0 down
ip tuntap del dev tap0 mode tap
ip a del dev br0 ${IPNMASK}
ip link set dev br0 down
ip link del dev br0

Через некоторое время на хосте связь с внешним миром теряется, запросы наружу не ходят, только в локалке (192.168.1.1/24). При этом в ВМ всё ок, всё работает нормально. В чём проблема может быть?

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

Подождите. У вас один бридж с локальным физическим интерфейсом. Я правильно понимаю?
Тогда достаточно для VM добавить tap интерфейс в бридж. Все остальное излишество.

anc ★★★★★ ()

Может что-то такое, т.е. юзера указать, чтобы с правами не было косяков? ip tuntap add mode tap tap0 user «юзер»

Можно пойти дальше и нагородить огород с присвоением tap IP.

И если рутовые права необязательны, то не лучше ли запускать QEMU через отдельного для этого дела сделанного юзера с ограниченными правами?

Я бы еще добавил юзера в группу libvirt-qemu и в kvm, если используешь kvm и вписал бы в qemu.conf юзера и группу kvm, тогда все будет шоколадно с правом записи в расшаренные папки без рута.

explorer ()
Ответ на: комментарий от ottomencke

При старте системы вы поднимаете br0 в него включаете eth (и при желании tap0) назначаете br0 ваш ip.
Либо tap можно добавлять перед стартом виртуалки.

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

На моем примере. При старте системы в бридж добавлен только eth0 я про старт хоста.
При старте qemu в скрипте только
ip link set $1 up
brctl addif br0 $1
где $1 это выделенный tap интерфейс.

anc ★★★★★ ()