Настройка сети в qemu linux

Обновлено: 29.06.2024

Это репост статьи от новогодней ночи 31 декабря 2008г. - 1 января 2009г.

Доброго времени суток. Вечер. 31 декабря 2008 года. Чем заняться человеку в такое время? Правильно! Начать писать статью на permlug, чтобы поделиться опытом. :)

Часть 1. Нелюбимый windows или с чего всё начиналось.

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

Преамбула: на работе стоял в стойке двухюнитовый сервер HP ML380 с четырнадцатью гигабайтами памяти и восемью скази дисками общим объёмом чуть менее терабайта (надо же, скоро эта единица измерения объёма информации станет совсем привычной, а ведь на полке где-то пылится с давних времён Seagate на 40 мегабайт :)). На этом сервере предыдущие админы догадались разместить расшаренные папки всей организации и внушительное количество всяческого барахла - дистрибутивы, драйвера и т.д.. И конечно же, на сервере стоит w2k3. Поставил snmp, подключил сервер к мониторингу и забыл о нём на какое-то время, поскольку дел было невпроворот. А потом внезапно вспомнил и решил посмотреть результаты. Результаты впечатляли. Средняя загрузка памяти - 1,6%, загрузка процессоров не поднималась выше трёх процентов. Причём гигабитным портом сервер был подключен к стомегабитному порту коммутатора, ибо больше некуда, а на гигабитный управляемый коммутатор, который можно было бы сделать центральным, начальство разоряться не хочет. В то же время, мне постоянно не хватало на работе машин, на которых можно что-то потестировать, опробовать и проверить, поэтому я решил устроить серверу размножение личности, благо, вычислительных ресурсов у него на это хватает с лихвой. Был проведён разговор с начальством и получено "добро" на использование сервера в своих целях при условии, что это не помешает пользователям работать с расшаренными документами, ибо перенести этот объём информации просто некуда. При помощи нехитрой утилитки SequoiaView (аналог встроенной в Konqueror FSView), я пошарился по папкам пользователей и конечно же, обнаружил там среди документов музыку, фильмы, игры и прочую чепуху, которая к делу не относится. Проведя разъяснительную беседу с рядом пользователей и пригрозив им введением квот, я освободил себе около 200 гигабайт места. В принципе, вполне достаточно.

Итак, приступаем к боевым действиям. Задача: получить средство быстрого создания и дублирования виртуальных хостов, которые могли бы находиться в той же сети.

На возможностях программы я особо останавливаться не буду, всё просто и понятно. Главный вопрос, с которым мне пришлось столкнуться - как вывести машины в сеть. Дело в том, что для *nix систем этой информации в сети было море, а для win - нет.

Общий принцип - для того, чтобы виртуальная машина могла общаться по сети с хост машиной, нужен так называемый tap интерфейс (Traffic Accounting Protocol). Но глупая w2k3 в своём составе не имеет средств для создания tap интерфейсов и придётся поставить эти средства отдельно. Для этого нам понадобится дистрибутив OpenVPN, который можно найти тут: http://openvpn.net/index.php/downloads.html. OpenVPN так же является свободной разработкой, о чём гласит надпись на их сайте "OpenVPN is Free Software released under the GNU/GPL License." При установке мы должны выбрать только TAP-Win32 Virtual Ethernet Adapter, убрав все остальные галочки. На вопросы о совместимости оборудования отвечаем "Всё равно продолжить". После окончания установки у нас появится новый сетевой интерфейс. Если windows русская, то она его назовёт "Подключение по локальной сети" + какой-то номер. Заходим в Панель управления > Сеть и подключения к Интернету > Сетевые подключения. Там видим ещё одно подключение (сетевой кабель не подключен). Подводим к нему мышь и во всплывающей подсказке мы должны увидеть что-то вроде TAP-Win32 Adapter V8. Нажимаем правой кнопкой мыши и выбираем пункт "Переименовать", после чего даём нашему тап интерфейсу для определённости имя tap0. Затем в Qemu Manager нажимаем на иконку с красным плюсом, вводим имя машины, задаём количество памяти и размер жётского диска. После чего нажимаем кнопку с надписью Create, переходим на вкадку Networking в правой части окна, дважды кликаем на строку VLAN0 User Networking и в выпадающем меню Network Type выбираем пункт Tap Networking. В появившейся строке VLAN0 Tap ID вводим имя нашего tap интерфейса. В данном случае tap0. Теперь необходимо объёдинить его с физическим интерфейсом. Заходим в Сетевые подключения, одиночным щелчком выделяем наш tap интерфейс и удерживая Ctrl выделяем физический интерфейс, потом на одном из них нажимаем правой кнопкой мыши и выбираем пункт "Подключение типа мост". Всё, наша виртуальная машина будет использовать нашу реальную сетевую карту для общения с сетью. В отличие от юникса нам понадобится две сетевых карты. Одна - для хост системы, другая для виртуальных машин. Так же, нам надо заранее создать столько tap интерфейсов, сколько виртуальных машин предполагается держать включенными одновременно. Добавить новый tap интерфейс можно запустив скрипт C:\Program Files\OpenVPN\bin\addtap.bat, после чего его нужно будет по аналогии переименовать в tap1. Привязать его к мосту можно в свойствах моста, просто отметив галочкой.

Часть 2. Любимый linux. Или чем всё закончилось.

Придя к выводу, что виртуальные машины - это часто очень удобно, я решил сделать дома себе ещё одну "платформу виртуализации". Так как память и жёсткие диски сейчас довольно дёшевы, я сделал себе новогодний подарок - 8Гб оперативной памяти и 2 жёстких диска по 640Гб с кешем 32Мб. Зачем так много? Я знаю, что хватило бы и меньшего, но это на "вырост". Итак, что нам необходимо - возможность запускать виртуальные машины, используя те же образы жёстких дисков, что и под win, которые находились бы в той же сети, что и наша машина, другими словами, реализовать то же самое, что мы уже рассмотрели выше, только средствами linux.

Сейчас моя машина работает под 64-х битной Ubuntu 8.10. Для начала нужно установить два пакета - quemu и qemuctl, которые есть практически в любом дистрибутиве. Под дистрибутивами, основанными на debian это можно сделать, дав комманду sudo apt-get install qemu qemuctl. Первый из пакетов - это собственно сам эмулятор, второй - средство для управления им, которое потребуется нам например в случае необходимости послать эмулятору Ctrl+Alt+Del. Синтаксис параметров запуска qemuctl полностью совпадает с таковым для qemu.

Предположим, образ жёсткого диска для виртуальной машины называется disk.dsk и лежит в директории, из которой происходит запуск и мы хотим выделить машине 256 мегабайт оперативной памяти. Команда будет выглядеть так:

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

Теперь вернёмся к вопросам работы с сетью. Сразу оговорюсь, что мой способ несколько отличается от тех, что я видел в сети.

Нам нужно создать так называемый мост (объединение интерфейсов на канальном уровне), после чего для каждой виртуальной машины создавать виртуальный tap интерфейс и объединять его с мостом. В отличие от windows, где нам приходилось создавать для каждой виртуальной машины новый tap интерфейс от имени администратора, в linux есть возможность этот процесс автоматизировать и создавать tap интерфейсы автоматически для каждой новой виртуальной машины, а после завершения её работы удалять соответствующий интерфейс. Конечно, для этих действий так же необходимы права супер пользователя, но мы решим эту проблему при помощи sudo. Далее необходимо будет произвести ряд действий от имени суперпользователя, поэтому можно воспользоваться командами sudo -s либо su -.

Сначала установим пакет bridge-utils, который позволит нам работать с соединениями типа мост.

Ещё в нашей системе должны иметься средства для работы с tun/tap интерфейсами. Обычно это tunctl, но в моей системе (ubuntu 8.10) он почему-то назывался vde_tunctl. Вы можете это проверить следующим образом:

В случае, если у Вас этот исполняемый файл называется tunctl, укажите его в скриптах вместо vde_tunctl.
Далее нам необходимо создать мост. Делается это примерно следующим образом:
Сначала наш физический интерфейс должен быть поднят без адреса

Затем мы должны создать новый мост, добавить физический интерфейс к созданному мосту и поднять мост с теми же настройками, какие имел физический интерфейс, всё довольно просто

либо если машина получает адрес через DHCP

В debian-based дистрибутивах настройки интерфейсов находятся в файле /etc/network/interfaces. Если мы рассчитываем работать с виртуальными машинами постоянно, то будет целесообразно внести настройки в него, чтобы они остались после перезагрузки системы.
Для определённости возьмём тот же пример, когда интерфейс сетевой карты называется eth0 и имеет адрес 192.168.1.1 или получает его посредством обращения к DHCP. Тогда содержимое файла /etc/network/interfaces будет примерно следующим:

в случае, если ip адрес был задан статически или

если адрес был получен посредством DHCP.
Вот на что мы должны заменить содержимое:

либо в случае с DHCP

Теперь у нас есть мост, к которому мы можем добавлять любые интерфейсы в нашей системе. Для добавления и удаления tap интерфейсов мы напишем пару скриптов, которые будут выполняться до старта виртуальной машины и после окончания её работы.

Я обычно использую в своей работе vim, Вы можете воспользоваться тем, что привычнее Вам, скажем, nano или mcedit. Следующая комманда откроет текстовый редактор и после сохранения создаст файл /usr/sbin/tapup:

Ниже содержимое скрипта:

Скрипт вызывается с двумя параметрами, первый из которых - имя интерфейса нашего моста, в нашем случае, это br0, а второй - имя пользователя, который будет владельцем созданного интерфейса и сможет впоследствии с ним работать. Например вызов /usr/sbin/tapup br0 user создаст tap интерфейс tap0, владельцем которого будет user и привяжет его к мосту br0. При повторном вызове будет создан интерфейс с именем tap1, при следующем - tap2 и т.д.. Первый параметр является обязательным, а второй можно опустить. При этом владельцем интерфейса будет root. C испоьзованием этого скрипта можно будет привязывать tap интерфейсы к различным мостам, что довольно удобно, если наша машина имеет несколько сетевых карт или несколько vlan интерфейсов, естесственно, для этой возможности каждый из них должен входить в состав какого-нибудь моста. При успешном выполнении скрипт выдаёт имя созданного интерфейса, нам это будет нужно.
Движемся далее. Создадим скрипт для удаления существующего интерфейса.

Здесь всё просто. tap интерфейс удаляется по имени, имя - это единственный и обязательный параметр. Не забудьте изменить vde_tunctl на tunctl, если он называется так в Вашей системе.
Теперь создадим группу, которая будет иметь право работать с qemu.

Перейдём в папку /usr/sbin и изменим владельца и права на наши скрипты:

Проверяем, что получилось

Редактируем файл /etc/sudoers и добавляем в него следующие строки:

Теперь добавляем пользователя, которому нужно будет работать с виртуальными машинами в группу qemu:

Теперь, если Вы внесли изменения в /etc/network/interfaces, необходимо перезапустить службу

Проверяем, что получилось:

Затем входим под логином пользователя user, желательно это сделать не в иксах, а в одной из консолей, которые доступны по сочетанию клавиш Ctrl+Alt+F1 - Ctrl+Alt+F6 и проверяем, как работают наши скрипты:

Всё замечательно. Пользователи, входящие в группу qemu ограничены в правах для работы с tunctl (vde_tunctl) и brctl напрямую, но имеют возможность работать с мостами и tap интерфейсами в той мере, в которой это необходимо для вывода в сеть виртуальных машин.

Теперь нам нужно ещё два скрипта. qemu, во всяком случае тот, что находится в репозитории ubuntu 8.10 при старте сети с поддеркой tap интерфейса выполняет скрипт /etc/qemu-ifup, без которого виртуальная машина просто не запустится. Поэтому на его место мы выложим заглушку - скрипт, который ничего не делает.

При завершении работы тоже должен исполняться скрипт - /etc/qemu-ifdown, но при его отсутствии в поток ошибок, который при старте скрипта запуска не из консоли Вы просто не увидите, может выдаваться ошибка. Думаю, это не существенно.

Теперь всё готово. Пишем последний скрипт, который будет запускать нашу виртуальную машину.

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

Примечание: так как по умолчанию qemu эмулирует хоть и довольно распространённую в своё время, но уже довольно старую сетевую карту Realtek на базе чипа rtl8029, которую Windows 2003 уже не знает и драйвера на которую для этой операционной системы я так и не смог поставить, как ни бился, то для корректной работы с сетью стоит указывать другой тип сетевого адаптера. Например, rtl8139. Тогда строка запуска будет выглядеть следующим образом:

Работа с сетью в 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

Настройка сети для виртуальных машин в 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 уже установлена. Для начала нужно создать пустой образ диска:

Теперь настроим сеть в режим сетевого моста для проброса сети к виртуальной машине. Копируем /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. Об остальных опциях можно узнать в мане):

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

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

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