Ошибка при создании виртуальной сети internal error network is already in use by interface eth0

Иногда можно не возиться с полной или пара-виртуализацией с помощью qemu, а запустить lxc-контейнер с userspace-окружением RHEL/CentOS 6/7 или Fedora 19-23-…-rawhide, чтобы быстро что-нибудь сделать, не относящееся к ядру. Преимущество lxc-контейнера над qemu-виртуализацией в том, что не надо возится с файлами образов дисков и установкой системы с инсталляционного диска или по сети. Наоборот, можно просто установить несколько необходимых «bootstrap» пакетов в обычную директорию на хост-системе и на этом всё. Ну и lxc-контейнеры исключительно быстро стартуют и завершаются, потому что по факту это просто набор процессов. RHEL/CentOS 6 для хост-системы не подойдёт, так как у них в репозиториях нет необходимых пакетов libvirt-*-lxc.

Несколько общих слов про lxc-контейнеры в RHEL/CentOS 6/7 и Fedora 19+. Есть минимум 3 их реализации. Первая — это как бы «голый» lxc, описанный у меня в статье «Установка и использование контейнеров LXC 1.0 в RHEL/CentOS 6.5». Почти все настройки для него нужно делать ручками, что удобно, только если вы понимаете что делаете, прям как я. Иначе — неудобно. Вторая реализация — это docker (а так же rocket/rkt и подобные), который сейчас дофига модный и делает (почти) всё за вас. Проблема с docker-ом в том, что надо возиться с установкой и настройкой самого docker-а. Третья реализация — вируальная машина (точнее, lxc-контейнер) внутри libvirt-а, но с backend-ом виртуализации не qemu, а lxc. Именно её мы рассмотрим в этой статье.

Ахтунг: технология libvirt + lxc объявлена устаревшей, начиная с RHEL/CentOS 7.1 и может быть выпилена из оных в любом релизе. Вы строите свою продакшн-инфраструктуру на этой технологии на свой страх и риск. Больше подробностей в статье Linux Containers with libvirt-lxc (deprecated).

Ниже предполагается, что у нас есть установленный хост RHEL или CentOS 7 или Fedora 19+ с минимальным набором пакетов, но с графикой (вариант установки «Server with GUI»), для virt-manager-a и virt-viewer-a. Без графики тоже можно, тогда доступ в консоль lxc-контейнера будет в текстовом режиме с помощью virsh console.

• Установка необходимых пакетов или группы пакетов с виртуализацией

Можно поставить целиком группу пакетов относящихся к виртуализации. Ранее в RHEL/CentOS была одна группа Virtualization, потом её разбили на несколько меньших (прочесть о спрятанных группах можно здесь), в Fedora так и оставили одну, поэтому посмотреть что у вас на конкренто вашей системе можно так:

[root@centos7 ~]# yum group list -v hidden | grep -i virt
   Virtualization Host (virtualization-host-environment)
   Virtualization Client (virtualization-client)
   Virtualization Hypervisor (virtualization-hypervisor)
   Virtualization Platform (virtualization-platform)
   Virtualization Tools (virtualization-tools)

В Fedora как была одна группа пакетов, так и осталась. Заметьте, в Fedora с версии 23 используется пакетный менеджер dnf вместо yum:

[root@fed23 ~]# dnf group list -v hidden | grep -i virt
   Virtualization (virtualization)

Посмотреть состав группы, например Virtualization Client можно так:

[root@centos7 ~]# yum group info 'Virtualization Client'
Group: Virtualization Client
 Group-Id: virtualization-client
 Description: Clients for installing and managing virtualization instances.
 Mandatory Packages:
    gnome-boxes
   +virt-install
   +virt-manager
   +virt-viewer
 Default Packages:
   +virt-top
 Optional Packages:
   libguestfs-tools
   libguestfs-tools-c

Нам нужны группы Virtualization Client, Virtualization Platform и пакеты libvirt-daemon-driver-lxc и libvirt-daemon-lxc:

[root@centos7 ~]# yum group install 'Virtualization Client' 'Virtualization Platform'
[root@centos7 ~]# yum install libvirt-daemon-driver-lxc libvirt-daemon-lxc

Но для совсем минимальной инсталляции (чтобы не тащить, например, qemu) достаточно установить следующие пакеты (плюс, естественно, зависимсости):

[root@centos7 ~]# yum install libvirt-daemon-driver-lxc libvirt-daemon-lxc libvirt-daemon-config-network virt-install virt-manager virt-viewer

• Запуск демона libvirtd и подключение к нему virt-manager-ом

После этого надо стартовать демон libvirtd (или перезагрузиться, он должен быть настроен стартовать при загрузке):

[root@centos7 ~]# systemctl start libvirtd

[root@centos7 ~]# systemctl status libvirtd
libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Sat 2066-66-66 66:66:66 UTC; 66min ago

Если не запустить демон libvirt, virt-manager не сможет к нему подключится. Чтобы подключится к бегущему демону, запускаем virt-manager, идём в File -> Add Connection… и выбираем тип локального гипервизора «LXC (Linux Containers)»:

Подключение «localhost (LXC)» должно появиться в окне virt-manager-а.

• Ошибка «libvirtd: internal error: Network is already in use by interface» при старте libvirtd

Иногда внезапно вы можете получить эту ошибку при старте libvirtd, особенно если вы запускаете его в виртуальной машине qemu:

[root@centos7 ~]# systemctl status libvirtd -l
...
Nov 66 66:66:66 centos7 systemd[1]: Started Virtualization daemon.
Nov 66 66:66:66 centos7 libvirtd[860]: libvirt version: 1.2.8, package: 16.el7_1.5 (CentOS BuildSystem <http://bugs.centos.org>)
Nov 66 66:66:66 centos7 libvirtd[860]: internal error: Network is already in use by interface eth0

Сообщение не очень понятное, но оно значит вот что. libvirtd хочет создать бридж с дефолтным диапазоном IP-адресов 192.168.122.0/24 на одном из интерфейсов хоста. Но может оказаться, что этот диапазон уже используется на каком-то из интерфейсов, eth0 в данном случае. Тогда бридж создать невозможно, о чём libvirtd и уведомляет. Решение — пересоздать сеть default изменив дефолтный диапазон 192.168.122.0/24 на что-то другое (например, на 10.0.0.0/16) в Virtual Machine Manager -> Edit -> Connection Details -> Virtual Networks -> IPv4 configuration:

Или остановить демон libvirtd, отредактировать диапазон IP-адресов сети default в файле /etc/libvirt/qemu/networks/default.xml и запустить демон заново:

[root@centos7 ~]# systemctl stop libvirtd

[root@centos7 ~]# cat /etc/libvirt/qemu/networks/default.xml
<network>
  <name>default</name>
  <uuid>f50db5d8-8e83-451f-9f37-0ec5d7c1959a</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:66:66:66'/>
  <ip address='10.0.0.1' netmask='255.255.0.0'>
    <dhcp>
      <range start='10.0.0.2' end='10.0.255.254'/>
    </dhcp>
  </ip>
</network>

[root@centos7 ~]# systemctl start libvirtd

После этого libvirtd должен успешно создать бридж virbr0 с назначенным диапазоном IP-адресов:

[root@centos7 ~]# ip a s virbr0
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 52:54:00:66:66:66 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/16 brd 10.0.255.255 scope global virbr0
       valid_lft forever preferred_lft forever

[root@centos7 ~]# systemctl status libvirtd -l
Nov 66 66:66:66 centos7 systemd[1]: Started Virtualization daemon.
Nov 66 66:66:66 centos7 dnsmasq-dhcp[3024]: DHCP, IP range 10.0.0.2 -- 10.0.255.254, lease time 1h

• Запуск virt-manager от обычного пользователя без пароля

В Fedora 20+ virt-manager запросит рутовый пароль если его запускать от обычного пользователя в графической оболочке. В RHEL/CentOS 7 — нет, так как они построены на кодовой базе Fedora 19, а virt-manager начал уметь в PolicyKit (который и заставляет спрашивать рутовый пароль) только с Fedora 20. Больше деталей про это здесь.

Чтобы убрать этот запрос надо добавить вашего обычного пользователя в группу wheel (или любую другую) и создать файл /etc/polkit-1/rules.d/80-libvirt.rules со следующим кодом:

[root@rules ~]# usermod -G wheel someuser

[root@rules ~]# cat /etc/polkit-1/rules.d/80-libvirt.rules 
polkit.addRule(function(action, subject) {
  if (action.id == "org.libvirt.unix.manage" && subject.local && subject.active && subject.isInGroup("wheel")) {
      return polkit.Result.YES;
  }
});

• Создание lxc-контейнера CentOS 7

Несколько общих слов про «bootstrapping» lxc-контейнера. Чтобы контейнер заработал, надо установить в него некий минимальный набор пакетов, которых достаточно для функционирования минимальной системы. Скорее всего это будут пакеты инициализации (systemd или upstart или Sys V init-скрипты) и пакетный менеджер (и, естественно, их зависимости). Этот начальный набор пакетов надо установить в директорию lxc-контейнера из хост-системы, так как самого контейнера пока нет. Для этого у yum (и dnf) есть волшебный ключ --installroot. Но чтобы yum знал откуда брать пакеты для операционной системы контейнера, ему это надо сказать файлами <корень-контейнера>/etc/yum.repos.d/*.repo. В частном случае, когда ОС хоста и контейнера одинакова (например мы создаём контейнер с CentOS 7 на хосте CentOS 7) это можно не делать.

Посмотреть, какие версии CentOS доступны для установки по сети можно на странице http://mirror.centos.org/centos/. .repo-файлы нужные нам для седьмой версии на момент написания статьи лежат в пакете centos-release-7-1.1503.el7.centos.2.8.x86_64.rpm. Использование таких пакетов будет описано во второй части статьи, пока для простоты создадим .repo-файлы руками.

Итак, предположим, мы создаём lxc-контейнер с CentOS 7 в директории /srv/centos7. Создадим нужные каталоги и .repo-файлы. Репозитории [base] и [updates] будут брать пакеты из сети с ближайшего зеркала. Если у вас нет сети, но есть установочный диск CentOS 7, смонтированный в директорию (например) /run/media/root/CentOS_7_x86_64/, можно ставить пакеты с него, для этого описан пока выключенный репозиторий [media]. Чтобы устанавливать пакеты с установочного диска, а не из сети, установите enabled=1 для репозитория [media], а enabled=0 для остальных репозиториев:

[root@centos7 ~]# mkdir -p /srv/centos7/etc/yum.repos.d/

[root@centos7 ~]# cat /srv/centos7/etc/yum.repos.d/bootstrap.repo
[base]
name=CentOS-$releasever - Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
enabled=1

[updates]
name=CentOS-$releasever - Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
enabled=1

[media]
name=CentOS-$releasever - Media
baseurl=file:///run/media/root/CentOS_7_x86_64/
enabled=0

Собственно, всё готово к установке bootstrap-пакетов. После установки можно удалить файл /srv/centos7/etc/yum.repos.d/bootstrap.repo, он больше не нужен. Заметьте, всё это мы пока делаем из хост-системы. Волшебная команда, которая делает магическую магию, такова:

[root@centos7 ~]# yum -y --installroot=/srv/centos7/ --releasever=7 --nogpg install systemd passwd yum centos-release vim-minimal openssh-server procps-ng iproute net-tools dhclient sudo rootfiles

[root@centos7 ~]# rm -f /srv/centos7/etc/yum.repos.d/bootstrap.repo

Далее, ещё из хост-системы надо провести некоторую первоначальную настройку lxc-контейнера с CentOS 7 ещё до его первого запуска. Сначало надо установить рутовый пароль (например, «rootpw») с помощью магии chroot:

[root@centos7 ~]# chroot /srv/centos7/ /bin/bash -c "/bin/echo rootpw | /usr/bin/passwd --stdin root"
Changing password for user root.
passwd: all authentication tokens updated successfully.

Или убрать рутовый пароль вообще и не забыть разрешить демону sshd пускать с пустым паролем:

[root@centos7 ~]# sed -i -e '/^root:/croot::16666:0:99999:7:::' /srv/centos7/etc/shadow
[root@centos7 ~]# sed -i -e '/PermitEmptyPasswords/cPermitEmptyPasswords yes' /srv/centos7/etc/ssh/sshd_config

Далее нужно добавить консоль контейнера как «доверенный» терминал, без этого система не пустит рута с консоли:

[root@centos7 ~]# echo pts/0 >> /srv/centos7/etc/securetty

Далее нужно сделать демон sshd запускаемым при старте контейнера (эта линка может уже существовать, тогда команда пофэйлится, но это нормально):

[root@centos7 ~]# ln -s /usr/lib/systemd/system/sshd.service /srv/centos7/etc/systemd/system/multi-user.target.wants/

Зададим имя хоста внутри контейнера:

[root@centos7 ~]# echo centos7-lxc.localdomain > /srv/centos7/etc/hostname

Теперь, шаг с которым наиболее вероянто могут возникнуть проблемы — кофигурация сети внутри контейнера. Мы хотим, чтобы интерфейс eth0 получал настройки по DHCP, поэтому создаём файлы с таким содержанием:

[root@centos7 ~]# touch /srv/centos7/etc/sysconfig/network

[root@centos7 ~]# cat /srv/centos7/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp

И, наконец, создаём и запускаем контейнер с помощью virt-install (больше деталей про опцию --os-variant упомянуто ниже):

[root@centos7 ~]# virt-install --connect lxc:// --name centos7 --ram 512 --os-variant=centos7.0 --filesystem /srv/centos7/,/
Starting install...
Creating domain...
Connected to domain centos7
Escape character is ^]
systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
Detected virtualization 'lxc-libvirt'.
Welcome to CentOS Linux 7 (Core)!
Set hostname to <centos7-lxc.localdomain>.
Initializing machine ID from container UUID.
...
CentOS Linux 7 (Core)
Kernel 3.10.0-229.el7.x86_64 on an x86_64

centos7-lxc login:

Позднее запустить остановленный контейнер и войти в него можно из графического интерфейса virt-manager-а или из текстового терминала с помощью virsh start и virsh console. Внимание: чтобы войти в контейнер из текстовой консоли virt-manager не должен быть запущен! Отсоединиться от консоли контейнера можно нажав Ctrl-]:

[root@centos7 ~]# virsh --connect lxc:// start centos7
Domain centos7 started

[root@centos7 ~]# virsh --connect lxc:// console centos7
Connected to domain centos7
Escape character is ^]
systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
Detected virtualization 'lxc-libvirt'.
...
CentOS Linux 7 (Core)
Kernel 3.10.0-229.el7.x86_64 on an x86_64

centos7-lxc login:

Итак, зайдём в контейнер и осмотримся, проверим, что всё как надо, памяти столько, скольно назначено, стоит правильное имя хоста и есть сеть:

[root@centos7 ~]# virsh --connect lxc:// console centos7
CentOS Linux 7 (Core)
Kernel 3.10.0-229.el7.x86_64 on an x86_64

centos7-lxc login: root

[root@centos7-lxc ~]# uname -a
Linux centos7-lxc.localdomain 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[root@centos7-lxc ~]# grep ^MemTotal /proc/meminfo 
MemTotal:         524288 kB

[root@centos7-lxc ~]# ip a s eth0
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 66:66:66:66:66:66 brd ff:ff:ff:ff:ff:ff
    inet 10.0.207.19/16 brd 10.0.255.255 scope global dynamic eth0
       valid_lft 2909sec preferred_lft 2909sec
    inet6 fe80::6666:66ff:fe66:6666/64 scope link 
       valid_lft forever preferred_lft forever

[root@centos7-lxc ~]# ping google.com
PING google.com (666.666.666.666) 56(84) bytes of data.
64 bytes from icmp.google.com (666.666.666.666): icmp_seq=1 ttl=52 time=1.1 ns
64 bytes from icmp.google.com (666.666.666.666): icmp_seq=2 ttl=52 time=1.7 ns

[root@centos7-lxc ~]# yum repolist
Loaded plugins: fastestmirror
repo id                             repo name                             status
base/7/x86_64                       CentOS-7 - Base                       8652
extras/7/x86_64                     CentOS-7 - Extras                      277
updates/7/x86_64                    CentOS-7 - Updates                    1707

Как бы, каза лось бы, ура.

• Создание lxc-контейнера RHEL 7

Почти ничем не отличается от создания lxc-контейнера CentOS 7. Проблема в установке bootstrap-пакетов. Так как доступ к пакетам RHEL требует регистрации, нельзя просто так взять и описать RHEL-репозитории в .repo-файлах, <картинка-с-боромиром.jpg>, нужна ещё регистрация, чтобы скачать пакеты RHEL 7 из сети из Red Hat Network. Поэтому нужно либо иметь установочный диск RHEL 7 и использовать репозиторий [media]. Либо устанавливать lxc-контейнер RHEL 7 из зарегистрированной хост-системы RHEL 7, тогда yum использует регистрацию хост-системы для скачивания пакетов.

Значение --releasever должно быть не 7, а 7Server. Набор bootstrap-пакетов также немного другой. То есть, магически волшебные команды такие:

[root@rhel7 ~]# yum -y --installroot=/srv/rhel7/ --releasever=7Server --nogpg install systemd passwd yum redhat-release vim-minimal openssh-server procps-ng iproute net-tools dhclient sudo rootfiles

[root@rhel7 ~]# virt-install --connect lxc:// --name rhel7 --ram 512 --os-variant=rhel7 --filesystem /srv/rhel7/,/

В virt-install надо использовать --os-variant=rhel7. Также, чтобы устанавливать софт и получать обновления, надо зарегистрировать контейнер в Red Hat Network как отдельную систему. Или устанавливать пакеты в контейнер из зарегистрированной хост системы. В остальном всё так же.

• Создание lxc-контейнеров в хост-системе Fedora 22+

В Fedora начиная с версии 22 и дальше пакетный мереджер yum был заменён на dnf и, внезапно, поведение опции --installroot измени лось. Теперь dnf не использует репозитории заданные в директории <корень-контейнера>/etc/yum.repos.d/, но использует не нужные в нашем случае репозитории из хост-системы. К счастью, эта функциональность была возложена на настройку reposdir, которая позволяет отдельно указать директорию с репозиториями. Что интересно, на момент написания этой статьи это отличие от yum не указано здесь, где, по-идее, должно бы.

Соответственно, очень волшебная и не менее магическая команда по установке bootstrap-пакетов в контейнер /srv/centos7 с помощью dnf на Fedora 22+ (после создания файла /srv/centos7/etc/yum.repos.d/bootstrap.repo с репозиториями) будет:

[root@fedora23 ~]# dnf --setopt=reposdir=/srv/centos7/etc/yum.repos.d/ --installroot=/srv/centos7/ --releasever=7 --nogpg install systemd passwd yum centos-release vim-minimal openssh-server procps-ng iproute net-tools dhclient sudo rootfiles

• Создание lxc-контейнера из готового образа от linuxcontainers.org

Внезапно, никто не запрещает особенно ленивым задницам вроде вас использовать уже готовые рутовые файловые системы с images.linuxcontainers.org. Достаточно взять готовый образ rootfs.tar.xz, распаковать его и создать контейнер с помощью virt-install. Образы пересоздаются каждый день, поэтому ссылка, скорее всего, уже не рабочая. Возьмите сами файл rootfs.tar.xz из каталога доступных образов CentOS 7.

Дальше, по-идее, всё просто: распаковать, задать имя системы, задать или сбросить рутовый пароль (на момент написания статьи по-умолчанию задан пароль «root» и требуется создание нового пароля при первом логине) и создать контейнер. На сейчас сеть в контейнере конфигуряется legacy-сервисом network, поэтому настройки сети можно менять в файле /etc/sysconfig/network-scripts/ifcfg-eth0.

[root@centos7 /]# wget http://images.linuxcontainers.org/images/centos/7/amd64/default/20151201_02:16/rootfs.tar.xz

[root@centos7 /]# mkdir -p /srv/centos7/ &&  tar -C /srv/centos7/ -xf rootfs.tar.xz

[root@centos7 ~]# echo centos7-lxc.localdomain > /srv/centos7/etc/hostname
[root@centos7 ~]# sed -i -e '/^root:/croot::16666:0:99999:7:::' /srv/centos7/etc/shadow

[root@centos7 /]# virt-install --connect lxc:// --name centos7 --ram 512 --os-variant=centos7.0 --filesystem /srv/centos7/,/
Starting install...
Creating domain...
...
CentOS Linux 7 (Core)
Kernel 3.10.0-229.el7.x86_64 on an x86_64

centos7-lxc login: root
[root@centos7-lxc ~]# ip a s eth0
7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 66:66:66:66:66:66 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.39/16 brd 10.0.255.255 scope global dynamic eth0
       valid_lft 3558sec preferred_lft 3558sec
    inet6 fe80::6666:66ff:fe66:6666/64 scope link 
       valid_lft forever preferred_lft forever

Наслаждайтесь.

• Замечания об опции —os-variant команды virt-install

Внезапно может возникнуть вопрос, какие ещё значения можно использовать в опции --os-variant команды virt-install, кроме centos7.0 или rhel7. К сожелению, команда virt-install, поставляемая с RHEL/CentOS 7 на момент написания статьи не поддерживает вывод допустимых значений этой опции с помощью --os-variant list --os-variant help или --os-variant=?. Если надо, можно использовать быстрый и грязный хак файла /usr/share/virt-manager/virtinst/guest.py, который выведет список допустимых вариантов, если еспользован неправильный:

(патч к файлу guest.py)

--- /usr/share/virt-manager/virtinst/guest.py
+++ /usr/share/virt-manager/virtinst/guest.py.new
@@ -215,6 +215,8 @@
         if val:
             val = val.lower()
             if osdict.lookup_os(val) is None:
+                for osname in osdict._allvariants:
+                    print osname
                 raise ValueError(
                     _("Distro '%s' does not exist in our dictionary") % val)

Теперь, запустив virt-install с какой-нибудь чушью в --os-variant, получим список допустимых значений этой опции:

[root@centos7 /]# virt-install --connect lxc:// --name ololo --ram 128 --os-variant=ololo
openbsd5.1
freebsd5.5
solaris
ubuntu11.10
...
win2k
generic
ubuntu13.10
openbsd4.9
ERROR    Error validating install location: Distro 'ololo' does not exist in our dictionary

• Создание lxc-контейнеров Fedora 23 и Rawhide

Вторая часть: Контейнерная виртуализация LXC в libvirt на RHEL/CentOS 7 и Fedora 19+. Часть 2. Контейнеризуем Fedora 23 и Rawhide.

Пыщь! Оригинал поста размещен в блоге Ад, ненависть и локалхост. Комментить? Набигай. Подкат? ОИНЧ.

I have set up a virtual networking on my CentOS 7 Workstation and the primary physical network interface is bridged as per this RHEL article.

libvirtd is running successfully, however after reboot this is what happens

virsh net-list --all
Name                 State      Autostart     Persistent
----------------------------------------------------------
default              inactive   yes           yes

If I try to start the default bridge. This is what I get

virsh net-start default 
error: Failed to start network default
error: internal error: Network is already in use by interface virbr0

So put the virtual bridge (virbr0) down and deleted the default bridge.

ifconfig virbr0 down
virsh net-start default 
Network default started

virsh net-list --all
Name                 State      Autostart     Persistent
----------------------------------------------------------
default              active     yes           yes

Once the virtual bridge (default) is active, I completely loose internet connectivity on my KVM host. Cannot ping www.google.com

Any idea why might be happening or any miss configuration that has occurred? I have the following interface scripts

Primary physical interface: ifcfg-enp1s0

TYPE="Ethernet"
NAME="enp1s0"
HWADDR=2c:27:d7:ef:fd:1e
UUID="f7fb856b-1879-411d-b8a4-0ef8c93303dc"
DEVICE="enp1s0"
ONBOOT="yes"
BOOTPROTO=dhcp
BRIDGE=virbr0
NM_CONTROLLED=no

Virtual Bridge interface: ifcfg-virbr0

DEVICE=virbr0
ONBOOT=yes
TYPE=Bridge
BOOTPROTO=none
IPADDR=192.168.3.52
NETMASK=255.255.255.0
GATEWAY=192.168.3.1
STP=on
DELAY=0
NM_CONTROLLED=no

Hi. I’ve used this tutorial  and have net-define’ed a network from this xml, but when i try to net-start it, i get the following error:

virsh # net-start default
error: Failed to start network default
error: internal error Network is already in use by interface virbr0

At first i though that some other network has already been defined and auto-started, so i’ve checked net-list

virsh # net-list --all
Name                 State      Autostart
-----------------------------------------
default              inactive   no  

Here is the output from $ ip a show dev virbr0

4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether ce:1e:b4:54:83:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0

I became curious, and found out that dnsmasq was running

$ ps -ef | ack dnsm | ack -v ack
nobody   12333     1  0 13:04 ?        00:00:00 dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override

With that i thought that everything works just fine, and i should try to configure a virtual machine to use the default network.
EDIT:
Looks like $ virsh edit fedora and /etc/libvirt/qemu/fedora.xml contain different things. I am pretty confused.
/etc/libvirt/qemu/fedora.xml
virsh edit fedora

virsh # list --all 
 Id Name                 State
----------------------------------
  - fedora               shut off

virsh # start fedora
error: Failed to start domain fedora
error: internal error Network 'default' is not active.

How can it be started and not started at the same time?

Last edited by blin (2011-12-18 14:51:49)

PS1='[$(date +%H:%M:%S) — H] n[$(pwd)]$ ‘

Мостовой способ настройки сети libvirt

1、network.xml

<network>

<name>local</name>

<bridge name="local"/>

<forward mode="route" dev="eth0"/>

<ip address="192.168.0.204" netmask="255.255.255.0">

    <dhcp>

         <range start="192.168.0.1" end="192.168.0.253"/>

    </dhcp>

</ip>

</network>

Где 192.168.0.204 — IP-адрес хоста, а шлюз — 192.168.0.254.

Если сообщается об ошибке:

2. Измените / etc / network / interface, сохраняйте только

auto lo
iface lo inet loopback 

dns-nameservers 192.168.0.254

3. Автоматический запуск скрипта при загрузке:

#!/bin/sh

sleep 3

ifconfig eth0 up

brctl add local eth0

route del default

route add default gw 192.168.0.254 metric 0 dev local

4. Перезагрузите машину, и вы увидите:

[email protected]:~# virsh net-list --all
Name                 State      Autostart
-----------------------------------------
default              active     yes
local                active     yes

eth0      Link encap:Ethernet  HWaddr 00:1e:68:04:74:68
          inet6 addr: fe80::21e:68ff:fe04:7468/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3085 errors:0 dropped:0 overruns:0 frame:0
          TX packets:248 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:491876 (491.8 KB)  TX bytes:43962 (43.9 KB)
          Interrupt:18 Memory:fd9e0000-fda00000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:167 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8376 (8.3 KB)  TX bytes:8376 (8.3 KB)

local     Link encap:Ethernet  HWaddr 00:1e:68:04:74:68
          inet addr:192.168.0.204  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1308 errors:0 dropped:0 overruns:0 frame:0
          TX packets:238 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:132498 (132.4 KB)  TX bytes:41842 (41.8 KB)

virbr0    Link encap:Ethernet  HWaddr ea:44:0a:49:d4:50
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[email protected]:/opt# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.254   0.0.0.0         UG    0      0        0 local
192.168.0.0     *               255.255.255.0   U     0      0        0 local
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
[email protected]:/opt#

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

 <interface type='bridge'>
      <source bridge='local' />
      <mac address="00:2c:be:1a:fa:80"/>
      <model type="virtio" />
</interface>

Я могу показать вам, как создать мостовое соединение в KVM, но есть разница в отношении VirtualBox: IP-адрес гостевых машин не назначается DHCP-сервером, но это статический IP-адрес, выбранный вами, возможно, за пределами DHCP пул.

Если вы используете кабельное соединение, то на странице libvirt Wiki показано, как соединить интерфейс Ethernet с вашими виртуальными машинами.

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

Этот хороший пост от Bohdi Zazen показывает, как это сделать. Он использует АРП-прокси для передачи агр трафика на специально созданный интерфейс крана. Существует только одна устаревшая функция — создание интерфейса крана с помощью команды / пакета tunctl. Не делайте этого, iproute может позаботиться об этом за вас:

    ip tuntap add tap0 mode tap user root
    ip link set tap0 up

В противном случае его решение работает без нареканий.

Если мысль об использовании статического IP-адреса вам невыносима, вы можете использовать NAT, а не мост, как объясняется здесь.