LINUX.ORG.RU
ФорумAdmin

QEMU bridged networking

 , ,


0

3

Надо в домашней локальной сети поднять {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
()
Ответ на: комментарий от explorer

Вы путаете. Речь не про libvirt. Простой запуск qemu.

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

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

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

Тогда достаточно для VM добавить tap интерфейс в бридж.

Это эквивалентно этому:

ip link add br0 type bridge
ip tuntap add dev tap0 mode tap
ip link set dev tap0 master br0

Но оно же работать не будет?

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

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

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