Qemu bridge network linux

H Создание виртуальной машины QEMU + соединение с сетью средствами qemu-bridge-helper (Arch Linux 2013.12.01) в черновиках Recovery Mode Tutorial

Создание виртуальной машины не очень сложное дело, но нужная информация раскидана по разным сайтам. Будем считать, что программа QEMU уже установлена. Для начала нужно создать пустой образ диска:

Теперь настроим сеть в режим сетевого моста для проброса сети к виртуальной машине. Копируем /etc/netctl/examples/bridge в /etc/netctl/bridge и редактируем:
Description=»Example Bridge connection»
Interface=bridge0
Connection=bridge
BindsToInterfaces=(enp2s0f0 tap0)
IP=static
Address=(‘192.168.1.101/24’)
Gateway=(‘192.168.1.1’)
DNS=(‘192.168.1.1’)

Если у вас не статические настройки, то заменяем строчку IP=static на IP=dhcp и убираем строки: Address, Gateway, DNS. Меняем название сетевой карты enp2s0f0 на свое значение.

Теперь копируем /etc/qemu/bridge.conf.sample в /etc/qemu/bridge.conf и редактируем файл:
allow bridge0

Возможно понадобиться включить опцию:

Для включения этой опции при загрузке, создаем файл: sudo vim /etc/sysctl.d/99-sysctl.conf с содержимым:
net.ipv4.ip_forward = 1

Также может потребоваться загрузка модуля ядра tun:

Для запуска модуля при каждой загрузке создаем файл sudo vim /etc/modules-load.d/tun-mod.conf с содержимым:
tun

Теперь запускаем скрипт для создания моста:

Далее устанавливаем гостевую систему. Я буду ставить Ubuntu Server 13.10:

Сеть на данном этапе может по умолчанию не заработать, но для установки она нам не потребуется. Установка системы проходит стандартно.

После установки запускаем убунту такой командой (опцию -enable-kvm устанавливаем только, если поддерживается процессором, можно узнать введя команду lscpu, если есть поддержка будет отображена такая строка: Virtualization: VT-x. Соответственно процессору нужно подгрузить и добавить в автозагрузку модуль ядра: kvm-intel или kvm-amd. Об остальных опциях можно узнать в мане):

Теперь настраиваем все что нужно в графическом режиме.

Для запуска без графики в фоне используем такую команду с правами рута:

Источник

Configuring Guest Networking

Guest (VM) networking in kvm is the same as in qemu, so it is possible to refer to other documentation about networking in qemu. This page will try to explain how to configure the most frequent types of networking needed.

User Networking

• You want a simple way for your virtual machine to access to the host, to the internet or to resources available on your local network.
• You don’t need to access your guest from the network or from another guest.
• You are ready to take a huge performance hit.
• Warning: User networking does not support a number of networking features like ICMP. Certain applications (like ping) may not function properly.

• You need kvm up and running
• If you don’t want to run as root, then the user needs to have rw access to /dev/kvm
• In order for the guest to be able to access the internet or a local network, the host system must be able to access these resources as well

• Simply run your guest without specifying network parameters, which by default will create user-level (a.k.a slirp) networking:

• The IP address can be automatically assigned to the guest thanks to the DHCP service integrated in QEMU
• If you run multiple guests on the host, you don’t need to specify a different MAC address for each guest
• The default is equivalent to this explicit setup:

• The user.0 identifier above is just to connect the two halves into one. You may use any identifier you wish, such as «n» or «net0».
• Use rtl8139 instead of e1000 to get an rtl8139-based network interface.
• You can still access one specific port on the guest using the «hostfwd» option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with «-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22». Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. «scp -P 5555 file.txt root@localhost:/tmp» from host to guest. Or you can also use the other address of the host to connect to.

Private Virtual Bridge

• You want to set up a private network between 2 or more virtual machines. This network won’t be seen from the other virtual machines nor from the real network.

• You need kvm up and running
• If you don’t want to run as root, then the user needs to have rw access to /dev/kvm
• The following commands must be installed on the host system and executed as root:

• You need to create a bridge, e-g:

• You need a qemu-ifup script containing the following (run as root):

• Generate a MAC address, either manually or using:

• Run each guest with the following, replacing $macaddress with the value from the previous step

• If you don’t want to run qemu-ifup as root, then consider using sudo
• You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run

• Each guest on the private virtual network must have a different MAC address

Public Bridge

WARNING: The method shown here will not work with all wireless drivers as they might not support bridging.

• You want to assign IP addresses to your virtual machines and make them accessible from your local network
• You also want performance out of your virtual machine

• You need kvm up and running
• If you don’t want to run kvm as root, then the user must have rw access to /dev/kvm
• The following commands must be installed on the host system and executed as root:

• Your host system must be able to access the internet or the local network

Solution 1: Using Distribution-Specific Scripts

RedHat	Debian	SuSE
Edit /etc/sysconfig/network-scripts/ifcfg-eth0 comment out BOOTPROTO Add BRIDGE=br0 Create /etc/sysconfig/network-scripts/ifcfg-br0 The content should be:	Start YaST Go to Network Configuration Add new device -> Bridge Tick your existing network device done

• /etc/init.d/networking restart
• The bridge br0 should get the IP address (either static/dhcp) while the physical eth0 is left without an IP address.

Please note that the rtl8139 virtual network interface driver does not support VLANs. If you want to use VLANs with your virtual machine, you must use another virtual network interface like virtio.

When using VLANs on a setup like this and no traffic is getting through to your guest(s), you might want to do:

Solution 2: Manual Configuration

• You need to create a bridge, e-g:

• Add one of your physical interface to the bridge, e-g for eth0:

• You need a qemu-ifup script containing the following (run as root):

• Generate a MAC address, either manually or using:

• Run each guest with the following, replacing $macaddress with the value from the previous step

• If you don’t want to run qemu-ifup as root, then consider using sudo
• Each guest on the network must have a different MAC address
• You can either create a system-wide qemu-ifup in /etc/qemu-ifup or use another one. In the latter case, run

Routing with iptables

With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

• Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest has started):

• Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

• Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the default route:

Another option is using VDE (Virtual Distributed Ethernet).

More information will be provided later.

Performance

Data on benchmarking results should go in here. There’s now a page dedicated to ideas for improving Networking Performance.

Some 10G NIC performance comparisons between VFIO passthrough and virtio are discussed in VFIO vs virtio.

Compatibility

There’s another, old and obsolete syntax of specifying network for virtual machines. Above examples uses -netdev..-device model, old way used -net..-net pairs. For example,

is about the same as old

(note mac => macaddr parameter change as well; vlan=0 is the default).

Old way used the notion of «VLANs» — these are QEMU VLANS, which has nothing to do with 802.1q VLANs. Qemu VLANs are numbered starting with 0, and it’s possible to connect one or more devices (either host side, like -net tap, or guest side, like -net nic) to each VLAN, and, in particular, it’s possible to connect more than 2 devices to a VLAN. Each device in a VLAN gets all traffic received by every device in it. This model was very confusing for the user (especially when a guest has more than one NIC).

In new model, each host side correspond to just one guest side, forming a pair of devices based on -netdev -device netdev= parameters. It is less confusing, it is faster (because it’s always 1:1 pair), and it supports more parameters than old -net..-net way.

However, -net..-net is still supported, used widely, and mentioned in lots of various HOWTOs and guides around the world. It is also a bit shorter and so faster to type.

Источник

Настройка сети в KVM

Содержание

Настройка сети в KVM [ править ]

Настройка сети для виртуальных машин в kvm очень похожа на настройку в qemu, поэтому любая документация к qemu подходит и для kvm. В этой статье описывается как настроить наиболее часто используемые типы подключения виртуальной машины к сети. Эта статья основана на Networking — KVM.

Пользовательская сеть [ править ]

• Вам нужен простой способ дать виртуальной машине доступ в Интернет и в вашу локальную сеть;
• Вам не нужен доступ к виртуальной машине из сети или из других виртуальных машины;
• Вы готовы пожертвовать производительностью;
• Внимание: пользовательская сеть не поддерживает некоторые возможности сетей, например ICMP, поэтому некоторые приложения (такие как ping) могут работать неправильно.

• Настроенная и запущенная виртуальная машина;
• Если вы не хотите запускать её из под root-а, то для вашего пользователя понадобятся права на чтение/запись в /dev/kvm;
• Если виртуальной машине нужен доступ в Интернет или в локальную сеть, то у хост-системы должен быть доступ в эти сети.

• Просто запустите виртуальную машину с параметрами «-net nic -net user», например:

• IP-адрес может быть назначен автоматически DHCP-сервером, встроенным в QEMU;
• Если вы хотите запустить несколько виртуальных машин, то вам не понадобится назначать для них различные MAC-адреса;
• Используя опцию «hostfwd» вы можете получить доступ к одном порту на виртуальной машине. Например, если вы хотите передать файл из хост-системы на виртуальную машину, то запустите машину с параметрами «-net nic -net user,hostfwd=tcp::5555-:22». В данном случае вы перенаправить порт 5555 из хост-системы на порт 22 виртуальной машины. Команда «scp -P 5555 file.txt root@localhost:/tmp», выполненная на хост-системе, скопирует файл в виртуальную машину. Также вы можете использовать другой адрес хост-системы для подключения.

Внутренний виртуальный мост [ править ]

1. Организация сети между двумя или более виртуальными машинами. Эта сеть не будет доступна ни другим виртуальным машинам, ни из реальной сети.
2. Организация сети между виртуальными машинами и хост-системой. От первого варианта отличается только добавлением адреса на мостовой интерфейс хоста. Если возникнет потребность, можно добавить реальный интерфейс в мост, тогда виртуальные машины будут подключены к реальной LAN.

• Настроенная и запущенная виртуальная машина;
• Если вы не хотите запускать её из под root-а, то для вашего пользователя понадобятся права на чтение/запись в /dev/kvm;
• Вам понадобятся следующие программы:

/sbin/ip (пакет iproute2, обычно уже установлен) /sbin/brctl или /usr/sbin/brctl (пакет bridge-utils, устанавливается вместе с kvm) /sbin/tunctl или /usr/sbin/tunctl (пакет tunctl, нужно установить самостоятельно)

Если вы не хотите запускать их из под root-a, то вам понадобится настроить sudo для их запуска.

Решение: [ править ]

Подготовка [ править ]

В Седьмой платформе

• Во-первых, можно стартовать виртуальные машины с помощью libvirtd и управлять ими посредством virsh, при этом всё будет сделано автоматически. Нужно только правильно указать интерфейс (опция --network bridge).

• Во-вторых, можно использовать мостовой интерфейс virbr0, который появляется в системе после установки пакета kvm. Интерфейсу уже назначен IP 192.168.122.1/24 (см. конфигурация ю файле /etc/libvirt/qemu/networks/default.xml).

Перед запуском виртуальной машины создайте tap-интерфейс, добавьте его мост и потом используйте его при запуске kvm:

Создать tap-интерфейсы и добавить их в мост можно и с помощью скриптов /etc/net (см. man etcnet).

• В-третьих, можно использовать системный скрипт для запуска мостового интерфейса: /etc/init.d/bridge, достаточно создать нужное количество виртуальных интерфейсов, добавить их в /etc/sysconfig/bridge и запустить «службу» bridge:

Скрипт /etc/init.d/bridge при этом нельзя запускать автоматически при старте системы, но запускайте только вручную от пользователя с помощью sudo:

В дальнейшем виртуальные машины нужно запускать с использованием этих готовых интерфейсов, например:

В старых дистрибутивах

• Нужно создать и сконфигурировать мост, например:

• Для связи по сети между виртуальной машиной и хост-системой нужно задать адрес IP мосту, например:

или, чтобы не задавать адрес вручную, создайте файл /etc/net/ifaces/br1/ipv4address, содержащий единственную строку «192.168.100.1/2» (Это не обязательно, если доступ по сети в/из виртуальную машину не нужен.)

Также можно сконфигурировать сервер DHCP, чтобы он выдавал адреса в подсети интерфейса br1 (см. man dhcpd).

Включение виртуальной машины в мост [ править ]

• Необходимо (стандартный вариант)

— наличие двух сетевых карт на хосте eth0 и eth1 подключенных к локальной сети, — интерфейс eth0 настроен и работает в сети, eth1 включен настройки не обязательны

• Создать мост br0 (некоторые разработчики считают, что команды tunctl и brctl устарели)

• Создать скрипт qemu-ifup следующего содержания без sudo и «устаревших» утилит:

• Создать скрипт qemu-ifup следующего содержания (c использованием sudo, возможно необходимы предварительные настройки):

• Сгенерировать MAC-адрес вручную или автоматически, используя скрипт:

• Запустить каждую виртуальную машину, заменяя $macaddress значением, полученным на предыдущем шаге:

• Внутри каждой виртуальной машины нужно сконфигурировать уникальный адрес IP из одной и той же подсети.

Работа с предварительно созданными иинтерфейсами

Можно заранее (в стартовом скрипте) настроить все интерфейсы и затем использовать их в виртуальных машинах. При этом обязательно нужно указывать опцию script=no:

• Если вы не хотите запускать машину от root-а, то скрипт qemu-ifup должен корректно работать от вашего пользователя;
• Вы можете создать общесистемный скрипт, назвав его в /etc/qemu-ifup или же спользовать любое другое имя, указав его при запуске машины:

• Каждая виртуальная машина подключенная к внутреннему виртуальному мосту должна иметь свой собственный MAC-адрес, отличный от адресов других машин.
• Для включения в мост необходимо использовать интерфейсы tap, но не tun. Дело в том, что у интерфейсов tun нет заголовков ethernet, которые требуются для работы моста.

Публичный мост [ править ]

Предупреждение: Данный метод может не работать с большинством беспроводных устройств.

• Вы хотите назначать IP-адреса виртуальным машинам и сделать их доступными из локальной сети;
• Вы хотите большой производительности от виртуальной машины.

• Настроенная и запущенная виртуальная машина;
• Если вы не хотите запускать её из под root-а, то для вашего пользователя понадобятся права на чтение/запись в /dev/kvm;
• Вам понадобятся следующие программы. Если вы не хотите запускать их из под root-a, по вам понадобится настроить sudo для их запуска:

• Хост-система должна иметь доступ в интернет и в локальную сеть.

Вариант №1: Использование средств дистрибутива

• Создать файл /etc/net/ifaces/breth0/options следующего содержания:

• Применить новые настройки сети командой:

• Интерфейс моста breth0 должен получить IP-адрес, а интерфейс eth0 должен быть без адреса.

Если вы используете VLANы но до виртуальной машины трафик не доходит, выполните команды:

• Создать мост командой:

• Добавить физический интерфейс в этот мост, например eth0:

• Создать скрипт qemu-ifup следующего содержания:

• Сгенерировать MAC-адрес вручную или автоматически, используя скрипт:

• Запустить каждую виртуальную машину, заменяя $macaddress значением, полученным на предыдущем шаге:

• Если вы не хотите запускать машину от root-а, то скрипт qemu-ifup должен корректно работать от вашего пользователя;
• Вы можете создать общесистемный скрипт, назвав его в /etc/qemu-ifup или же спользовать любое другое имя, указав его при запуске машины:

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

Маршрутизация/iptables [ править ]

Также вы можете объединить виртуальные машины tap-интерфесом в хост-системе и настроить правила iptables в хост-система, чтобы она была маршутизатором и сетевым экраном для виртуальных машин.

Настройки маршрутизации сводятся к созданию маршрута по умолчанию в виртуальной машине, указывающего на хост-систему, разрешение пересылки пакетов (IP forwarding) и настройки маршрута на tap-интерфейс виртуальной машины в хост-системе.

Заблаговременно проверьте настройки:

• Хост-система: Разрешить пересылку пакетов и добавить маршрут до виртуальной машины (должно быть помещено в скрипт — маршрут необходимо добавить после запуска виртуальной машины):

• Виртуальная машина: маршрут по умолчанию указывает на хост-систему ( должен быть в одной сети с ):

• Виртуальная машина v2: если IP-адрес хост-системы не в одной сети с , тогда надо вручную добавить маршрут до хост-системы перед добавлением маршрута по умолчанию:

VDE [ править ]

Другой способ настройки сети это VDE (Virtual Distributed Ethernet).

Известные баги [ править ]

Отказы сети в гостевых Windows [ править ]

Под большой нагрузкой сетевой интерфейс в гостевой машине с ОС Windows перестаёт принимать и отправлять пакеты в хост-машину. Такое поведение характерно для любой модели виртуального интерфейса и для любой версии Windows в QEMU-KVM как минимум до версии 1.4.

Существует обходное решение: нужно заново проинициализировать сетевой интерфейс гостевой машины. Либо это можно сделать из гостевой ОС, либо из хост-машины парой команд virsh detach-interface и atttach-interface (и это надёжнее). Проверяем работоспособность при этом, очевидно, командой ping. Варианты скриптов для гостевой машины: [1], [2]. В скрипте для хоста перед проверкой пинга требуется проверить, работает ли гостевая ОС.

Источник