Сетевой интерфейс к гостевой ОС (варианты подключения)

На хосте пользуй бриджы. Для гостевой венды у меня нормально работает драйвер e1000, virtio в гостевой венде почему-то не хочет нормально работать. Я создаю в virt-manager машину, даю машине сеть в созданный бридж. Оно само создаёт vnet интерфейс на хост системе, который включет в бридж. Даёшь бриджу на хосте железный интерфейс, включенный в сеть и получаешь гостя в той же сети.

Бриджы на хосте создаю руками, этим функционалом virt-manager-а не пользуюсь.
Не забудь изолировать бриджы на хосте

$IPTABLES -A FORWARD -i $LAN_31_IFACE -o $LAN_31_IFACE -j ACCEPT
$IPTABLES -A FORWARD -o $LAN_31_IFACE -j REJECT --reject-with icmp-port-unreachable
$IPTABLES -A FORWARD -i $LAN_31_IFACE -j REJECT --reject-with icmp-port-unreachable

А как будет происходить маршрутизация на хосте? Хотелось чтобы ethernet-контроллер использовался только для гостевой ОС. Оно так будет работать? Как это повлияет на работу network-manager?

Спасибо. Попробую.

qemu-kvm 1.1.2

Свежатинка, не то, что стабильная 2.4.0-r1 в генте. Или ты не знаешь, что для kvm сейчас ставят просто qemu?

network-manager

забудь про эту софтину, если нет беспровода. Всё делай через /etc/network/interfaces
При включении виртуалки в бридж, который включен в локалку, маршрутизации нет. Есть коммутация. Бридж - это тупо обычный свитч.

auto		lo	br_host br_10_3_1_0 br_10_3_2_0 br_wan

iface lo inet loopback
	dns-nameservers цензура
	dns-domain цензура
	dns-search цензура
	post-up /etc/init.d/rc.firewall.host31

iface em1 inet manual
#iface em1 inet6 auto

iface em2 inet manual

iface em3 inet manual

iface em4 inet manual

iface br_host inet static
	bridge_ports em1
	bridge_stp off
	bridge_fd 0
	address цензура
	netmask 255.255.255.192
	gateway цензура

iface br_10_3_1_0 inet manual
	bridge_ports none
	bridge_stp off
	bridge_fd 0

iface br_10_3_2_0 inet manual
	bridge_ports none
	bridge_stp off
	bridge_fd 0

iface br_wan inet manual
	bridge_ports none
	bridge_stp off
	bridge_fd 0

если нет беспровода

Он, к сожалению, есть. Интернеты на хост буду через него получать.

Есть коммутация. Бридж - это тупо обычный свитч.

Спасибо.

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

Для гостевой венды у меня нормально работает драйвер e1000, virtio в гостевой венде почему-то не хочет нормально работать.

а разобраться в чем проблема слабо? у всех работает, все довольны

если надо отдать NIC виртуалке, то проще использовать macvtap чем мост. и производительность, по идее, должна быть немного лучше.

многие wifi карты не умеют promisc, и поэтому в бридже не работают.

macvtap

расскажи на пальцах как работает, пожалуйста.

многие wifi карты не умеют promisc, и поэтому в бридже не работают.

угу, есть такое

да так же как и мост, но только между железзкой и виртуалкой, без возможности втыкать больше ничего. получается что отдаешь NIC без полноценного PCI проброса

То есть, хост-система не может пользоваться отданным NIC?

Поставьте proxmox
в нем админка есть, все красиво, удобно

именно так.

Хм. Где-то на практике такая схема применяется? В чём соль? Ведь это же получается по 1 nic на виртуалку + хост-системе надо еще nic.

если надо отдать NIC виртуалке, то проще использовать macvtap чем мост. и производительность, по идее, должна быть немного лучше.

Разве мост даёт заметный оверхед? А кроме него в этом случае, вроде ничего не экономится.

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

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

Ясно, спасибо. Наверное, имеет смысл внутре-хостовые гейты таким образом включать во внешние сети.

это имеет смысл когда это реально нужно. у меня один клиент гоняет транзакции кредитных карт в виртуалках, и скорость обработки очень важна. поэтому каждая VM поднимается с проброшенным 10G интерфейсом, причем не просто с macvtap, а еще и с vmfex (802.1Qbh).

Проброс PCI или варианции на тему, типа SRIOV еще эффективнее, но привязав VM к реальному железу, теряешь возможность двигать VM между серверами, а с macvtap, можно просто создать пул из девайсов и цеплять машины к пулу а не к конкретному девайсу. получается libvirt сам разруливает что куда цеплять и что доступно, а что занято

1) если радикально то пробросить сетевуху в виртуалку, но если она одна то оставишь хост без сети

2)через tun/tap; создать мост на хосте ну а виртуалку запусктить примерно так

-netdev type=tap,id=guest0,script=/etc/qemu/qemu-ifup,vhost=on -device virtio-net-pci,netdev=guest0,mac=52:54:12:34:56:78

3)если проблемы с virtio то вместо virtio-net-pci использовать e1000

Спасибо, это хорошая инфа.