Qemu kvm не подключен
Обновлено: 01.07.2024
Библиотека libvirt используется для взаимодействия с различными технологиями виртуализации. Прежде чем приступить к работе с libvirt, лучше всего убедиться, что ваше оборудование поддерживает необходимые расширения виртуализации для KVM. Введите следующее в командной строке терминала:
Будет напечатано сообщение, информирующее вас о том, поддерживает или не ваш ЦП аппаратную виртуализацию.
Примечание
На многих компьютерах с процессорами, поддерживающими аппаратную виртуализацию, необходимо активировать параметр в BIOS, чтобы включить его.
Виртуальная сеть
Существует несколько способов разрешить виртуальной машине доступ к внешней сети. Конфигурация виртуальной сети по умолчанию включает правила моста и iptables, реализующие сетевое взаимодействие usermode, которое использует протокол SLIRP. Трафик передается через интерфейс хоста во внешнюю сеть через NAT.
Чтобы внешние хосты могли напрямую обращаться к службам на виртуальных машинах, необходимо настроить тип моста, отличный от используемого по умолчанию. Это позволяет виртуальным интерфейсам подключаться к внешней сети через физический интерфейс, благодаря чему они выглядят как обычные узлы для остальной части сети.
Есть отличный пример, как настроить собственный бридж и скомбинировать его с libvirt, чтобы гости могли использовать его на netplan.io.
Установка
Чтобы установить необходимые пакеты, введите в терминале:
После установки libvirt-daemon-system пользователя, используемого для управления виртуальными машинами, необходимо добавить в группу libvirt. Это делается автоматически для членов группы sudo, но это необходимо сделать дополнительно для всех, у кого должен быть доступ к общесистемным ресурсам libvirt. Это предоставит пользователю доступ к расширенным сетевым параметрам.
В терминале введите:
Примечание
Если выбранный пользователь является текущим пользователем, вам потребуется выйти и снова войти, чтобы новое членство в группе вступило в силу.
Теперь вы готовы установить гостевую операционную систему. Установка виртуальной машины выполняется так же, как и установка операционной системы непосредственно на оборудование.
Вам нужно:
- способ автоматизировать установку
- к физическому компьютеру необходимо подключить клавиатуру и монитор.
- использовать образы облаков, предназначенные для самоинициализации (см. Multipass и UVTool)
В случае виртуальных машин графический интерфейс пользователя (GUI) аналогичен использованию физической клавиатуры и мыши на реальном компьютере. Вместо установки графического интерфейса приложения virt-viewer или virt-manager можно использовать для подключения к консоли виртуальной машины с помощью VNC. Дополнительную информацию см. в разделе Диспетчер виртуальных машин/средство просмотра.
Управление виртуальными машинами
В следующем разделе рассматриваются инструменты командной строки для virsh, которые являются частью самой libvirt. Но есть различные варианты на разных уровнях сложности и наборов функций, например:
вирш
Существует несколько утилит для управления виртуальными машинами и libvirt. Утилиту virsh можно использовать из командной строки. Некоторые примеры:
Чтобы получить список запущенных виртуальных машин:
Чтобы запустить виртуальную машину:
Аналогично, чтобы запустить виртуальную машину при загрузке:
Перезагрузите виртуальную машину с помощью:
Состояние виртуальных машин можно сохранить в файл для последующего восстановления. Следующее сохранит состояние виртуальной машины в файл с именем в соответствии с датой:
После сохранения виртуальная машина больше не будет работать.
Сохраненную виртуальную машину можно восстановить с помощью:
Чтобы выключить виртуальную машину, выполните следующие действия:
Устройство CDROM можно подключить к виртуальной машине, введя:
Чтобы изменить определение гостевой вирши, откройте домен через
Это позволит редактировать XML-представление, определяющее гостевую систему, и при его сохранении будут применяться проверки формата и целостности этих определений.
Прямое редактирование XML, безусловно, является самым мощным, но и самым сложным способом. Такие инструменты, как Virtual Machine Manager/Viewer, могут помочь неопытным пользователям выполнять большинство стандартных задач.
Если virsh (или другие инструменты vir*) должен подключаться к чему-то другому, кроме гипервизора qemu-kvm/system по умолчанию, можно найти альтернативу параметру connect в man virsh или документ libvirt
область системы и сеанса
Вирш, как и большинство других инструментов для управления виртуализацией, может передавать строки подключения.
$ virsh --connect qemu:///system
Есть два варианта подключения.
- qemu:///system — локальное подключение от имени root к демону, контролирующему домены QEMU и KVM
- qemu:///session — локальное подключение от имени обычного пользователя к его собственному набору доменов QEMU и KVM
По умолчанию по умолчанию всегда был (и остается) qemu:///system, так как это поведение, к которому привыкли пользователи.
Но у qemu:///session есть несколько преимуществ (и недостатков), которые следует учитывать.
qemu:///session предназначена для каждого пользователя и может использоваться в многопользовательской системе для разделения людей.
Но самое главное, все работает с разрешениями пользователя, что означает отсутствие проблем с разрешениями на только что загруженный образ в вашем $HOME или только что подключенный USB-накопитель.
С другой стороны, он не может так хорошо получить доступ к системным ресурсам, включая настройку сети, которая, как известно, сложна с qemu:///session . Он возвращается к скользкой сети, которая функциональна, но медленна и делает невозможным доступ из других систем.
qemu:///system отличается тем, что он управляется глобальной общесистемной libvirt, которая может распределять ресурсы по мере необходимости.
Но вам может понадобиться mv и/или chown файлы в нужных местах, чтобы их можно было использовать.
Приложения обычно выбирают свой основной вариант использования. Приложения, ориентированные на рабочий стол, часто выбирают qemu:///session, в то время как большинство решений, требующих участия администратора, по-прежнему по умолчанию используют qemu:///system .
Подробнее об этом читайте в FAQ по libvirt и в этом блоге на эту тему.
Миграция
Существуют различные варианты этих методов, но отправной точкой для всех из них является virsh migrate. Подробнее читайте во встроенной справке.
Некоторую полезную документацию по ограничениям и соображениям по поводу динамической миграции можно найти на Ubuntu Wiki
Транспортное подключение устройства/горячее подключение
Если вместо описанного здесь горячего подключения вы хотите всегда проходить через устройство, добавьте xml-содержимое устройства в ваше статическое гостевое xml-представление, например. вирш редактировать . В этом случае вам не нужно использовать присоединить/отсоединить. Есть разные виды прохождения. Доступные типы зависят от настроек вашего оборудования и программного обеспечения.
Но оба вида обрабатываются очень похожим образом, и хотя есть разные способы сделать это (например, также через монитор qemu), рекомендуется вносить такие изменения через libvirt. Таким образом, libvirt может попытаться справиться со всеми видами особых случаев для вас, а также несколько скрыть различия версий.
Вообще, при горячем подключении через libvirt вы создаете фрагмент xml, описывающий устройство так же, как в статическом гостевом описании. USB-устройство обычно идентифицируется по идентификатору поставщика/продукта:
Виртуальные функции обычно назначаются через их PCI-ID (домен, шина, слот, функция).
Примечание
Чтобы получить виртуальную функцию, в первую очередь, очень зависит от устройства и поэтому не может быть полностью рассмотрено здесь. Но в целом это включает в себя настройку iommu, регистрацию через VFIO и иногда запрос нескольких VF. Вот пример на ppc64el, чтобы получить 4 VF на устройстве:
Затем вы подключаете или отключаете устройство через libvirt, связывая гостя с фрагментом XML.
Доступ к монитору Qemu через libvirt
Монитор Qemu — это способ взаимодействия с qemu/KVM во время работы гостя. Этот интерфейс имеет множество очень мощных функций для опытных пользователей. При работе под libvirt этот интерфейс монитора связан самой libvirt для целей управления, но пользователь по-прежнему может запускать команды монитора qemu через libvirt. Общий синтаксис: virsh qemu-monitor-command [опции] [гость] 'команда'
Libvirt охватывает большинство необходимых вариантов использования, но если вы хотите/должны обойти libvirt или хотите настроить очень специальные параметры, вы можете, например, добавить устройство таким образом:
Но поскольку монитор такой мощный, вы можете многое сделать, особенно для целей отладки, например, показать гостевые регистры:
Огромные страницы
Использование больших страниц может помочь уменьшить нагрузку на TLB, накладные расходы на таблицу страниц и ускорить некоторые дальнейшие действия, связанные с памятью. Кроме того, по умолчанию прозрачные огромные страницы полезны, но могут быть довольно накладными, поэтому, если ясно, что использование больших страниц предпочтительнее, то их явное использование обычно имеет некоторые преимущества.
Несмотря на то, что огромными страницами, по общему признанию, сложнее управлять, особенно на более поздних этапах жизненного цикла системы, если память фрагментирована, они обеспечивают полезный прирост, особенно для довольно больших гостевых систем.
Бонус: при использовании сквозного доступа к устройствам для очень больших гостевых систем есть дополнительное преимущество использования огромных страниц, так как быстрее выполнить первоначальную очистку памяти на контакте vfio dma.
Огромное количество страниц
Огромные страницы бывают разных размеров. Обычная страница обычно имеет размер 4 КБ, а огромные страницы имеют размер 2 М или 1 ГБ, но в зависимости от архитектуры возможны и другие варианты.
Самый простой, но наименее надежный способ выделить несколько огромных страниц – просто передать значение в sysfs.
Обязательно проверьте, сработало ли это.
Одним из этих размеров является «размер огромной страницы по умолчанию», который будет использоваться в автоматически монтируемом файле /dev/hugepages.
Изменение размера по умолчанию требует перезагрузки и устанавливается через default_hugepagesz
Вы можете проверить текущий размер по умолчанию:
Но может быть больше одной одновременной проверки:
И даже в более крупных системах это может быть дополнительно разделено по узлам Numa.
Можно выделить огромные страницы при загрузке или во время выполнения, но из-за фрагментации нет никаких гарантий, что это сработает позже. В документации ядра подробно описаны оба способа.
Огромные страницы должны быть выделены ядром, как упоминалось выше, но чтобы их можно было использовать, они также должны быть смонтированы.
По умолчанию systemd делает /dev/hugepages доступным для огромного размера страницы по умолчанию.
Не стесняйтесь добавлять дополнительные точки крепления, если вам нужен другой размер.
Обзор можно запросить с помощью
Информацию об общем статусе огромных страниц системы можно получить с помощью
Огромное использование страницы в libvirt
С учетом вышеизложенного libvirt может сопоставлять гостевую память с огромными страницами.
В определение гостя добавьте самую простую форму
Огромные страницы будут выделены с использованием размера огромной страницы по умолчанию из автоматически определенной точки подключения.
Для большего контроля, например. как память распределяется по узлам Numa или какой размер страницы использовать, ознакомьтесь с подробностями в документации libvirt.
Изоляция Apparmor
По умолчанию libvirt создает гостей qemu, используя изоляцию apparmor для повышения безопасности. Правила аппармора для гостя будут состоять из нескольких элементов:
- статическая часть, доступная всем гостям => /etc/apparmor.d/abstractions/libvirt-qemu
- динамическая часть, созданная во время гостевого запуска и измененная при горячем подключении/отключении => /etc/apparmor.d/libvirt/libvirt-f9533e35-6b63-45f5-96be-7cccc9696d5e.files
Из вышеперечисленного первое предоставляется и обновляется пакетом libvirt-daemon, а второе генерируется при гостевом запуске. Ни один из двух не должен редактироваться вручную. По умолчанию они охватывают подавляющее большинство вариантов использования и работают нормально. Но есть определенные случаи, когда пользователи хотят:
- дополнительно заблокировать гостя (например, явно запретив доступ, который обычно разрешен)
- открыть гостевую изоляцию (в большинстве случаев это необходимо, если установка на локальном компьютере не соответствует обычно используемым путям.
Для этого есть два файла. Оба являются локальными переопределениями, которые позволяют вам изменять их без их затирания или запросов командного файла при обновлении пакета.
- /etc/apparmor.d/local/abstractions/libvirt-qemu это будет применяться к каждому гостю. Поэтому это довольно мощный, но и довольно тупой инструмент. Это весьма полезное место для добавления дополнительных правил отказа.
- /etc/apparmor.d/local/usr.lib.libvirt.virt-aa-helper вышеупомянутая динамическая часть, которая является индивидуальной для каждого гостя, генерируется инструментом под названием libvirt.virt- аа-помощник. Это также находится в изоляции от Apparmor. Чаще всего это используется, если вы хотите использовать необычные пути, поскольку позволяет добавить эти необычные пути в гостевой XML (см. virsh edit ) и отобразить эти пути в динамических правилах для каждого гостя.
Обмен файлами между гостевым хостом
Чтобы иметь возможность обмениваться данными, память гостя должна быть выделена
как «общая», для этого вам необходимо добавить следующее в конфигурацию гостя:
По соображениям производительности (это помогает virtiofs, но также, как правило, разумно учитывать)
рекомендуется использовать огромные страницы, которые тогда будут выглядеть так:
В определении гостя можно добавить разделы файловой системы, чтобы указать пути
хостов для совместного использования с гостем. целевой каталог немного отличается, так как на самом деле это не каталог, а тег, который в гостевой системе можно использовать для доступа к этому конкретному экземпляру virtiofs.< /p>
И теперь это можно использовать в гостевой системе на основе тега myfs, например:
$ sudo mount -t virtiofs myfs /mnt/
По сравнению с другими вариантами обмена файлами между хостом и гостем — обычно samba, nfs
или 9p — virtiofs обычно намного быстрее, а также более совместим с обычной семантикой файловой системы. Для дополнительной совместимости в отношении
семантики файловой системы можно добавить:
Дополнительную информацию см. в документации по домену/файловой системе libvirt.
Примечание.
Хотя virtiofs работает с >=20.10 (Groovy), с >=21.04 (Hirsute) стало
намного удобнее, особенно в небольших средах (нет жестких требований
чтобы указать топологию гостевой нумы, нет жестких требований к использованию огромных страниц).
Если необходимо настроить 20.10 или просто интересуются этими подробностями,
база знаний libvirt о virtiofs содержит более подробную информацию об этом.
Ресурсы
Дополнительные сведения см. на главной странице KVM.
Дополнительную информацию о libvirt см. на домашней странице libvirt
- Конфигурация доменов и хранилища в формате xml является наиболее часто используемой ссылкой на libvirt
Другим хорошим ресурсом является страница Ubuntu Wiki KVM.
Основные сведения о том, как назначать устройства VT-d для qemu/KVM, см. на странице linux-kvm.
Внезапно возникла проблема с тем, что virt-manager не может подключиться к libvirtd. Соединение не прерывается, оно просто не завершается. вирш тоже виснет. Любая помощь приветствуется.
Конфигурации и выходные данные:
Похоже, libvirtd работает нормально (в настоящее время я не использую виртуальный бокс, поэтому меня не беспокоит это предупреждение).
модули kvm загружены
USER находится в группах kvm и libvirt
Отладочная информация при запуске virt-manager. Я предполагаю, что сервер и пользователь должны быть нулевыми, поскольку я не подключаюсь к удаленному гостю?
У меня есть сгенерированный файл /etc/libvirt/libvirtd.conf, но в настоящее время все закомментировано.
Кто-нибудь знает, что происходит? Это размещено в правильном разделе?
Очень не любит systemd, но не удовлетворен альтернативами, поэтому сосредоточился на укрощении systemd.
Вы использовали пошаговый установщик? Если да, я не могу вам помочь.
(A работает в момент времени B) && (время C > время B ) ≠ (A работает в момент времени C)
От имени пользователя root ни одна из команд не выводит результат. Оба висят. В качестве ПОЛЬЗОВАТЕЛЯ virsh -c qemu:///system зависает, а virsh -c qemu:///session запускает интерфейс командной строки virsh. «список» не показывает ни одну из моих старых виртуальных машин. Я просмотрю ссылку, которую вы разместили, и посмотрю, есть ли там что-нибудь еще.
Успешно ли работает libvirtd в этой системе? As groups содержит kvm, как назначено systemd с первым доступным gid ниже 1000, а не 78, как назначено qemu
Я далеко от своей системы, но проверю это, когда вернусь домой. Я сообщу о результатах, когда смогу.
Раньше это работало. Я не редактировал файлы .conf (сброс из удаления/переустановки? Кажется, я помнил, что устанавливал их раньше.), поэтому я соответствующим образом обновил строки группы и пользователя и изменил права собственности /var/lib/virtlib/qemu и содержимого на root: kvm, но без изменений. Пробовал также uid/gid в qemu.conf. Изменил gid kvm на 78, чтобы посмотреть, изменит ли это что-нибудь с
и обновление старых GID с помощью
без изменений. Я просмотрел /usr/lib/sysusers.d/basic.conf и увидел, что kvm указан в группе доступа к оборудованию, что бы это ни стоило.
Есть ли другие файлы .conf, в которых мне нужно обновить имя gid/группы? Отчет об ошибке, похоже, все еще открыт, поэтому стоит ли мне взглянуть на применение последнего исправления, упомянутого loqs?
В этом приложении описываются распространенные проблемы и ошибки, связанные с libvirt, а также инструкции по их устранению.
Найдите ошибку в таблице ниже и перейдите по соответствующей ссылке в разделе "Решение", чтобы получить подробные сведения об устранении неполадок.
Таблица А.1. Распространенные ошибки libvirt
Гость может общаться с другими гостями, но не может подключиться к хост-компьютеру после настройки на использование сетевого интерфейса macvtap (или type='direct').
А.19.1. libvirtd не удалось запустить
Примечание
Эта строка по умолчанию закомментирована, чтобы libvirt не создавал лишние сообщения журнала. После диагностики проблемы рекомендуется еще раз прокомментировать эту строку в файле /etc/libvirt/libvirtd.conf.
Справочная страница libvirtd показывает, что отсутствующий файл cacert.pem используется в качестве полномочий TLS, когда libvirt запускается в режиме прослушивания соединений TCP/IP. Это означает, что передается параметр --listen.
Примечание
Для получения дополнительной информации о сертификатах ЦС и настройке системной аутентификации см. главу "Управление сертификатами и центрами сертификации" в Руководстве по идентификации домена, аутентификации и политике Red Hat Enterprise Linux 7.
Не используйте TLS; вместо этого используйте голый TCP. В /etc/libvirt/libvirtd.conf установите listen_tls = 0 и listen_tcp = 1. Значения по умолчанию: listen_tls = 1 и listen_tcp = 0 .
Не передавайте параметр --listen. В /etc/sysconfig/libvirtd.conf измените переменную LIBVIRTD_ARGS.
А.19.2. URI не удалось подключиться к гипервизору
А.19.2.1. Не удается прочитать сертификат ЦС
Сообщение об ошибке вводит в заблуждение относительно фактической причины. Эта ошибка может быть вызвана целым рядом факторов, например неверно указанным URI или ненастроенным подключением.
При указании qemu://system или qemu://session в качестве URI подключения virsh пытается подключиться к системе или сеанс соответственно. Это связано с тем, что virsh распознает текст после второй косой черты как хост.
Используйте три косые черты для подключения к локальному хосту. Например, если указать qemu:///system, virsh подключится к экземпляру system libvirtd на локальном хосте.
URI правильный (например, qemu[+tls]://server/system ), но сертификаты неправильно настроены на вашем компьютере. Информацию о настройке TLS см. на веб-сайте основной ветки разработки libvirt.
А.19.2.2. не удалось подключиться к серверу по адресу 'host:16509': в соединении отказано
Демон libvirt не прослушивает порты TCP даже после изменения конфигурации в /etc/libvirt/libvirtd.conf:
А.19.2.3. Ошибка аутентификации
Если аутентификация завершается ошибкой даже при использовании правильных учетных данных, возможно, аутентификация SASL не настроена.
Отредактируйте файл /etc/libvirt/libvirtd.conf и задайте для параметра auth_tcp значение sasl . Чтобы проверить:
А.19.2.4. Разрешение отклонено
А.19.3. Ошибка загрузки PXE (или DHCP) в гостевой системе
Гостевая виртуальная машина запускается успешно, но затем либо не может получить IP-адрес от DHCP, либо загружается с использованием протокола PXE, либо и то, и другое. Существует две распространенные причины этой ошибки: установленное для моста длительное время задержки пересылки и когда пакет iptables и ядро не поддерживают правила изменения контрольной суммы.
Это наиболее распространенная причина этой ошибки. Если гостевой сетевой интерфейс подключается к мостовому устройству, на котором включен STP (протокол связующего дерева), а также установлена длительная задержка пересылки, мост не будет пересылать сетевые пакеты с гостевой виртуальной машины на мост, пока не будет достигнуто хотя бы это число. секунд задержки пересылки прошло с момента подключения гостя к мосту. Эта задержка позволяет мосту отслеживать трафик от интерфейса и определять MAC-адреса за ним, а также предотвращать зацикливание пересылки в топологии сети.
Если задержка пересылки больше времени ожидания PXE- или DHCP-клиента гостя, операция клиента завершится ошибкой, и гость либо не сможет загрузиться (в случае PXE), либо не сможет получить IP-адрес (в случае в случае DHCP).
В этом случае измените задержку пересылки на мосту на 0, отключите STP на мосту или и то, и другое.
Примечание
Это решение применимо только в том случае, если мост используется не для соединения нескольких сетей, а просто для соединения нескольких конечных точек с одной сетью (наиболее распространенный вариант использования мостов, используемых libvirt).
Если у гостя есть интерфейсы, подключающиеся к виртуальной сети, управляемой libvirt, отредактируйте определение сети и перезапустите ее. Например, отредактируйте сеть по умолчанию с помощью следующей команды:
Примечание
delay='0' и stp='on' являются настройками по умолчанию для виртуальных сетей, поэтому этот шаг необходим только в том случае, если конфигурация по умолчанию была изменена.
Если гостевой интерфейс подключен к хост-мосту, настроенному вне libvirt, измените настройку задержки.
Добавьте или отредактируйте следующие строки в файле /etc/sysconfig/network-scripts/ifcfg-name_of_bridge, чтобы включить STP с задержкой в 0 секунд:
Примечание
Если name_of_bridge не является корневым мостом в сети, задержка этого моста в конечном итоге будет сброшена до времени задержки, настроенного для корневого моста. Чтобы этого не произошло, отключите STP на name_of_bridge.
Гость пытается получить IP-адрес от DHCP-сервера, работающего непосредственно на узле.
iptables 1.4.10 была первой версией, в которую было добавлено расширение libxt_CHECKSUM. Это происходит, если в журналах libvirtd появляется следующее сообщение:
Важно
Если все остальные три условия в этом списке также не выполняются, приведенное выше предупреждающее сообщение можно игнорировать, и оно не является признаком каких-либо других проблем.
При возникновении этих условий UDP-пакеты, отправляемые с хоста гостю, имеют невычисленные контрольные суммы. Из-за этого UDP-пакеты хоста кажутся недействительными для гостевого сетевого стека.
Чтобы решить эту проблему, отмените любой из четырех пунктов выше. Лучшее решение — обновить iptables хоста и ядро до iptables-1.4.10 или новее, если это возможно. В противном случае наиболее конкретным решением является отключение драйвера vhost-net для этого конкретного гостя. Для этого отредактируйте гостевую конфигурацию с помощью этой команды:
Если проблема все еще не решена, проблема может быть связана с конфликтом между firewalld и сетью libvirt по умолчанию.
Чтобы это исправить, остановите firewalld с помощью команды service firewalld stop, а затем перезапустите libvirt с помощью команды service libvirtd restart.
Примечание
Кроме того, если файл /etc/sysconfig/network-scripts/ifcfg-имя_сети настроен правильно, вы можете убедиться, что гость получит IP-адрес, используя команду dhclient от имени пользователя root на гость.
А.19.4. Гость может получить доступ к внешней сети, но не может получить доступ к хосту при использовании интерфейса macvtap
Гостевая виртуальная машина может взаимодействовать с другими гостями, но не может подключаться к хост-машине после настройки на использование сетевого интерфейса macvtap (также известного как type='direct').
Даже если вы не подключаетесь к агрегатору портов виртуального Ethernet (VEPA) или коммутатору с поддержкой VN-Link, интерфейсы macvtap могут быть полезны. Установка режима моста для такого интерфейса позволяет гостевой системе напрямую подключаться к физической сети очень простым способом без проблем с настройкой (или несовместимости с NetworkManager), которые могут сопровождать использование традиционного хост-устройства моста.
Однако, когда гостевая виртуальная машина настроена на использование сетевого интерфейса type='direct', такого как macvtap, несмотря на то, что у нее есть возможность общаться с другими гостями и другими внешними хостами в сети, гость не может общаться со своими хост.
Эта ситуация на самом деле не является ошибкой — это определенное поведение macvtap. Из-за того, что физический Ethernet хоста подключен к мосту macvtap, трафик на этот мост от гостей, который перенаправляется на физический интерфейс, не может быть возвращен обратно в стек IP хоста. Кроме того, трафик из стека IP хоста, который отправляется на физический интерфейс, не может быть возвращен обратно на мост macvtap для пересылки гостям.
Используйте libvirt для создания изолированной сети и создайте второй интерфейс для каждой гостевой виртуальной машины, подключенной к этой сети. Затем хост и гости могут напрямую общаться через эту изолированную сеть, сохраняя при этом совместимость с NetworkManager .
Процедура А.8. Создание изолированной сети с помощью libvirt
Добавьте и сохраните следующий XML-код в файле /tmp/isolated.xml. Если сеть 192.168.254.0/24 уже используется в вашей сети, вы можете выбрать другую сеть.
Рисунок А.3. Изолированный сетевой XML
Используя virsh edit name_of_guest, отредактируйте конфигурацию каждого гостя, использующего macvtap для своего сетевого подключения, и добавьте новое в раздел, аналогичный следующему (обратите внимание, что эта строка не является обязательной):< /p>
Рисунок А.4. XML устройства интерфейса
Теперь гости могут связаться с хостом по адресу 192.168.254.1, а хост сможет связаться с гостями по IP-адресу, который они получили от DHCP (или вы можете вручную настроить IP-адреса для гостей). ). Поскольку эта новая сеть изолирована только для хоста и гостей, все остальные сообщения от гостей будут использовать интерфейс macvtap. Для получения дополнительной информации см. Раздел 23.17.8, «Сетевые интерфейсы».
А.19.5. Не удалось добавить правило для исправления контрольных сумм ответов DHCP в сети 'default'
Если проблема, с которой вы столкнулись, заключается в том, что гостевые виртуальные машины не могут получить IP-адреса через DHCP, это сообщение можно игнорировать.
Если это так, см. раздел A.19.3, «Сбой загрузки PXE (или DHCP) на гостевой системе» для получения дополнительной информации об этой ситуации.
А.19.6. Не удалось добавить мост br0 порт vnet0: нет такого устройства
Оба сообщения об ошибках показывают, что устройство-мост, указанное в определении гостя (или домена), не существует.
Чтобы убедиться, что мостовое устройство, указанное в сообщении об ошибке, не существует, используйте команду оболочки ip addr show br0 .
Используйте virsh либо для редактирования настроек существующего моста или сети, либо для добавления устройства моста в конфигурацию хост-системы.
Используйте virsh edit name_of_guest, чтобы изменить определение для использования уже существующего моста или сети.
Для libvirt версии 0.9.8 и выше устройство-мост можно создать с помощью команды virsh iface-bridge. Это создает мостовое устройство br0 с подключенным eth0 , физическим сетевым интерфейсом, который установлен как часть моста:
Необязательно: при необходимости удалите этот мост и восстановите исходную конфигурацию eth0 с помощью этой команды:
Для более старых версий libvirt можно вручную создать мостовое устройство на хосте. Инструкции см. в разделе 6.4.3, «Сетевые мосты с помощью libvirt».
А.19.7. Миграция завершается с ошибкой: невозможно определить адрес
Во время переноса libvirtd, запущенный на целевом хосте, создает URI из адреса и порта, через которые он ожидает получить данные миграции, и отправляет их обратно в libvirtd, работающий на исходном хосте.
В этом случае хосту назначения ( 192.168.122.12 ) присвоено имя 'newyork'. По какой-то причине libvirtd, запущенный на этом хосте, не может преобразовать имя в IP-адрес, который можно было бы отправить обратно и при этом по-прежнему использовать. По этой причине он вернул имя хоста 'newyork', надеясь, что исходный libvirtd справится с разрешением имени более успешно. Это может произойти, если DNS настроен неправильно или в файле /etc/hosts имя хоста связано с локальным петлевым адресом ( 127.0.0.1 ).
Обратите внимание, что адрес, используемый для переноса данных, не может быть автоматически определен из адреса, используемого для подключения к целевому libvirtd (например, из qemu+tcp://192.168.122.12/system ).Это связано с тем, что для связи с целевым libvirtd исходному libvirtd может потребоваться использовать сетевую инфраструктуру, отличную от типа, который требуется virsh (возможно, работающему на отдельной машине).
Лучшее решение — правильно настроить DNS, чтобы все хосты, участвующие в миграции, могли разрешать все имена хостов.
Если DNS нельзя настроить для этого, список всех хостов, используемых для миграции, можно добавить вручную в файл /etc/hosts на каждом из хостов. Однако трудно поддерживать согласованность таких списков в динамической среде.
Если имена хостов нельзя сделать разрешимыми каким-либо образом, virsh migrate поддерживает указание хоста миграции:
Назначение libvirtd примет URI tcp://192.168.122.12 и добавит автоматически сгенерированный номер порта. Если это нежелательно (например, из-за настроек брандмауэра), номер порта можно указать в этой команде:
Еще один вариант — использовать туннельную миграцию. Туннелированная миграция не создает отдельного соединения для данных миграции, а вместо этого туннелирует данные через соединение, используемое для связи с целевым libvirtd (например, qemu+tcp://192.168.122.12/system ):
А.19.8. Сбой переноса из-за невозможности разрешить доступ к пути к диску: нет такого файла или каталога
Гостевая виртуальная машина (или домен) не может быть перенесена, так как libvirt не может получить доступ к образу(ам) диска:
По умолчанию миграция передает только состояние памяти запущенного гостевого компьютера (например, состояние памяти или процессора). Хотя образы дисков не переносятся во время переноса, они должны оставаться доступными по одному и тому же пути для обоих хостов.
Настройте и подключите общее хранилище в одном месте на обоих хостах. Самый простой способ сделать это — использовать NFS:
Процедура A.9. Настройка общего хранилища
Настройте сервер NFS на узле, который будет использоваться в качестве общего хранилища. Сервер NFS может быть одним из хостов, участвующих в переносе, при условии, что все задействованные хосты обращаются к общему хранилищу через NFS.
Смонтируйте экспортированный каталог в общем месте на всех хостах, на которых работает libvirt. Например, если IP-адрес сервера NFS — 192.168.122.1, смонтируйте каталог с помощью следующих команд:
Примечание
Невозможно экспортировать локальный каталог с одного хоста с помощью NFS и смонтировать его по тому же пути на другом хосте — каталог, используемый для хранения образов дисков, должен быть смонтирован из общего хранилища на обоих хостах. Если это не настроено правильно, гостевая виртуальная машина может потерять доступ к своим образам дисков во время миграции, потому что демон libvirt исходного хоста может изменить владельца, разрешения и метки SELinux на образах дисков после того, как он успешно мигрирует гостя к месту назначения. .
Если libvirt обнаружит, что образы дисков смонтированы из общего хранилища, эти изменения не будут внесены.
А.19.9. При запуске libvirtd отсутствуют гостевые виртуальные машины
Существуют различные возможные причины этой проблемы. Выполнение этих тестов поможет определить причину этой ситуации:
Если вы используете машину AMD, убедитесь, что модули ядра kvm_amd вместо этого вставлены в ядро, используя аналогичную команду lsmod | grep kvm_amd в корневой оболочке.
Примечание
Хотя это редкость, поддержка виртуализации KVM может быть скомпилирована в ядро. В этом случае модули не нужны.
Включите расширения виртуализации в конфигурации прошивки вашего оборудования в настройках BIOS. Дополнительную информацию см. в документации по оборудованию.
Например, это сообщение показывает, что URI подключен к гипервизору VirtualBox, а не QEMU, и выявляет ошибку конфигурации для URI, который в противном случае настроен для подключения к гипервизору QEMU. Если бы URI правильно подключался к QEMU , вместо этого появилось бы то же сообщение, что и:
Эта ситуация возникает, когда присутствуют другие гипервизоры, с которыми libvirt может общаться по умолчанию.
А.19.10. Распространенные ошибки XML
Инструмент libvirt использует XML-документы для хранения структурированных данных. Множество распространенных ошибок возникает с документами XML, когда они передаются в libvirt через API. Несколько распространенных ошибок XML, включая ошибочные теги XML, недопустимые значения и отсутствующие элементы, подробно описаны ниже.
А.19.10.1. Редактирование определения домена
Хотя это не рекомендуется, иногда необходимо отредактировать XML-файл гостевой виртуальной машины (или домена) вручную. Чтобы получить доступ к гостевому XML для редактирования, используйте следующую команду:
Эта команда открывает файл в текстовом редакторе с текущим определением гостевой виртуальной машины. После завершения редактирования и сохранения изменений XML перезагружается и анализируется libvirt. Если XML правильный, отображается следующее сообщение:
Важно
При использовании команды редактирования в virsh для редактирования XML-документа сохраните все изменения перед выходом из редактора.
После сохранения XML-файла используйте команду xmllint, чтобы проверить правильность формата XML, или команду virt-xml-validate, чтобы проверить наличие проблем с использованием:
Если ошибки не возвращаются, XML-описание правильно сформировано и соответствует схеме libvirt. Хотя схема не учитывает все ограничения, исправление обнаруженных ошибок улучшит устранение неполадок.
Эти документы содержат определения состояний и конфигураций для гостей. Эти документы создаются автоматически и не должны редактироваться вручную. Ошибки в этих документах содержат имя файла поврежденного документа. Имя файла допустимо только на хост-компьютере, указанном в URI, который может видеть компьютер, на котором была запущена команда.
Ошибки в файлах, созданных libvirt, случаются редко. Тем не менее, одним из возможных источников этих ошибок является более ранняя версия libvirt — в то время как более новые версии libvirt всегда могут читать XML, сгенерированный более ранними версиями, более старые версии libvirt могут быть сбиты с толку элементами XML, добавленными в более новой версии.
А.19.10.2. Ошибки синтаксиса XML
Синтаксические ошибки обнаруживаются синтаксическим анализатором XML. Сообщение об ошибке содержит информацию для определения проблемы.
Этот пример сообщения об ошибке от синтаксического анализатора XML состоит из трех строк: первая строка обозначает сообщение об ошибке, а две следующие строки содержат контекст и расположение XML-кода, содержащего ошибку. Третья строка содержит индикатор, показывающий примерное местонахождение ошибки на строке выше:
Это имя файла документа, содержащего ошибку. Имена файлов в круглых скобках являются символическими именами для описания документов XML, проанализированных из памяти, и не соответствуют напрямую файлам на диске. Имена файлов, не заключенные в круглые скобки, являются локальными файлами, находящимися в целевом объекте соединения.
Гипервизор типа 2 позволяет пользователям запускать изолированные экземпляры других операционных систем внутри хост-системы. Будучи ОС на основе Linux, Ubuntu поддерживает широкий спектр решений виртуализации.
Помимо популярных сторонних приложений, таких как VirtualBox и VMWare, ядро Linux имеет собственный модуль виртуализации под названием KVM (виртуальная машина на основе ядра).
В этом руководстве вы узнаете, как установить и настроить KVM в Ubuntu 20.04.
- Система под управлением Ubuntu 20.04
- Учетная запись с правами sudo
- Доступ к командной строке/терминалу
Проверьте поддержку виртуализации в Ubuntu 20.04
<р>1. Прежде чем приступить к установке KVM, проверьте, поддерживает ли ваш ЦП аппаратную виртуализацию:Проверьте число в выводе:
Если команда возвращает значение 0 , ваш процессор не поддерживает KVM. С другой стороны, любой другой номер означает, что вы можете продолжить установку.
<р>2. Теперь проверьте, может ли ваша система использовать ускорение KVM, набрав:Вывод должен выглядеть следующим образом:
Если kvm-ok возвращает ошибку о том, что ускорение KVM невозможно использовать, попробуйте решить проблему, установив cpu-checker.
<р>3. Чтобы установить cpu-checker, выполните следующую команду: <р>4. Когда установка завершится, перезапустите терминал.Теперь вы готовы начать установку KVM.
Примечание. Когда аппаратная виртуализация выполняется для серверов, она называется виртуализацией серверов.
Установка KVM в Ubuntu 20.04
Чтобы включить виртуализацию KVM в Ubuntu 20.04:
- Установите связанные пакеты с помощью apt
- Разрешить пользователям запускать виртуальные машины
- Убедитесь, что установка прошла успешно.
Шаг 1. Установите пакеты KVM
<р>1. Сначала обновите репозитории: <р>2. Затем установите необходимые пакеты KVM с помощью следующей команды:Это запустит установку четырех пакетов KVM:
Шаг 2. Авторизуйте пользователей
<р>1. Только члены групп пользователей libvirt и kvm могут запускать виртуальные машины. Добавьте пользователя в группу libvirt, набрав:Замените имя пользователя на фактическое имя пользователя.
Примечание. Если вам нужно удалить пользователя из группы libvirt или kvm, просто замените adduser на deluser в приведенной выше команде.
Шаг 3. Проверка установки
<р>1. Подтвердите, что установка прошла успешно, с помощью команды virsh:Вы можете ожидать результат, как показано ниже:
Если все работает правильно, выходные данные возвращают активное (работающее) состояние.
Создание виртуальной машины в Ubuntu 20.04
<р>1. Прежде чем выбрать один из двух перечисленных ниже методов, установите virt-manager, инструмент для создания и управления виртуальными машинами:
Убедитесь, что вы загрузили ISO-образ, содержащий ОС, которую вы хотите установить на ВМ, и перейдите к выбору метода установки.
Метод 1: графический интерфейс Virt Manager
<р>1. Запустите virt-manager с помощью: <р>2. В первом окне щелкните значок компьютера в левом верхнем углу.
Способ 2. Использование командной строки
Используйте команду virt-install для создания виртуальной машины через терминал Linux. Синтаксис:
В следующем примере virt-install используется для установки Fedora 33 Workstation.
Совет. Чтобы команды с большим количеством параметров выглядели более аккуратно, вводите обратную косую черту после каждого параметра. Таким образом, при нажатии Enter команда не будет выполняться, а курсор перейдет на следующую строку.
Параметры этой команды служат для определения параметров установки.
Вот что означает каждый из них:
| Опция | Описание |
|---|---|
| --name | Имя вы даете ВМ |
| --description | Краткое описание ВМ |
| - -ram | Объем оперативной памяти, которую вы хотите выделить виртуальной машине |
| --vcpus | Количество виртуальных процессоров, которые вы хотите выделить ВМ |
| --disk | Расположение ВМ на вашем диске (если вы укажете несуществующий файл qcow2 на диске , он будет создан автоматически) |
| --cdrom | Расположение загруженного вами ISO-файла |
| --graphics | Указывает тип отображения |
Прочитав эту статью, вы должны знать, как установить KVM в Ubuntu 20.04. Кроме того, в статье описываются два метода настройки виртуальных машин с использованием графического интерфейса virt-manager и команды virt-install.
Читайте также: