Kvm зайти в виртуальную машину

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Как создавать виртуальные машины на Linux с помощью KVM

Виртуальная машина на основе ядра

В этом руководстве мы расскажем, как установить KVM и как его использовать, чтобы создать виртуальные машины с такими дистрибутивами как RHEL, CentOS 7 и Fedora 21, основанными на RedHat.

Интенсив по Виртуализации VMware vSphere 7

Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware

Что такое KVM?

KVM (Kernel-based Virtual Machine) – это решение для полной виртуализации для Linux на оборудовании Intel 64 и AMD 64, которое включено в основное ядро Linux, начиная с версии 2.6.20. Аппаратные средства работают быстро и стабильно даже при больших нагрузках.

Функции KVM

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

Гипервизор KVM поддерживает следующие функции:

Подготовительная работа

Для хостов на базе AMD ЦП поддерживает расширение виртуализации [svm] :

Если вывод отсутствует, убедитесь, что в BIOS включена опция расширения виртуализации. Убедитесь, что модули KVM загружены в ядро (это должно быть загружено по умолчанию).

Вывод должен содержать kvm_intel для хостов на базе Intel и kvm_amd – на базе AMD.

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

Убедитесь, что Selinux в режиме Permissive.

Шаг 1: Установка KVM

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

Давайте установим эти инструменты с помощью следующей команды:

Для пользователей RHEL/CentOS7 также есть дополнительные группы пакетов, которые можно установить, например: Virtualization Client, Virtualization Platform и Virtualization Tools

Демоном виртуализации, который управляет платформой, является libvirtd. Давайте перезапустим его.

После того, как Вы перезапустили демона, проверьте его статус с помощью следующей команды:

Теперь давайте перейдем к следующему разделу и создадим виртуальную машину.

Шаг 2: Создание ВМ с помощью KVM

Так как мы установили несколько полезных приложений для управления виртуальными платформами и создания виртуальных машин, одно из них –virt-manager – нам сейчас понадобится.

Несмотря на то, что virt-manager является инструментом, основанным на графическом интерфейсе пользователя, из терминала мы можем запускать его так же, как и из GUI.

После того, как Вы запустите приложение, появится такое окно.

Поставьте галочку на Connect to remote host и впишите название или IP (Hostname) удаленного сервера. Если Вам нужно устанавливать соединение с удаленным сервером каждый раз, когда запускается менеджер, то поставьте галочку на Auto Connect.

Давайте вернемся к localhost. Прежде чем создавать виртуальную машину, Вы должны решить, где будут храниться файлы. Другими словами, Вам необходимо создать том (виртуальный диск) для вашей виртуальной машины. Правой кнопкой мыши нажмите на localhost и выберите Details, а затем перейдите на вкладку Storage.

Затем нажмите кнопку New Volume (Новый том) и введите название вашего нового виртуального диска (тома). В графу Max Capacity (Максимальная ёмкость) введите требующийся вам объем диска.

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

Примечание: технология в области администрирования хранилищ называется thin provision (Тонкое обеспечение). Она используется для выделения только используемого объема хранилища, а не всего доступного объема. Например, Вы создали виртуальный диск размером 60 Гб, но используемого объема у Вас только 20 Гб. С помощью данной технологии жёсткий диск предоставит Вам только 20 Гб, а не 60. Другими словами, выделенный физический объем будет динамически распределяться в зависимости от фактического используемого объема.

Знак нового диска появится в списке.

Наконец, мы готовы к созданию виртуальной машины. Нажмите на кнопку VM на главном экране, и появится окно.

Выберите метод установки для создания ВМ. Мы пока выберем Local install media, а позже обсудим оставшиеся методы.

Теперь мы должны выбрать, какой локальный носитель использовать. У нас есть два варианта:

Давайте выберем ISO-образ и введем его путь.

Важно: к сожалению, для тех, кто использует RHEL или CentOS7, здесь есть баг. Он не даёт установить машину с использованием физического носителя CDROM/DVD. Опция просто будет серая:

И если Вы наведете курсор, то появится сообщение об ошибке: physical cdrom passthrough not supported with this hypervisor (Физический CDROM не поддерживает данный гипервайзер).

Больше информации можете узнать здесь.

Снова вопрос про хранилище. Используем виртуальный диск, который мы недавно создали. Он скоро появится.

На последнем шаге Вам необходимо дать название виртуальной машине.

Если Вы хотите изменить что-то в конфигурации или сделать небольшую адаптацию, поставьте галочку на Customize configuration before install. Затем нажмите на finish и подождите несколько секунд, пока не появится контрольная консоль для вашей гостевой ОС.

Заключение

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

Интенсив по Виртуализации VMware vSphere 7

Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware

Источник

Работа с виртуальными машинами KVM. Введение

Как и обещал, начинаю серию статей о том, как мы делали услугу аренды выделенных серверов на базе KVM.

В этой вступительной статье я расскажу вкратце обо всех программных средствах, использованных в процессе разработки услуги. Более подробно о них будет рассказано в следующих статьях.

Debian

Почему Debian? Эта операционная система мне близка и понятна, так что при выборе дистрибутива мучений, терзаний и метаний испытано не было. Особых преимуществ перед Red Hat Enterprise Linux у него нет, но было принято решение работать со знакомой системой.

Если вы планируете самостоятельно развернуть инфраструктуру, используя аналогичные технологии, я бы посоветовал взять именно RHEL: благодаря хорошей документации и хорошо написаным прикладным программам это будет если не на порядок, то уж точно раза в два проще, а благодаря развитой системе сертификации без особого труда можно будет найти некоторое количество специалистов, на должном уровне знакомых в данной ОС.

Мы же, повторюсь, решили использовать Debian Squeeze с набором пакетов из Sid/Experimental и некоторыми пакетами, бэкпортированными и собранными с нашими патчами.
В планах имеется публикация репозитория с пакетами.

При выборе технологии виртуализации рассматривались два варианта — Xen и KVM.

Замечу, что лично я не очень хорошо знаю Xen, его архитектуру и уж тем более мелкие особенности — в основном я знакомился с ним в качестве гостя. Нет повода сказать, что Xen чем-то плох (потому, что он ещё не полностью вошёл в ядро, или у него что-то не так с производительностью, или еще по какой-то причине). Ничего определённого нельзя сказать и в плане производительности: в каких-то тестах KVM на 10-20 процентов опережает Xen по всем показателям, а где-то выигрывает Xen. Фактически, на текущий момент они практически сравнялись по функционалу, производительности, надёжности. И в принципе, не за горами тот день, когда Xen также войдёт в ядро. Уже вошёл в состав ядра virtually-a-machine.blogspot.com/2011/06/xen-support-in-mainline-linux-kernel.html.

Также во внимание принимался факт наличия огромного количества разработчиков, хостеров, комерческих решений именно на базе Xen — тем интереснее было провести в жизнь решение именно на базе KVM.

Основной же причиной, по которой мы решили использовать именно KVM, является необходимость запуска виртуальных машин с FreeBSD и, в перспективе, MS Windows.

libvirt

Для управления виртуальными машинами оказалось чрезвычайно удобно использовать libvirt и продукты, использующие ее API: virsh, virt-manager, virt-install, пр.

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

Разумеется, решение не идеально. Из минусов libvirt следует назвать:

cgroups

Основной проблемой в реализации услуги в самом начале представлялось лимитирование ресурсов для виртуальных машин. В Xen эта проблема была решена при помощи внутреннего шедулера, распределяющего ресурсы между виртуальными машинами — и что самое прекрасное, была реализована возможность лимитировать и дисковые операции в том числе.

В KVM ничего такого не было до появления механизма распределения ресурсов ядра cgroups. Как обычно в Linux, доступ к этим функциям был реализован посредством специальной файловой системы cgroup, в которой при помощи обычных системных вызовов write() можно было добавить процесс в группу, назначить ему его вес в попугаях, указать ядро, на котором он будет работать, указать пропускную способность диска, которую этот процесс может использовать, или, опять же, назначить ему вес.

Профит в том, что всё это реализуется внутри ядра, и использовать это можно не только для сервера, но и для десктопа (что и использовали в известном «The

200 Line Linux Kernel Patch That Does Wonders»). И на мой взгляд, это одно из самых значительных изменений в ветке 2.6, не считая любимого #12309, а не запиливание очередной файловой системы. Ну, разве что, кроме POHMELFS (но чисто из-за названия).

libguestfs

Отношение к этой библиотеке-утилите у меня весьма неоднозначное.

С одной стороны это выглядит примерно так:

И ещё эту штуку чертовски сложно собрать из исходников и тем более в пакет: иногда мне кажется, что Linux From Scratch собрать с нуля несколько проще.

С другой стороны — очень мощная штука, которая позволяет создавать образы для виртуальных машин, модифицировать их, ужимать, ставить grub, модифицировать таблицу разделов, управлять конфигурационными файлами, переносить «железные» машины в виртуальную среду, переносить виртуальные машины с одного образа на другой, переносить виртуальные машины из образа на железо и, честно говоря, тут меня фантазия немного подводит. Ах, да: ещё можно запустить демон внутри виртуальной машины Linux и получить доступ к данным виртуальной машины вживую, и всё это делать на shell, python, perl, java, ocaml. Это краткий и далеко не полный список того, что можно сделать с libguestfs.

Интересно, что большая часть кода в libguestfs генерируется в момент сборки, равно как и документация к проекту. Очень широко используется ocaml, perl. Сам код пишется на C, который потом оборачивается в OCaml, и повторяющиеся куски кода генерируются сами. Работа с образами осуществляется путём запуска специального сервисного образа (supermin appliance), в который через канал внутрь него отправляются команды. Внутри этого образа содержится некоторый rescue набор утилит, таких как parted, mkfs и прочих полезных в хозяйстве системного администратора.

Я с недавнего времени его даже дома стал использовать, когда выковыривал из образа nandroid нужные мне данные. Но для этого требуется ядро с поддержкой yaffs.

Прочее

Ниже приведено ещё несколько интересных ссылок на описание использованных пограммных средств — почитать и поизучать самостоятельно, если интересно. Например, про утилиту для массовой работы с конфигурационными файлами, KVM best practices от товарищей из IBM. Рекомендую!

В следующей части

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

Источник

Используем KVM для создания виртуальных машин на сервере

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

Сейчас передо мной встал вопрос аренды хорошего сервера с большим объёмом оперативной памяти и объёмным жестким диском. Но запускать проекты прямо на хост-машине не хочется, поэтому буду разграничивать их по отдельным небольшим виртуальным серверам с ОС Linux или docker-контейнерам (о них расскажу в другой статье).

Все современные облачные хостинги работают по такому же принципу, т.е. хостер на хорошем железе поднимает кучу виртуальных серверов, которые мы привыкли называть VPS/VDS, и раздаёт их пользователям, либо автоматизирует этот процесс (привет, DigitalOcean).

KVM (kernel-based virtual machine) это программное обеспечения для Linux, использующее аппаратные средства x86-совместимых процессоров для работы с технологией виртуализации Intel VT/AMD SVM.

Установка KVM

Все махинации по созданию виртуальной машины я буду проводить на ОС Ubuntu 16.04.1 LTS. Чтобы проверить поддерживает ли ваш процессов аппаратную виртуализацию на базе Intel VT/AMD SVM, выполняем:

Если терминал непустой, то значит всё в порядке и KVM можно устанавливать. Ubuntu официально поддерживает только гипервизор KVM (входит в состав ядра Linux) и советует использовать библиотеку libvirt в качестве инструмента по управлению им, что мы и будем делать дальше.

Проверить поддержку аппаратной виртуализации в Ubuntu также можно через команду:

В случае успеха, вы увидите что-то вроде этого:

Устанавливаем пакеты для работы с KVM:

Если у вас есть доступ к графической оболочке системы, то можно установить GUI менеджер libvirt:

Пользоваться virt-manager достаточно просто (не сложнее VirtualBox), поэтому в этой заметке речь пойдёт про консольный вариант установки и настройки виртуального сервера.

Установка и настройка виртуального сервера

В консольном варианте установки, настройки и управлением системой, незаменимым инструментом является утилита virsh (надстройка над библиотекой libvirt). У неё большое количество опций и параметров, подробное описание можно получить так:

или вызвать стандартный «help»:

Я всегда придерживаюсь следующих правил при работе с виртуальными серверами:

Приступим к установке первой виртуалки (64-битной серверной убунте 16.04 LTS):

Скачав образ запускаем установку:

Переводя все эти параметры на «человеческий язык», то получается, что мы создаём виртуальную машину с ОС Ubuntu 16.04, 1024 МБ ОЗУ, 1 процессором, стандартной сетевой картой (виртуальная машина будет ходить в интернет как-будто из-за NAT), 20 ГБ HDD.

Стоит обратить внимание на параметр —os-variant, он указывает гипервизору под какую именно ОС следует адаптировать настройки.
Список доступных вариантов ОС можно получить, выполнив команду:

Если такой утилиты нет в вашей системе, то устанавливаем:

После запуска установки, в консоли появится вот такая надпись:

Это нормальная ситуация, продолжать установку мы будем через VNC.
Смотрим на каком порту он был поднят у нашей виртуалки (в соседнем терминале, например):

Порт 5900, на локальном адресе 127.0.0.1. Чтобы подключиться к VNC, необходимо использовать Port Forwarding через ssh. Перед тем как это сделать, убедитесь, что tcp forwarding разрешён у демона ssh. Для этого идём в настройки sshd:

Если ничего не нашлось или вы видите:

То правим конфиг на

и перезагружаем sshd.

Настройка Port forwarding

Выполняем команду на локальной машине:

Здесь мы настроили ssh port forwarding с локального порта 5900 на серверный порт 5900. Теперь уже можно подключиться к VNC, используя любой VNC-клиент. Я предпочитаю UltraVNC из-за простоты и удобства.

После успешного подключения, на экране отобразится стандартное окно приветствия начала установки Ubuntu.

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

Запоминаем и идём на хост машину. Вытаскиваем mac-адрес «сетевой» карты виртуалки:

Запоминаем наш mac адрес:

Редактируем сетевые настройки гипервизора:

Ищем DHCP, и добавляем вот это:

Должно получиться что-то вроде этого:

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

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

Чтобы подключиться к терминалу виртуальной машины, выполняем:

Машина готова к бою.

Virsh: список команд

Перезагрузить хост можно:

Остановить виртуальную машину:

Добавить в автозапуск:

Очень часто требуется склонировать систему, чтобы в будущем использовать её как каркас для других виртуальных ОС, для этого используют утилиту virt-clone.

Она клонирует существующую виртуалку и изменяет host-sensitive данные, например, mac address. Пароли, файлы и прочая user-specific информация в клоне остаётся прежней. Если на клонируемой виртуалке IP адрес был прописан вручную, то могут возникнуть проблемы с доступом по SSH на клон из-за конфликта (2 хоста с одинаковым IP).

Помимо установки виртуалки через VNC, также возможен вариант с X11Forwarding через утилиту virt-manager. В Windows, например, для этого можно использовать Xming и PuTTY.

Ссылки

💌 Присоединяйтесь к рассылке

Понравился контент? Пожалуйста, подпишись на рассылку.

Источник

Работа с виртуальными машинами KVM. Подготовка хост-машины

Вступление

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

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

$ egrep ‘(vmx|svm)’ /proc/cpuinfo

Если есть — это замечательно.

Подготовка операционной системы

Установку Debian Squeeze я, пожалуй, описывать не буду: если уж вы добрались до KVM, то установка системы — плёвое дело.

Устанавливать нужно будет 64-битную OS, поскольку необходимые пакеты есть только для этой архитектуры.

В Debian Squeeze «свежесть» пакетов с KVM и сопутствующих программами нас совсем не устраивает, поскольку очень много всяких фиксов и фич попросту пройдут мимо нас. Поэтому мы добавим репозитории Debian Sid и experimental:

deb http://ftp.ru.debian.org/debian sid main contrib non-free
deb-src http://ftp.ru.debian.org/debian sid main contrib non-free

deb http://ftp.ru.debian.org/debian experimental main contrib non-free
deb-src http://ftp.ru.debian.org/debian experimental main contrib non-free

Указываем, что у нас базовый дистрибутив stable, а не то, что подумала система:

# echo ‘APT::Default-Release «stable»;’ > /etc/apt/apt.conf.d/default

Оттуда нам понадобятся пакеты:

Из стабильного репозитория нам будут нужны:

# aptitude install uml-utilities bridge-utils

На вашем рабочем десктопе вы можете поставить virt-manager (GUI-утилита), который позволит удобно создавать нужные конфигурации виртуальных машин.

Ядро чем «свежее» — тем лучше (в известных пределах конечно: из git, например, я бы ставить не рекомендовал). Хорошим вариантом будет 2.6.39, вышедшее недавно.

Следует отметить, что в стандартном ядре отсутствует модуль для поддержки записи в UFS2, и если планируется запускать гостевую FreeBSD, потребуется собрать ядро с этим модулем. Ну и, конечно, в Debian-овском ядре отсутствуют свежие версии cgroups.

Что должно быть включено в ядре для использования максимального объема требуемого функционала:

CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_CONSOLE=y
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NET_CLS_CGROUP=y

Затем идём по ссылке и устанавливаем все deb-пакеты оттуда, копируем insmod.static в /sbin/insmod.static (это нужно, поскольку в работе libguestfs использует статически скомпилированную версию insmod, а в Debian и Ubuntu такого файла просто нет, однако в последней версиии febootstrap эту проблему устранили, insmod.static более не нужно загружать на сервер). libguestfs позволяет нам получать доступ к диску VDS через API libguestfs(C, Perl, Python, PHP) или через утилиту guestfish.

Первый блин

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

Давайте попробуем что-нибудь поставить, например, тот же самый Debian. Пока без настройки сети, просто, по умолчанию.

Скачиваем установщик netinstall:

Редактируем /etc/libvirt/qemu.conf, чтобы виртуальные машины работали у нас от непривилегированного пользователя:

user = «username»
group = «libvirt»

Поскольку у нас будут использоваться tun-устройства, нужно выставить capability CAP_NET_ADMIN, сделать это можно как для отдельного исполняемого файла, так и для пользователя в целом, или настроить чтобы libvirt не сбрасывал нужные права для qemu/kvm.

Выставляем для отдельного файла:

sudo setcap cap_net_admin=ei /usr/bin/kvm

Или выставляем для пользователя в целом в файле /etc/security/capability.conf:

Или выставляем соответствующую настройку в /etc/libvirt/qemu.conf:

Добавим пользователя в группу libvirt и kvm:

# adduser username libvirt
# adduser username kvm

Запустим установку виртуальной машины:

Подробно разберём параметры, которые мы указали:

Утилиты настройки и управления

Для управления установкой и для клонирования виртуальных машин у нас есть две замечательные утилиты — графическая и консольная: virt-manager и virsh, соответственно. Конечно, консольная версия намного богаче по возможностям, но ничто не сравнится с видом графиков, от которых сердце сисадмина млеет.

Думаю с virt-manager вы и сами разберётесь, давайте попробуем покопаться в консольных внутренностях virsh. Вот несколько команд которые стоит выполнить и посмотреть что из этого получится:

Чтобы тысячу раз не писать —connect qemu:///system, добавьте:

export VIRSH_DEFAULT_CONNECT_URI= qemu:///system

Подготовка сети

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

В моей конфигурации используются TUN/TAP устройства, на которые с eth0 маршрутизируется трафик. Коротко опишу, почему выбран именно такой способ маршрутизации:

NAT нам не подходит, поскольку каждая VDS должна быть доступна из сети напрямую.
Схема с мостами не очень надёжная, поскольку теоретически есть возможность «захвата» IP адреса чужой виртуальной машины.
Итак:

Данный участок конфигурации нужно указывать непосредственно в конфигурационном файле гостя, расположенного по адресу /etc/libvirt/qemu/debian_guest.xml. Редактировать лучше всего через:

$ virsh edit debian_guest

Тогда конфигурация обновится на лету, при условии, что машина не запущена. В противном случае нужно будет подождать, пока она остановится, и запустить ее снова.

Создадим необходимое нам виртуальное устройство.

Для начала нам нужно дать нашему пользователю возможность беспарольного обращения к системным командам. Для этого добавим в sudoers:

Cmnd_Alias QEMU = /sbin/ifconfig, /sbin/modprobe, /usr/sbin/brctl, /usr/sbin/tunctl, /sbin/sysctl, /bin/ip, /usr/bin/cgcreate, /usr/bin/cgdelete, /sbin/tc
username ALL=(ALL:ALL) NOPASSWD: QEMU

Включим возможность форвардинга и проксирования arp-запросов:

sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv4.conf.all.proxy_arp=1

Также можно добавить эти параметры в /etc/sysctl.conf и применить их:

Создадим виртуальную сетевую карту и поднимем устройство:

Создадим маршрут на нужное нам устройство с нужного IP-адреса:

sudo ip route add 10.10.10.100 dev debian_guest

Теперь можно запустить VDS:

$ virsh start debian_guest

Подключившись к консоли, мы увидим, что сети нет, но у нас появилось устройство eth1, вместо eth0. Это произошло потому, что система при загрузке в /etc/udev/rules.d/70-persistent-net.rules прописывает mac-адрес сетевой карты, и если mac сменился, она создаёт ещё одну запись о сетевой карте, вроде этой:

SUBSYSTEM==»net», ACTION==»add», DRIVERS==»?*», ATTR