Qemu windows настройка сети

Обновлено: 04.07.2024

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

Варианты использования:

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

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

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

Варианты использования:

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

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

Если вы не хотите запускать их из под 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ов

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

Варинат №2: "Ручной"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с сетью в qemu достаточна проста, но зачастую вызывает множество вопросов у начинающих. Несмотря на то, что в сети существует ряд полезных руководств, в процессе решения прикладных задач возникают мелкие, но неприятные проблемы. В данной статье, я постараюсь постепенно собирать ряд рецептов и рекомендаций по настройке сети в qemu. Со стороны читателей приветствуются замечания и дополнения.

Все примеры в статье проверены на Fedora 14, qemu 0.13.0, kvm включен.

Основы.

С самого начала надо пояснить, как создать сетевой адаптер в гостевой системе. Для этого служит опция -net с параметром nic (Network Interface Card)

При указании данной опции в гостевой системе появится сетевой интерефейс заданной модели, с указанным mac адресом. При отсутствии параметра model будет эмулироваться адаптер realtek. Узнать какие адаптеры поддерживаются qemu для вашей архитектуры можно при помощи следующей команды

После указания адаптера самое время подумать, как он будет взаимодействовать с внешним миром. Qemu предоставляет несколько различных способов сетевого поключения для гостевой системы, но прежде чем перейти к описанию некоторых из них, необходимо познакомиться с понятием vlan. Сразу хочу отметить,что к Virtual Local Area Network этот термин не имеет отношения. В терминологии qemu vlan - это виртуальный коммутатор который создается процессом qemu, на один процесс их может быть несколько штук, и различаются они по номеру. Подключить сетевой адаптер к нужному vlan можно указав номер в качестве параметра, например

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

Так как же всё таки настроить работающую сеть?

Самый простой способ подключения сети в гостевой системе - использование встроенной в qemu системы сетевого обмена с хостом (user mod). Она не требует дополнительной конфигурации - если на хост-системе настроена сеть, то qemu сам позаботиться о том, чтобы запросы автоматически перенаправлялись на нужный сетевой интерфейс.

В данном случае к vlan 0 подключается с одной стороны сетевой адаптер гостевой системы, с другой стороны к этому же vlan подключается встроеннsq в qemu маршрутизатор. Гостевая система при этом получает IP адрес по DHCP (по умолчанию в диапазоне 10.0.2.0/8).

Необходимо подчернуть, что user режим работы сети включается по умолчнию, даже если не прописывать параметры конфигурации в командной строке qemu. Кроме того user режим имеет несколько полезных настроек - как всегда их можно подсмотреть в man`e.

Несмотря на свою простоту данный способ настройки сети для гостевой системы обладает рядом недостатков:

Медленная скорость сетевого соединения
Нет связи с другими виртульными машиными запущенными на данном хосте
Гостевая система недоступна с хост системы и с дригих машин в сети хоста.

К счастью существуют способы, позволяющие устранить эти проблемы.

Сетевое соединение между виртуальными машинами

Нижеописанный способ соединения позволяет установить связь между двумя виртуальными машинами qemu, через сетевой сокет на хост-системе. Для этого будет использоваться параметр -net socket

Сначала запустим первую машину, которая будет слушать порт 2030 по адресу 127.0.0.1

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

Во второй системе создается два интерфейса, один из которых подключается к первой виртуальной машине через сокет, а второй работает в user режиме (NAT встроенный в qemu и описанный выше) - благодаря этому вторая машина получает и доступ во внешнюю сеть и кроме того может обмениваться информацией с первой виртуальной машиной

Необходимо отметить, что при использовании socket механизма, сетевые настройки конечно же не раздаются автоматически. На скриншотах сетевые интерфейсы машин соединенных при помощи сокета на хост системе имеют адреса 192.168.200.1 и 192.168.200.2 (назначены руками) для Linux и Windows соответсвенно. На Linux системе также заметен и второй интерфейс eth2, который предоставляет доступ к внешней сети при помощи NAT.

Схему данной сети можно представить в следующем виде

Кроме того для связи нескольких машин друг с другом может использоваться схема UDP мультикаст сокетов, при этом сами виртуальные машины могут быть запущены на разных хостах. На этой схеме я подробно останавливаться не буду, так как сам её не использовал, а переписывать краткий мануал было бы бессмысленно.

Использование tun/tap интерфейсов для связи машин

Теперь для соединения между хостом и гостевой системой достаточно назначить адреса для tap интерефейса и сетевого адаптера на гостевой системе.

Например, на хост-системе создан мост virtnet0, тогда для добавления в этот мост tap интерфейса привязанного к виртуальной машине /etc/qemu-ifup может выглядеть так

Первый параметр передаваемый скрипту - это имя tap адаптера, он переводится в promisc mode и добавляется в сетевой мост.

Таким образом, если запустить несколько виртаульных машин, то для каждой из них будет назначен tap интерфейс и добавлен в мост virtnet0. При этом машины могут общаться друг с другом и с хост системой (в этом случае мосту в хост системе назнаяается IP адрес).

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

В сети можно найти множество различных руководств по настройке подобной конфигурации, поэтому здесь хочется отметить только несколько моментов. Если вы хотите использовать PXE загрузку (например для автоматической установки систем), то крайне рекомендую установить forward delay для моста равным 0

Кроме того, если вы используете NetworkManager для настройки сети, то могли заметить, что он пока что не работает сетевыми мостами (Я не нашел адекватного и быстрого способа). Для решения этой проблемы можно создавать мост непосредственно в скрипте /etc/qemu-ifup

Привет всем!
ОС: Archlinux (6/9/2016)
Пытаюсь уже пятый день настроить сеть в виртуальной машине, но никак не получается.
Пробовал -net nic,vlan=0 -net user,vlan=0 - адреса сетевая карта получает, но интернета нет, и что самое главное - когда пингуешь, IP-адрес определяется, но при этом ни инета, ни фига нет.
Машина запускается так: qemu-system-x86_64 -enable-kvm -m 2048M -smp 3 -hda hard -cdrom os.iso -boot d -vga qxl.
Пробовал еще так: -net tap,vlan=0,ifname=tap0,script=no,downscript=no, назнал адреса хосту и гостевой, но не работает, хост даже не пингуется!
А что касается моста, то:
Есть сетевой интерфейс eth0, настраиваю мост:
brctl addbr br0
btctl addif br0 eth0
и сеть пропадает, ввожу ifconfig up br0 и dhcpcd br0 и сети по прежнему нет.

Вопрос задан более трёх лет назад
4301 просмотр

Самый простой вариант не указывать -net параметр. Будет NAT. Интернет в виртуалке работать будет, хост и виртуальная машина по ip-адресу друг друга НЕ видят.

Этот NAT как раз таки не работает. Адрес сервера определяется, но не пингуется, бред какой-то.

Поправка к ответу: виртуальная машина по ip видит хост (пинг не работает, но TCP и UDP работает)

xibir: фаерволом случаем чего не закрыто?
ну а то, что адрес теряется, когда интерфейс в бридж добавляется, то это известный факт. нужно делать в такой последовательности (лучше скриптом, или инициализацией в системе), сначала снести адрес на интерфейсе, после этого его добавить в бридж, бриджу присвоить старый адрес.

Пробовал еще так: -net tap,vlan=0,ifname=tap0,script=no,downscript=no, назнал адреса хосту и гостевой, но не работает, хост даже не пингуется!

Регулярно пользуюсь этим способом, всё работает. Если стоит networkmanager надо следить за тем, чтобы он не потушил tap-интерфейс если qemu от него отключается.

я на центосе с делал так

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

Наконец-то мне удалось настроить сеть. Сейчас я расскажу, каким образом это у меня получилось.

Во-первых, я решил включить виртуальную машину в реальную локальную Ethernet-сеть, объединив мостом tap-интерфейс и eth-интерфейс. Для настройки сетевого интерфейса и мостового объединения интерфейсов нам понадобятся два пакета - соответственно uml-utilities и bridge-utils. Установим их с помощью команды:
Загрузим в ядро модули bridge и tun:
В принципе подгружать эти модули совсем не обязательно, т.к. они автоматически будут загружены командами brctl и tunctl при необходимости. Тем не менее, я таким образом просто решил заранее удостовериться, что возможные дальнейшие ошибки не связаны с отсутствием модулей или невозможностью загрузить их в ядро.

Теперь перезапустим настройку сети:
Если посмотреть список активных интерфейсов с помощью команды ifconfig, то можно увидеть 4 интерфейса: локальный петлевой интерфейс lo, интерфейс моста br0, получивший сетевые настройки по DHCP и два ненастроенных интерфейса: eth1 и tap0. eth1 соответствует реальной сетевой карте, а tap0 - виртуальному Ethernet-интерфейсу.

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

В виртуальной машине указываем получение настроек сетевого интерфейса по DHCP. Поскольку у меня в локальной сети настроен DHCP-сервер, я сразу же смог выйти в виртуальной машине в сеть.

При перезагрузке всплыли кое-какие проблемы. Система запускает с помощью сценария /etc/init.d/uml-utilities некий uml-switch. Сначала я подумал, что именно этот uml-switch заменяет группу-владельца устройства /dev/net/tun на группу uml-net, в результате чего запущенная виртуальная машина не может получить доступ к устройству и сеть не работает.

Тут можно было поступить несколькими способами. Во-первых, можно включить себя в группу uml-net, тогда проблема будет обойдена. Во-вторых, можно поменять группу-владельца в файле /etc/default/uml-utilities, указав нужную в переменной UML_SWITCH_USER. И наконец, можно просто отключить uml-switch, указав в переменной UML_SWITCH_START значение false. Я выбрал именно последний способ, поскольку я даже не знаю что такое uml-switch, то он мне вряд-ли нужен. Однако и это не повлияло на групповую принадлежность устройства /dev/net/tun!

Читайте также: