KVM + VDE в Fedora

еще раз, на 32-битном ХОСТЕ работает 64-битный гест? и это не в режиме эмуляции а через kvm?

в принципе на 64-битном хосте с 32-битным юзерспейсом, можно поизвращаться. ну или полная эмуляция с дикими тормозами с флагом -nokvm
https://bugs.launchpad.net/qemu/+bug/596106

что-то все поперепутали... :)

"dyasny" написал:

еще раз, на 32-битном ХОСТЕ работает 64-битный гест?

так конечно на заработает... kvm - виртуализатор же.

"newzenon" написал:

так конечно на заработает... kvm - виртуализатор же

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

Мы тут стараемся, тестируем хосты с терабайтами памяти и сотнями процессоров, а народ на 32ух битах сидит :)

dyasny написал:

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

Разве я где сказал, что пытаюсь закрутить рабочую виртуалку? Сейчас я только на "стендовой" машине (которая по совметительству является и моей администраторской консолью) прорабатываю все потнциально возможные грабли, с которыми я могу столкнуться при реализации KVM-виртуалок на рабочих серверах. А они - да, они 64-разрядные. А вот моя административна машина - она под RFR-15.i686. Ей большего не требуется. И тренировки я устраиваю на 32-х разрядном госте. По жизни, мне виртуализировать 64-х битного гостя не особо и надо. Нафига 64-бита для почтового сервера или Астериска? Или для винды ХР, в которой ночами выполнаются роботами некие регламентые работы по обслуживанию 1С и Консультанта? Для этого 32-х бит за глаза хватит.
2semperN И, кстати, вся виртуализированная трихомудия, qemu-kvm-xen, и даже "кастрированный" слегка VirtualBox входят в штатные репы Федоры. Как 64-х разрядные, так и 32-х. Так что всё поддерживается. Так как особой разницы между CentOS и Fedora нет.
===========================
Teперь вопрос по теме. Научил, таки, вязаться kvm-машину с vde. И VDE - работает. Почти. Вначале небольшая поправка к скрипту newzenon надо не так:

vde_switch -x -n 5 -s /run/vde.ctl -g kvm -m 770 -d -p /run/vde.pid -t tap0
kvm -m 1000 -localtime -net nic -net vde,sock=/run/vde.ctl -hda debian-wheezy-i386.img &

А так:

vde_switch -x -n 5 -M /tmp/vdemng -s /run/vde.ctl -g kvm -m 770 -d -p /run/vde.pid -t tap0
qemu-kvm -m 1000 -localtime -net nic -net vde,sock=/run/vde.ctl,group=kvm  -hda debian-wheezy-i386.img &

То есть, если при объявлении свича заявили группу, то изволь для подключения виртуальной машины эту группу указывать тоже. Иначе - фиг достучишься. Второе - очень полезно использовать ключ -M. При этом открывается дополнительный сокет, через который можно с помощью vdeterm (или unixterm) очень удобно смотреть, что именно в свиче происходит. И управлять им как обычным свичом L2-уровня терминалом. А вот что работает криво (у меня) - интерфейс tap0 откликаться во внутрь свича не хочет ни разу.
Итак, делаем tap0 традиционным способом:

vde_tunctl -t tap0
ifconfig tap0 192.168.43.1 up
ifconfig tap0 mtu 1400   

Назначаем правила форвардинга. Интерфейс tap0 пингуется. К tap0 можно подключиться извне на 22й порт и попасть на хост. Вроде все с этим нормально.
Далее, привязываем к tap0 vde_switch указанным выше способом, контролируем привязку его в vdeterm. Порт занят.
Запускаем витруальную машину описанным выше способом. Она запускается и подкючается к свичу. Контролируем привязку в vdeterm. Еще один порт занят. Но сеть не видна... А именно - сетевой интерфейс виртуалки настроен получать IP-адрес по dhcp. Фиг-вам. Назначаю его руками, через ifconfig (192.168.43.208). И пытаюсь пропинговать tap0, ping 192.168.43.1 из виртуальной машины. В результате вижу, что из виртуальной машины выходят только ARP-запросы. Но ответа на них нету...
Вот, что есть на виртуальной машине:
А ничего нет, не знаю, как клипборд интегрировать. Ну пинг упорно пишет, что целевой хост недоступен.
Далее, в свиче видим следующее:

[console]
Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
Current User: NONE Access Control: (User: NONE - Group: NONE)
IN: pkts 0 bytes 0
OUT: pkts 59 bytes 8281
-- endpoint ID 0007 module tuntap : tap0
Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
Current User: root Access Control: (User: NONE - Group: NONE)
IN: pkts 59 bytes 8281
OUT: pkts 0 bytes 0
-- endpoint ID 0008 module unix prog : QEMU user=root PID=8547
Success
vde[/tmp/myvde.mgmt]: port/print

Port 0001 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
Current User: NONE Access Control: (User: NONE - Group: NONE)
IN: pkts 0 bytes 0
OUT: pkts 1072 bytes 50947
-- endpoint ID 0007 module tuntap : tap0
Port 0002 untagged_vlan=0000 ACTIVE - Unnamed Allocatable
Current User: root Access Control: (User: NONE - Group: NONE)
IN: pkts 1072 bytes 50947
OUT: pkts 0 bytes 0
-- endpoint ID 0008 module unix prog : QEMU user=root PID=8547
[/console]
То есть пакеты с порта виртуальной машины перекладываются на порт с tap0. Но обратно ничего не идет. На интерфейсе tap0 видим только ARP-запросы:

[console]# tcpdump -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
10:19:10.777584 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
10:19:12.778655 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
10:19:13.778638 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
10:19:14.778625 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
10:19:16.779613 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
10:19:17.779609 ARP, Request who-has 192.168.43.1 tell 192.168.43.208, length 28
[/console]
Правила iptables следующие:
[console]# iptables-save | grep tap0
-A FORWARD -i p5p1 -o tap0 -j ACCEPT
-A FORWARD -i tap0 -o p5p1 -j ACCEPT
[/console]
Морщим лоб, прописываем на хосту правило маршрутизации, что пакеты на 192.168.43.208 надо направлять на tap0, на 192.168.43.1. После чего tap0 начинает пинговаться из виртуальной машины.
Теперь пытаемся пропинговать реальный хост в этой сети из виртуальной машины. Опять видим то же самое на tap0:

[console]# tcpdump -n -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
11:03:05.921670 ARP, Request who-has 192.168.43.2 tell 192.168.43.208, length 28
11:03:06.921676 ARP, Request who-has 192.168.43.2 tell 192.168.43.208, length 28
11:03:07.921654 ARP, Request who-has 192.168.43.2 tell 192.168.43.208, length 28
[/console]
И, при этом, даже если прописать на пингуемом хосту маршрут на виртуальную машину 192.168.43.208 через tap0 (192.168.43.1) ничего не происходит. Продолжают идти ARP-запросы. Но ответа на них - нет. При этом они не доходят до реального пингуемого сервера. Вроде как умирают внутри tap0.
Вопрос, собственно, очевиден. Как выставить "на улицу" виртуальную машину? Все симптомы описал.

"Cruiser78" написал:

Разве я где сказал, что пытаюсь закрутить рабочую виртуалку?

то есть мы все это время обсуждали не рабочий кластер а тестовую площадку? Пардон, наверное я не так все понял.

"Cruiser78" написал:

Нафига 64-бита для почтового сервера

у меня сейчас крутится зимбра на примерно 700 юзеров, с рассчетом перетащить туда около 3500-4000 юзеров к концу года. Потянула бы одна 32-ух битная машина такое? Я очень сомневаюсь

"Cruiser78" написал:

вся виртуализированная трихомудия, qemu-kvm-xen, и даже "кастрированный" слегка VirtualBox входят в штатные репы Федоры. Как 64-х разрядные, так и 32-х. Так что всё поддерживается.

в федоре не поддерживается ничего. это апстримовый дистр и в случае поломки "поддержка" только на форумах и багзилле. "поддерживается" это когда не "в репах есть пакет" а когда все пакеты идущие с дистром проверены и в случае чего есть ответственное за каждый пакет лицо, к которому можно обратиться.

"Cruiser78" написал:

Так как особой разницы между CentOS и Fedora нет.

кто это вас так обманул?

dyasny написал:

то есть мы все это время обсуждали не рабочий кластер а тестовую площадку? Пардон, наверное я не так все понял.

У меня есть очень простое правило - никогда и ни при каких обстоятельствах не лезть на рабочие сервера до тех пор, пока не разгребешь все грабли на стенде. Стенд, правда, не совсем повторяет конфигурацию рабочих серверов, но все проблемы - выявляет. И только когда наешь железные зубы в новом ПО на стенде, убедишься в его работоспособности - тогда:
1. Дополняю "руководство системного администратора", талмудик свой, в котором описано пошагово (но достаточно общо) что, как и почему надо делать для установки ПО и как надлежит его настроить.
2. Разворачиаю по этому "руководству" новое ПО.
3. Фиксирую все отклонения от "руководства".
4. Фиксирую там же начальные настройки, с которыми запущено новое ПО в эксплуатацию.
Сейчас я пока кувыркаюсь на начальном этапе, добиваюсь, чтобы вся эта виртуализация мною собиралась-разбиралась как автомат Калашникова. Делать то на рабочих серверах нельзя. А когда я потащу обкатанное на стенде решение (которое я и обсуждаю здесь) на рабочие сервера, то обсуждать мне уже ничего не надо будет.

dyasny написал:

у меня сейчас крутится зимбра на примерно 700 юзеров, с рассчетом перетащить туда около 3500-4000 юзеров к концу года. Потянула бы одна 32-ух битная машина такое? Я очень сомневаюсь

Не знаю, но думаю, что потянула бы вполне. И даже не задумалось бы об этом. Аргументирую:
0. Что дает нам 64-х разрядная машина? Возможность запросить и адресовать блок памяти размером больше 4 гигабайт. А где такой блок памяти может быть заказан в почтовом сервере?
1. Сколько нужно памяти почтовому серверу, чтобы обработать одно письмо? Даже натравив на него всю мощь антиспамовой аналитики и антивирусной защиты? Очень не думаю, что для этого потребуются гигабайты памяти.
2. Если мне не изменяет склероз, то все почтари для обработки одного письма "форкают" один "процесс" (если очень грубо, кавычки важны) и в рамках этого "процесса" и происходит обработка письма. Для одного такого процесса памяти нужно не очень много. И при этом - это потребное на один процесс количество памяти не зависит от количества учетных записей в сервере. Так что 4 гигабайт на 32х разрядной машине вполне даже хватит.
3. Сколько _одновременно_ будет нафоркано таких процессов? Не думаю, что 4000. От силы сотня, другая.
4. А для базы данных 4 тыщи записей - это вообще не объем, сопли.
Исходя из этих соображений я предполагаю, что 32-х битный почтарь вполне справится с нагрузкой.

"Cruiser78" написал:

0. Что дает нам 64-х разрядная машина? Возможность запросить и адресовать блок памяти размером больше 4 гигабайт. А где такой блок памяти может быть заказан в почтовом сервере?

почтовый сервер в наше время это не только демон smtpd, там еще и доступ по аймапу и поп, веб консоль для админов и юзеров, активсинк, и плагины для блекберри, бекапы разного уровня, API через SOAP и REST... а теперь умножаем все это на количество юзеров, мейлбоксов, алиасов, дистр. листов, ящиков для ресурсов, caldav-счетов и хранилищ встроенных документов и тасков.

там сейчас 32Гб памяти и 12 SAS дисков в 10ом рейде, и подозреваю что на все 4000 юзеров может не хватить.

dyasny написал:

там сейчас 32Гб памяти и 12 SAS дисков в 10ом рейде, и подозреваю что на все 4000 юзеров может не хватить.

если там 32 гигабайта памяти на 700 юзерей, то кучеряво живете, однако... :-) И на такой памяти, действительно, надо 64х разрядную систему. Или kernel-PAE. Но, именно из за объема доступной памяти, а не из-за количества юзерей.
=========================================
А по теме - есть что посоветовать? У меня полное ощущение, что tap0 не выпускает во внешний мир бродкасты (ARP запросы) которые идут с VDE. И (или), соответственно, не возвращает ответы на них.
Вот что я вижу на хосту, где поднят tap0:

[console]# ifconfig
p5p1 Link encap:Ethernet HWaddr 14:DA:E9:B5:0B:DE
inet addr:192.168.43.8 Bcast:192.168.43.255 Mask:255.255.255.0

tap0 Link encap:Ethernet HWaddr CA:EF:D0:9A:6A:D6
inet addr:192.168.43.1 Bcast:192.168.43.255 Mask:255.255.255.0
[/console]

То есть имеются разные mac-адреса.
Однако во внешнем мире ARP запрос отрабатывает несколько иначе:
[console]# arp -n
Address HWtype HWaddress Flags Mask Iface
192.168.43.8 ether 14:da:e9:b5:0b:de C eth0
192.168.43.1 ether 14:da:e9:b5:0b:de C eth0
[/console]

То есть - показывается на один физический интерфейс. Это, как я полагаю, правильно. При этом если я пингую из виртуальной машины внешний сервер, то на tap0 я ловлю ARP-запросы. Но эти запросы не передаются на физичекий p5p1(eth0)-интерфейс (форвардинг включен). Там - полная (на тему ARP из tap0) тишина... tcpdump эти запросы на p5p1 не видит. Как будто они в tap0 где-то умирают.
=====================
Похоже, что надо раскуривать настройки Proxy-ARP.
Включил, как в man'е прописано, получил следующее:

[console]
# tcpdump -n -i tap0
....
14:28:25.801502 ARP, Request who-has 192.168.43.2 tell 192.168.43.208, length 28
14:28:25.801515 ARP, Reply 192.168.43.2 is-at ca:ef:d0:9a:6a:d6, length 28
14:28:25.801591 IP 192.168.43.208 > 192.168.43.2: ICMP echo request, id 20503, seq 1043, length 64
14:28:25.801627 IP 192.168.43.1 > 192.168.43.208: ICMP host 192.168.43.2 unreachable - admin prohibited, length 92
[/console]
То есть, теперь tap0 стал ARP-Proxy, вместо реального mac-адреса пингуемого сервера возвращает свой. Но вот дальше - сделать ничего не может. И от своего имени отвечает, что некий админ запрещает доступ... Причем никакого форвардинга на p5p1 (физический интерфейс нету). И на физическом интерфейсе нет никакой активности...
Что я неправильно делаю?..
************************************************
Всё. Вопрос закрыт. Это я тормоз. Собака зарылась в iptables. Там оказалась небольшая предистория по FORWARD'у. Которая заканчивалсь режектом. Ну а новые правила форвардига между tap0 и p5p1 естественно заносились после этого режекта. Исправил таблицу - всё заработало как хотел..

"Cruiser78" написал:

Вопрос, собственно, очевиден. Как выставить "на улицу" виртуальную машину? Все симптомы описал.

Симптомы очень похожи на те, что я испатывал года полтора назад, когда мне приглянутлся этот vde. Уровень гемора с этим vde c годами не уменьшается, судя по твоем рассказам. Но я еще игрался с vlan на vde, и небо тогда казалось безоблачным. А если винда идет гостем, то тоже были сюрпризы, готорые я смог побороть только частично.
Мое имхо такое, что vde интересно, но пускать его в продакшн очень стремно , а крутить виртуалки без libvirt очень хлопотно. А варппер для vde на либвирт прикручивать мне было очень костыльно.
Если я правильно уловил мысль, ты хочешь сделать так

host_eth0 --> VDE <--> tap0 <-guest_eth0

Эта схема меняется на

host_eth0 --> host_bridge <--guest_eth0

которая сапортится либвиртом. Сопровождать ее значительно легче.

"Cruiser78" написал:

если там 32 гигабайта памяти на 700 юзерей, то кучеряво живете, однако... :-) И на такой памяти, действительно, надо 64х разрядную систему. Или kernel-PAE. Но, именно из за объема доступной памяти, а не из-за количества юзерей.

я же говорю - дело дойдет до 3.5-4к юзеров, и сервисов вокруг почты много. В другой фирме, все еще лучше - зимбра на полутора десятках VM, плюс фронтэнды и load balancer-ы, почты на пару десятков Тб. Все это для примерно 5к юзеров и кучи разнообразных дистр. листов и серверных аккаунтов. И это никому не кажется большим и тяжелым кстати.

"Cruiser78" написал:

А по теме - есть что посоветовать? У  меня полное ощущение, что tap0 не выпускает во внешний мир бродкасты (ARP запросы) которые идут с VDE. И (или), соответственно, не возвращает ответы на них.

vde не знаю, всегда обходил такие поделки стороной

dyasny написал:

я же говорю - дело дойдет до 3.5-4к юзеров, и сервисов вокруг почты много.

От чего зависят эти сервисы? Зависят ли они от каждого почтового сообщения или они есть принадлежность собсьвенно почтовой системы? То есть, если привести аналогию - зависит ли MySQL от количества записей в таблицах? Я думаю, что что если и зависит, то не сильно критично. Тому же давкоту и постгресу как-то всё равно сколько почтовых ящиков (каталогов) обрабатывать 100 или тыщу.
В данном же случае я вижу только следующее:
1. Количество юзерей увеличивается примерно в 5 раз. с 700 до 3-4 тыщ.
2. Соответственно возрастет объем хранимого материала. Хотя - зависимость здесь явно нелинейная. Скорее может возрасти количество записей в листах рассылки... Ну ладно, пусть это выростет в 5 раз. Это затраты на диски.
3. А вот с загрузкой процессора - здесь надо смотреть уже в теорию массового обслуживания. А она нам говорит, что подобные вещи надо складывать (как независимые процессы) под корнем. То есть загрузка процессора, выделение им памяти, возрастет в среднем чуть больше чем в 2 раза. И то, только на тех процессах, которые от юзера (на его сообщения) форкаются, но их не так много. А не на различные сервисы, админки и так далее...

Так что, если бы ту почту обслуживал сервер с памятью в гигабайт, то я бы удвоил бы ему память и на том успокоился. Ну не вижу я в данном вопросе необходимости работать с блоками памяти больше 4 гигабайт. А всё остальное там прекрасно может работать в 32-х разрядном режиме.


В другой фирме, все еще лучше - зимбра на полутора десятках VM, плюс фронтэнды и load balancer-ы, почты на пару десятков Тб. Все это для примерно 5к юзеров и кучи разнообразных дистр. листов и серверных аккаунтов. И это никому не кажется большим и тяжелым кстати.

dyasny написал:

vde не знаю, всегда обходил такие поделки стороной

Да вроде нормальный программный свитч. Если бы я изначально не затупил с iptables - пару дней назад всё заработало бы. Одна неприятность - необходимость на хосту прописывать руками статический маршрут через tap0 на действующие на этом хосту виртуалки. А если виртуалка поедет (начнется миграция) на иной хост в HA-кластере... Тут есть над чем подумать.

Читаю вашу дискусию и внимаю информацию как губка. Приятно читать диалог умных и профессионалов. Скажите мне пожалуйста вот что. Зачем поднимать програмный свитч, если все можно слелать через бридж? Гостевые системы и так будут в сети как реальная машина в сети. Имеется ввиду не большое число ВМ. Не больше 10 например. Или иметь виртуальный свитчь 2 уровня проще и программировать его как реальное железо?

"XliN" написал:

Не больше 10 например

у меня тут через такой бридж бегают 140 виртуалок. Правда бридж прицеплен на бонд из 4x10Gbps NIC, но сам факт того что бридж это тянет это не отменяет, была бы за ним труба потолще

"Cruiser78" написал:

вроде нормальный программный свитч.

года 3 назад я его разглядывал и уже тогда было понятно что решение бесперспективное - оно сложнее чем бридж, развивается вяло, и не дает преимуществ перед обычным бриджем. Ваш случай очень специфичный, и даже если конкретно вам оно подойдет, то это не будет означать что проект стал более интересным для общества пользователей kvm.

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

или, если очень хотите рулить сетевушками ВМ со свичей, то есть 802.1Qbh и 802.1Qbg

А вообще как себя ведет VirtiO сетевая карта? некоторые жалуются что бывает падает скорость? такое не кто не замечал? или лучше использовать виртуальную e1000?

"semperN" написал:

А вообще как себя ведет VirtiO сетевая карта? некоторые жалуются что бывает падает скорость? такое не кто не замечал? или лучше использовать виртуальную e1000?

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

Если скорость падает, то надо разбираться почему, обычно это сам хост перегружен

dyasny написал:

[quote="semperN"]А вообще как себя ведет VirtiO сетевая карта? некоторые жалуются что бывает падает скорость? такое не кто не замечал? или лучше использовать виртуальную e1000?

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

Если скорость падает, то надо разбираться почему, обычно это сам хост перегружен[/quote]
Тут с вами согласен. Ток не забыть модули подгрузить.
openvswitch щас курю маны вроде даже нечего.

XliN написал:

Зачем поднимать програмный свитч, если все можно слелать через бридж?

У меня очень специфический и нестандартный случай. Который, к сожалению, стандартным бриджеванием физического интерфейса не лечится.
То есть, классическая и удобная для libvirt'а схема:

host_eth0 --> host_bridge <--guest_eth0

мне не подходит.
А именно: мне надо в силу ограниченности количества средств вычислительной техники для организации HA-кластера иметь блуждающий алиасный адрес на физических интерфейсах узлов кластера. И на этих же узлах поднимать виртуалки. Если я делаю бридж на интерфейсе, то я теряю возможность иметь на нем алиас, через который должны быть доступны сервисы, работающие именно на узлах, а не в виртуалках. Переносить эти сервисы в виртуалки я пока не хочу. Ибо настроено, да и не совсем понимаю, пока, как пробросить drbd диск узла в виртуальную машину, чтобы там его смонтировать и поуправлять им узловым хеартбитом...
Можно для этого дела воткнуть в сервер дополнительную сетевую плату и развернуть на ней бридж, но это слишком просто, раз. Тем более, что платы гигабитные у меня есть. А во вторых - я не хочу сейчас заниматься модернизацией серверов, так как они на 1DIN и воткнуть туда плату можно только через райзер. А этого у меня нет. Так что, принял решение помучаться. В результате реализовал схему с посредником (важно иметь оригинальный физический интерфейс в неприкосновенности):

host_eth0 < -- > tap0 <==> VDE <--> guest_eth0

Наел немного железа на зубы в части VDE. В нем мне, кстати, понравилась возможность иметь "распределенный" между хостами бридж. Пока не знаю, нужно ли мне это, но выглядит весьма вкусно.

dyasny написал:

хотите програмный свич - ставьте openvswitch или, если получится прикрутить - vyatta. примитивный программный свич - бридж.
или, если очень хотите рулить сетевушками ВМ со свичей, то есть 802.1Qbh и 802.1Qbg

1. Вопрос - из описания openswitch я вычитал, что там поднимается tap-интерфейс. Првилен ли мой вывод из этого о том, что если его поставить, то виртуалками можно будет рулить через libvirt, virt-manager? Если да, то это большое преимущество.
2. За наводку на vyatta спасибо, очень интересно. Но оно мне, как я понял, бегло пробежавшись по верхушкам офф.сайта, не очень подходит. Ибо не СПО.
3. А вот последнее - я совсем не понял... Это названия "стандартов" или что? То есть - как применить?

А то, что проект не развивается шустро, то может и к лучшему. Часто ли мы меняем прошивки в железных свичах. Так и здесь - отлито из бронзы, руками не трогать.

"Cruiser78" написал:

1. Вопрос - из описания openswitch я вычитал, что там поднимается tap-интерфейс. Првилен ли мой вывод из этого о том, что если его поставить, то виртуалками можно будет рулить через libvirt, virt-manager? Если да, то это большое преимущество.

в принципе там можно поднять его в bridge mode, который вполне совместим с либвиртом. сам давно не трогал, и в репах RHEL OVS пока отсутствует, так что пока и не трогаю. OVS хорош тем что он умеет быть полноценным свичем, с настройками портов, вланов и прочего. Основной аналог - cisco nexus

"Cruiser78" написал:

2. За наводку на vyatta спасибо, очень интересно. Но оно мне, как я понял, бегло пробежавшись по верхушкам офф.сайта, не очень подходит. Ибо не СПО.

там вроде была бесплатная версия. насколько я помню, vyatta стремилась заменить собой каталисты и пиксы по функционалу.

"Cruiser78" написал:

3. А вот последнее - я совсем не понял... Это названия "стандартов" или что? То есть - как применить?

это стандарт который поддерживает либвирт, но нужен свич который это умеет (cisco UCS/VMFEX и nexus умеют Qbh, есть кучка других умеющих Qbg). Принцип немного разнится по реализации, но основная идея в том что ВМ пробрасывает свои сетевые карты в виртуальный порт на свиче, и дальше этим портом можно управлять из интерфейса свича, а не на гипервизоре. Ну а так как свичи как раз для управления портами и существуют, то там уже и так все хорошо без всяких костылей.

"Cruiser78" написал:

"распределенный" между хостами бридж

это попытка догнать dvSwitch в vCenter, настраивается свич, и его профиль накладывается на набор хостов, при этом автоматически захватываются подходящие NIC-и. OVS как раз в этом очень неплох.

Если интересно почитайте про quantum, это проект пытающийся соединить все эти технологии в одно целое, с набором плагинов для каждого вендора.

"Cruiser78" написал:

А то, что проект не развивается шустро, то может и к лучшему. Часто ли мы меняем прошивки в железных свичах. Так и здесь - отлито из бронзы, руками не трогать.

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