Ошибка при создании виртуальной сети 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.

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

Источник

Иногда можно не возиться с полной или пара-виртуализацией с помощью 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.

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

Источник
  • Home
  • Forum
  • The Ubuntu Forum Community
  • Ubuntu Specialised Support
  • Ubuntu Servers, Cloud and Juju
  • Server Platforms
  • [SOLVED] Ubuntu server hosting virtual machines (dhcp range problem)

  1. Ubuntu server hosting virtual machines (dhcp range problem)

    Hello all,

    I am configuring a network that consists of a physical machine and 10 virtual machines. The physical machine is running ubuntu server (11.04) and I am using qemu/kvm/virt-manager to run the virtual machines.

    Here is my problem. I need the physical host to assign IP addresses in a very specific range, using DHCP, to the virtual machines. I don’t want the range it defaults to. However, when I set this in virt-manager (under connection settings, and then I create a new virtual network with the desired IP range) I get an error that says I can�t start the network I configured because the interface eth0 is already in use.

    What gives!? I tried changing the settings on the default connection using �virsh net-edit default� and I got the same error. The exact error message in virt-manager is �Error starting network: Internal error Network is already in use by interface eth0�. Any advice at all on how to fix this, or any workarounds would be very helpful.

    Thank you!

  2. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    So, it turns out that if I set up a bridge in the /etc/network/interfaces file then I don’t get this error any more. However, I can’t connect to the internet now either. Lol. Any thoughts?

    The bridge is set up like this btw:
    auto lo
    iface lo inet loopback

    auto eth0
    iface eth0 inet manual

    auto br0
    iface br0 inet static
    address 192.168.0.10
    network 192.168.0.0
    netmask 255.255.255.0
    broadcast 192.168.0.255
    gateway 192.168.0.1
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

    (except with my IPs)

  3. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    Ok, nevermind. Bridging it only helped that one time. I tried to do that again and it didn’t change anything. I still don’t know why.

    Does anyone know what the error «Error starting network: Internal error Network is already in use by interface eth0» means? and if I can do anything to get around this? Any help would be greatly appreciated.

  4. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    What are you using for the VM’s? Virtual box VMware or ?

  5. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    You might want to try restart the dnsmasq service when you change your IP range. I am not sure if that will work for you but I had a similar issue once that it resolved.

  6. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    Why not use static IPs for the VMs rather than DHCP? Then you get to specify the precise address each machine will be using.

  7. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    Thanks for the responses. So, I tried restarting dnsmasq (I had to install it first!) by typing «/etc/init.d/dnsmasq restart» and it gave the following output: «* Restarting DNS forwarder and DHCP server dnsmasq dnsmasq: failed to create listening socket for port 53: Address already in use [fail]»

    -I’m not using VMware or virtualbox. I’m using qemu/kvm and I’m using the virt-manager GUI.

    -Here’s why I’m not using static IPs. I actually have more than 10 VMs on my server but I will only be running 10 at once. So, I just want the first 10 VMs that are running to be assigned an IP within a specific range of 10 addreses. I might end up using static IPs, but that just wouldn’t be the ideal situation.

    Thanks.

    Last edited by YouBuntToo?; June 29th, 2011 at 04:47 PM.

  8. Re: Ubuntu server hosting virtual machines (dhcp range problem)

    Thanks for the replies. I finally figured it out. The solution was actually quite simple. In virt-manager when you setup a connection it asks for the network address. The address I had previously setup for eth0 was xxx.xxx.xxx.64/26. I used this same one for the virt-manager connection. Obviously, this is why I was getting the error «Error starting network: Internal error Network is already in use by interface eth0».

    To fix it, in virt-manager i just used xxx.xxx.xxx.64/27, giving the connection a different block of addresses. This solved the problem entirely. I can’t believe it was that simple.

Bookmarks

Bookmarks


Posting Permissions

Источник

0 / 0 / 0

Регистрация: 02.02.2016

Сообщений: 26

1

06.09.2022, 06:49. Показов 816. Ответов 3

Студворк — интернет-сервис помощи студентам

Доброго времени суток, друзья! Пожалуйста выручите горемыку -подскажите пожалуйста по такому вопросу:
Установил операционную систему Astra Linux(хост система)—> в менеджере виртуальных машин создал машину с Windows 7(виртуальная машина). Моя задача состоит в создании сети между виртуальной машиной и хост системой, так же компьютеры которые физически находятся у меня в локальной сети тоже могли подключаться к моей виртуальной машене windows7. Так вот ближе к сути — при создании сетевого интерфейса eth0 типа мост нет, есть маршрутизация, и что бы не выбирал мне всегда выходит сообщение «Ошибка при создании виртуальной сети: internal error: Network is already in use by interface eth0» — якобы интерфейс уже используется. Как быть ? Как создать этот виртуальный интерфейс? Скриншёты прилагаю. Заранее низкий поклон!

Создание виртуального соединения типа "мост" в менеджере виртуальных машин Astra Linux

Создание виртуального соединения типа "мост" в менеджере виртуальных машин Astra Linux



0

Programming

Эксперт

94731 / 64177 / 26122

Регистрация: 12.04.2006

Сообщений: 116,782

 06.09.2022, 06:49

3

_sg2

631 / 234 / 50

Регистрация: 30.08.2017

Сообщений: 1,493

06.09.2022, 08:46

2

Нужно сделать сетевой мост. Для этого в /etc/network/interfaces добавьте настрой настройки моста (настройки loopback/lo не трогайте) . Например для статической настройки:

PureBasic 
1
2
3
4
5
6
7
8
9

$ sudo vim  /etc/network/interfaces
auto br0
iface br0 inet static
address 192.168.1.48
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.1
bridge_ports eth0
bridge_stp off

Отключите все строки в разделе интерфейса eth0, чтобы они выглядели примерно так:

Bash 
1
2

auto eth0
iface eth0 inet manual

Перезапустите сетевую службу.

Bash 
1

 sudo systemctl restart networking.service

Я, слава Богу, уже несколько лет уже не использую Астру, могу подзабыть как там в Дебьянах, поэтому не забывайте сохранять резервную копию конфигурационных файлов. Потом в VMM у Вас появится этот самый мост для выбора и ВМ сможет работать в сети хоста безо всяких NAT.



1

0 / 0 / 0

Регистрация: 02.02.2016

Сообщений: 26

07.09.2022, 06:01

 [ТС]

3

Добрый день. Создал сетевой интерфейс br, как и описали. С хостовой системы на виртуалку пинг идет, но к расшареной папке на виртуалку не могу подключиться. Ошибок никаких не выдает, просто пустое поле. На виртуалке отключил брандмаувер и доступ общий настроил. Так же на хост системе пропал доступ в интернет. Есть еще какие-то варианты настройки?



0

Эксперт NIX

2925 / 816 / 184

Регистрация: 14.01.2013

Сообщений: 3,785

07.09.2022, 07:40

4

Цитата
Сообщение от stalkerovich2
Посмотреть сообщение

Есть еще какие-то варианты настройки?

Можно ходить через SFTP.



0

IT_Exp

Эксперт

87844 / 49110 / 22898

Регистрация: 17.06.2006

Сообщений: 92,604

 07.09.2022, 07:40

4

Источник

Nested virtualization [1] is a nice feature where it’s able to run a virtual machine within another. KVM [2] has support to nested virtualization [3] since 2010 (if I’m not wrong) and you can use it to test virtualization features and/or aspects in a different Linux distribution, or even Windows system. I use this sometimes when I need test some Kimchi [4] patch I’m working in different distros to make sure the solution will work.

However, when you start up a VM using NAT configuration on top of the main hosts system (let’s call them VM-master and host-master) the network interface of the VM will get an IP in the range of 192.168.122.2 and 192.168.254. This is the default configuration of libvirt+qemu on the most of the distros and when you start up a nested VM (let’s call VM-guest) it will start with the same configuration (because of the default configuration on VM-master) and you will not able to connect getting this error:

 libvirt: error : internal error: Network is already in use by interface eth0

The solution is quite simple. You only need edit the /etc/libvirt/qemu/networks/default.xml file on the VM-master and change the IP configuration that the VM-guest will work on:

$ sudo vi/etc/libvirt/qemu/networks/default.xml

%s/192.168.122/10.0.0/g
:wq

$ sudo systemctl restart libvirtd.service

After this, start up your VM-guest and you will be able to connect now.

References:

  1. https://en.wikipedia.org/wiki/Virtualization#Nested_virtualization
  2. http://www.linux-kvm.org/
  3. http://www.linux-kvm.org/images/3/33/02×03-NestedVirtualization.pdf
  4. http://kimchi-project.github.io/kimchi/

Источник

  • Ошибка при смене материнской платы
  • Ошибка при смене каталога arizona rp
  • Ошибка при смене аккумулятора iphone
  • Ошибка при скоринге что это
  • Ошибка при создании виртуальной сети internal error failed to initialize a valid firewall backend