LinuxForum.Fans
Тема

KVM + VDE в Fedora

Автор: Cruiser78 42 сообщений 9802 просмотров
#265065

Привет всем!

Что то я немного туплю с настройкой сети КVM. А именно, начало вопроса здесь: http://linuxforum.ru/viewtopic.php?id=23274 Далее - курим интернет, конференцию и приходим к выводу, что можно для организации сети под мои особенности применить виртуализацию сетевого интерфейса с помощью VDE-2.
Итак, имеем RFR-15, libvirt 9.13. К нему virt-manager 0.9.1. IP-форвардинг включен.
устанавливаем пакет VDE следующим образом:

text
svn co https://vde.svn.sourceforge.net/svnroot/vde/trunk/vde-2 vde_svn
cd vde_svn
autoreconf -fi
./configure --enable-kernel-switch && make && make install

Проблем с этим нет. Далее делаем:
[console] #vde_tunctl -t tap0 [/console]
На выходе - молчание, ifconfig интерфейса tap0 не показывает. Но, думаем, что интерфейс создан.
Далее делаем на tap0 свитч:
[console] #vde_switch -x -n 5 -s /run/vde2/vde.ctl -g vde2-net -m 770 -d -p /run/vde2/vde.pid -t tap0 [/console]
Сообщений опять нет никаких, думаем, что свитч поднимается в заданной конфигурации. Но ifconfig все равно нам ничего не показывает. Делаем дальше, как написано в VDE README-файле:
[console] #ifconfig tap0 192.168.43.208 up[/console]
То есть назначаем на бридж tap0 сетевой адрес. Только после этого ifconfig нам показывает интерфейс tap0.

Далее - настраиваю сеть виртуальных машин через virt-manager. И тут то и приходит нам пушной зверек. Выбираю там в интерфейсе при настройке сетевого моста tap0, ставлю инфтефейс virtio, пытаюсь запустить гостя и ролучаю окно с текстом:

text
Ошибка запуска : Unable to add bridge tap0 port vnet1: Неподдерживаемая операция

При этом в расшифровке дополнительно сообщается:

text
Ошибка запуска : Unable to add bridge tap0 port vnet1: Неподдерживаемая операция
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 66, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1114, in startup
    self._backend.create()
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 620, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Unable to add bridge tap0 port vnet1: Неподдерживаемая операция

То есть libvirt откровенно (как я понимаю) не хочет видеть мост tap0, который поднят средствами VDE. При этом, tap0 пингуется (адрес то есть) и через него можно зайти на тестовую машину, где он поднят, по ssh. То есть, оно работает...
Ладно, морщим лоб и пытаемся через brctl поднять мост br0 на tap0. Проблем с этим не возникает, в результате имеем:
[console]# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.ea68fb6bac9e yes tap0
virbr0 8000.52540022d39f yes virbr0-nic
#ifconfig
.....
tap0 Link encap:Ethernet HWaddr EA:68:FB:6B:AC:9E
inet addr:192.168.43.208 Bcast:192.168.43.255 Mask:255.255.255.0
inet6 addr: fe80::e868:fbff:fe6b:ac9e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:4881 (4.7 KiB)

virbr0 Link encap:Ethernet HWaddr 52:54:00:22:D3:9F
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:936 errors:0 dropped:0 overruns:0 frame:0
TX packets:676 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:65337 (63.8 KiB) TX bytes:77317 (75.5 KiB)
[/console]
Снова настраиваем в virt-manager сетевой интерфейс. Пишем там имя моста br0, после чего гостевая ось (CentOS) запускается. Но... там, унутре гостя, сетевой его интерфейс болтается "в воздухе", выхода через него во внешний мир нету никакого.
Коллеги, спинным мозгом чую, что истина где то рядом. Наведите на решение проблемы. Почему KVM не хочет видеть мосты VDE на Fedora?
И, кстати, после установки VDE virt-manager об интерфейсах macvtap забыл напрочь...

#265067

эх, сколько извращений, лишь бы не докупить сетевушку :)

#265089
dyasny написал:
эх, сколько извращений, лишь бы не докупить сетевушку :)

Сразу виден подход системного интегратора, обученного решать проблемы через закупку дополнительного оборудования, а не оптимизацию существующего. :)

А по дело то есть что сказать?
-----------------
Кстати, обратил еще и на одну малоприятную вещь. Если в libvrt из репозиториев RFR-15 (на ней тренируюсь), версия 8.8, можно было создавать виртуальные сети и привязывать их к произвольному физическому интерфейсу (что, вообще то правильно), то в версии 9.13 (последней) - этой возможности нет. Можно создать виртуальную сеть, но дуть она будет во все интерфейсы. Это только я один замечаю, или и у других тоже самое?
Далее, куда-то в 9.13 пропал способ подключения macvtap. Вполне возможно, он и лишний, тем более всегда можно указать имя моста (сети) к которому виртуальная машина цепляется. Но, все таки - если macvtap-интерфейс был создан в версии 8.8, то он в версии 9.13 пишется как "Direct tap0", например. А вот новые интерфейсы 9.13 - те только через мост...

#265121
"Cruiser78" написал:
Сразу виден подход системного интегратора, обученного решать проблемы через закупку дополнительного оборудования, а не оптимизацию существующего

честно говоря очень мало работал конкретно интегратором. а вот сисадмином у которого под рукой много сотен серверов и мало времени был достаточно, и это подход который в первую очередь экономит время, плюс берет оптимальное по эффективности и простоте решение

macvtap имеет смысл в случае использования 802.1Qbg/h и тогда либвирт сам его создает. а просто так он, как и VDE не годится для нормальной работы.

когда пройдет интеграция с quantum и ovs, добавится еще один способ (а точнее библиотека с кучей плагинов для любого кто захочет впилить свой способ), а до тех пор бриджи и NAT - предел либвирта

#265128
dyasny написал:

честно говоря очень мало работал конкретно интегратором. а вот сисадмином у которого под рукой много сотен серверов и мало времени был достаточно, и это подход который в первую очередь экономит время, плюс берет оптимальное по эффективности и простоте решение

У меня ситуация обратная. Серверов мало, а времени свободного - гораздо более. То, что с третьей картой всё заработает у меня сомнений нет. Да и вопрос, собственно не про macvtap, а больше про VDE. Дополнительный tap-интерфейс создается. причем - рабочий, к нему из "внешнего мира" обратиться можно. Но вот непонятно, как подвязаться к нему штатными гуевыми редствами штатного virt-manager'a

#265129
"Cruiser78" написал:
На выходе - молчание, ifconfig интерфейса tap0 не показывает. Но, думаем, что интерфейс создан.

Зачем думать? ifconfig -a покажет не поднятые интерфейсы.

"Cruiser78" написал:
Далее - настраиваю сеть виртуальных машин через virt-manager.

Уж определись virt-manager - в топку, если пользуешь vde2.
ы. Какой мост? поднял вирт свитч, настраивай iptables. Виртуалки напрямую к свичу вешай. (-net nic -net vde,sock=/run/vde2/vde.ctl)
ыы. Зачем из исходников?

#265144
"Cruiser78" написал:
Но вот непонятно, как подвязаться к нему штатными гуевыми редствами штатного virt-manager'a

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

#265163
newzenon написал:

Уж определись virt-manager - в топку, если пользуешь vde2.

Недостаток знаний приводит к неверным выводам. Завтра раскурим полезный совет. Мне, главное, направление мысли - куда копать надо. Вопрос - то, что в скобках - это аргументы какой команды в контексте федоры?

newzenon написал:

Зачем из исходников?

Отдельно взятая умная личность подцепила в зависимостях в linvirt весьма неплохую штуку - glusterfs (на всякий случай, шоб було). Беда только в том, что в репах штатных этот пакет имеет уж очень давнюю версию. И имена пакетов той давней версии не совсем соответствуют тем, что есть в настоящее время. Если бы я не использовал у себя на своих серверах почти последнюю версию гластера, то и фиг бы с ним. Пусть тащилось бы старье из репов. А так - чтобы поставить libvirt из репов надо очень сильно кувыркаться вокруг эксплуатируемого гластера. Проще взять последнюю версию паета с оффсайта, подправить spec, выбросить (как минимум) из него эту вредную мне зависимость и поставить свой rpm. Это по поводу libvirt. По поводу VDE-2 - yum не находит такого пакета в штатных репозиториях федоры. Следовательно пути опять стандартны - или искать репозиторий с vde, либо брать исходники (последнюю стабильную версию) с официального сайта и компилировать пакет из них.
Так что, работа с исходниками - не от хорошей жизни.

#265168
"Cruiser78" написал:
Вопрос - то, что в скобках - это аргументы какой команды в контексте федоры?

Тут писал
пример с kvm

text
# kvm -m 1024 -k ru -localtime -net nic -net vde,sock=/run/vde2/vde.ctl -hda zsn.img
#265169

ы:

text
#!/bin/bash
IPT="/sbin/iptables -v"
MPB="/sbin/modprobe"

modprobe kvm modprobe kvm-amd modprobe kvm-intel vde_tunctl -t tap0 ifconfig tap0 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 up ifconfig tap0 mtu 1400 vde_switch -x -n 5 -s /run/vde.ctl -g kvm -m 770 -d -p /run/vde.pid -t tap0 /etc/init.d/dhcpd start

# Туд-сюда $IPT -A FORWARD -i eth0 -o tap0 -j ACCEPT $IPT -A FORWARD -i tap0 -o eth0 -j ACCEPT # Маскарад $IPT -t nat -A POSTROUTING -o eth0 -s 192.168.2.0/24 -j MASQUERADE kvm -m 1000 -localtime -net nic -net vde,sock=/run/vde.ctl -hda debian-wheezy-i386.img &

думаю понятно.

#265176
newzenon написал:
думаю понятно.

Все это понятно. Непонятно чуток иное. Я же не сразу на компиляцию исходников перешел. Вначале было сделано:
[console]yum groupinstall "Virtualization"[/console]

И среди прочего было установлено и это:

[console]# rpm -qa | grep kvm
qemu-kvm-0.13.0-1.fc14.x86_64
# rpm -qa | grep qemu
qemu-img-0.13.0-1.fc14.x86_64
qemu-kvm-0.13.0-1.fc14.x86_64
gpxe-roms-qemu-1.0.1-3.fc14.noarch
qemu-system-x86-0.13.0-1.fc14.x86_64
qemu-common-0.13.0-1.fc14.x86_64
[/console]

Но вот программы (скрипта) под именем kvm там не приехало в пакетах. Отсюда и вопрос выплыл. Что есть kvm в контексте Fedora?. Ну или иначе - в каком пакете он живет?

Ну и второй вопрос. Мне надо, чтобы мои виртуальные сервера сидели в локальной сети. И были оттуда юзерям доступны. То есть это должна быть одна IP-сеть. Если ставим маскарадинг на eth0, то этим самым подразумеваем, что виртуальная сеть не совпадает с юзерской IP-сетью. Выход из виртуальной сети будет с адреса eth0, но вот войти в неё, достучаться до виртуального сервера - проблемно... Есть решение этой проблемы? Я полагал дать адрес tap0 из сети, обслуживаемой eth0, и на этом успокоиться. Или это неправильное решение?

#265190
"Cruiser78" написал:
Что есть kvm в контексте Fedora?. Ну или иначе - в каком пакете он живет?

qemu-kvm

#265234

А говоришь понятно:

"Cruiser78" написал:
То есть это должна быть одна IP-сеть.

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

"newzenon" написал:
text
# Туд-сюда 
$IPT -A FORWARD -i eth0 -o tap0 -j ACCEPT 
$IPT -A FORWARD -i tap0 -o eth0 -j ACCEPT

Форвард можно разрешать/запрещать также по подсетям.
/
ы. После того как поднял виртуальный свитч - он ничем не отличается от железки... :)

#265269
newzenon написал:

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

Да нет, это ты не совсем понял. Это мне _надо_ чтобы два интерфейса, физический, eth0, и виртуальный, tap0, были в одной физической локальной IP-сети. Чтобы их адреса принадлежали одной IP-сети.

Но, все равно, не завелось из кАроПки... А именно, получил следующую неприятность:
[console]# qemu-kvm -m 1024 -localtime -net nic -net vde,sock=/run/vde.ctl -hda /var/lib/libvirt/images/test.img
qemu-kvm: -net vde,sock=/run/vde.ctl: Parameter 'type' expects a network client type
[/console]
Небольшое курение интернета навело на мысль, что qemu в федоре собран без поддержки VDE (что вполне логично).
Итак, берем опять сырцы, корректируем spec (вставляем туда желаемое --enable-vde в нужное место), компилируем rpm, и на выходе, на этапе установки пакета (yum install ....) получаем сообщения, что для установки qemu* требуется библиотека libvdeplug.so.3. Вот теперь я совершенно ничего не понимаю. Она есть, лежит в /usr/lib... Не понимаю, почему qemu*.rpm этой библиотеки не видят... Как удовлетворить эту зависимость?
----
Скомпилировал пакеты с опцией --disable-vde. Вопросов об зависимости libvdeplug.so.3 не возникло. То есть, эта опция - дефолтная. А вот как отклониться от этого дефолта, как сказать yum, что библиотека искомая есть в наличии?..
=========================
Поставил скомпилированные с VDE qemu через rpm с ключом --nodeps. Виртуальная машина запустилась. Но вот интерфейсов сетевых она не видит... На этапе загрузки пишет, что похоже, что нет eth0 и откладывает его активизацию.

#265306
"Cruiser78" написал:
Вот теперь я совершенно ничего не понимаю. Она есть, лежит в /usr/lib... Не понимаю, почему qemu*.rpm этой библиотеки не видят... Как удовлетворить эту зависимость?
----

добавить симлинк в /usr/lib64

#265308
dyasny написал:

добавить симлинк в /usr/lib64

Я бы добавил. Но система на хосту - 32х битная. Нету там такого каталога за полной его ненадобностью. На подобной грабле уже прыгал, когда ставил какойто 32-хбитный пакет на 64х битную систему. Но здесь то зачем? Здесь система 32-х разрядная, все должно находиться в /lib/ /usr/lib/ usr/local/lib... Ведь всё остальное то находится правильно...

#265310
"Cruiser78" написал:
мне _надо_ чтобы два интерфейса, физический, eth0, и виртуальный, tap0, были в одной физической локальной IP-сети

Ну так делай бридж между ними, только без всяких virt-manager'ов, не помню уже какие конфиги у вас за это отвечают...
ы. Только мост после поднятия tap0, куда-нибудь в if-up/post-up скрипты.
ыы. Не знаю как в федоре, в дебиан все работает из коробки.

#265311
"Cruiser78" написал:
система на хосту - 32х битная

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

#265336
"Cruiser78" написал:
Но система на хосту - 32х битная

32 битная версия поддерживает виртуализацию? centos 6 точно знаю нет.

#265340
"semperN" написал:
centos 6 точно знаю нет.

Это что за нововведения?
Debian 32 bit запущена на amd, нормально запускается kvm 32/64 bit, обратный вариант тоже.
В Gentoo тоже и туда и обратно.

Войдите или зарегистрируйтесь, чтобы ответить.