KVM недоступен Возможно, KVM не установлен

Обновлено: 21.11.2024

На самом деле это руководство по установке, и его, вероятно, следует переместить.

KVM настроен как гипервизор по умолчанию для вычислений.

Чтобы явно включить KVM, добавьте следующие параметры конфигурации в файл /etc/nova/nova.conf:

Гипервизор KVM поддерживает следующие форматы образов виртуальных машин:

  • Необработанный
  • QEMU Копирование при записи (QCOW2)
  • Расширенный диск QED Qemu
  • Формат диска виртуальной машины VMware (vmdk)

В этом разделе описывается, как включить KVM в вашей системе. Дополнительные сведения см. в следующей документации по конкретному дистрибутиву:

    из документации Fedora 22. из документации сообщества Ubuntu. из справочника Debian.
  • Red Hat Enterprise Linux: установка пакетов виртуализации в существующей системе Red Hat Enterprise Linux из Руководства по настройке хоста виртуализации Red Hat Enterprise Linux и гостевой установки . из руководства openSUSE Virtualization with KVM. из Руководства по виртуализации SUSE Linux Enterprise Server.

Включить KVM¶

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

Для систем на базе x86¶

Чтобы определить, присутствуют ли расширения ЦП svm или vmx, выполните следующую команду:

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

Если ничего не выводится, обратитесь к документации по вашей системе, чтобы убедиться, что ваш ЦП и системная плата поддерживают аппаратную виртуализацию. Убедитесь, что в BIOS системы включены все соответствующие параметры аппаратной виртуализации.

BIOS у каждого производителя разный. Если вам необходимо включить виртуализацию в BIOS, найдите параметр, содержащий слова виртуализация , VT , VMX или SVM .

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

Если выходные данные включают kvm_intel или kvm_amd , модули аппаратной виртуализации kvm загружены и ваше ядро ​​соответствует требованиям к модулям для OpenStack Compute.

Если выходные данные не показывают, что модуль kvm загружен, выполните эту команду, чтобы загрузить его:

Выполните команду для вашего процессора. Для Intel выполните эту команду:

Для AMD выполните следующую команду:

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

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

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

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

Если ускорение KVM не поддерживается, настройте вычислительные ресурсы на использование другого гипервизора, например QEMU или Xen . Дополнительные сведения см. в QEMU или XenServer (и других вариантах Xen на основе XAPI).

Эти процедуры помогут загрузить модули ядра для процессоров Intel и AMD, если они не загружаются автоматически во время установки KVM.

Если ваш вычислительный хост основан на процессорах Intel, выполните следующие команды от имени пользователя root, чтобы загрузить модули ядра:

Добавьте эти строки в файл /etc/modules, чтобы эти модули загружались при перезагрузке:

Если ваш вычислительный хост основан на процессорах AMD, выполните следующие команды от имени пользователя root, чтобы загрузить модули ядра:

Добавьте эти строки в файл /etc/modules, чтобы эти модули загружались при перезагрузке:

Для систем на базе POWER¶

KVM в качестве гипервизора поддерживается на платформе PowerNV системы POWER.

Чтобы определить, поддерживает ли ваша платформа POWER виртуализацию на основе KVM, выполните следующую команду:

Если предыдущая команда выводит следующий вывод, ЦП поддерживает виртуализацию на основе KVM.

Если вывод не отображается, ваша платформа POWER не поддерживает аппаратную виртуализацию на основе KVM.

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

Если выходные данные включают kvm_hv , модули аппаратной виртуализации kvm загружены и ваше ядро ​​соответствует требованиям к модулям для OpenStack Compute.

Если выходные данные не показывают, что модуль kvm загружен, выполните следующую команду, чтобы загрузить его:

Для платформы PowerNV выполните следующую команду:

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

Настройка резервного хранилища вычислительных ресурсов¶

Резервное хранилище — это хранилище, используемое для предоставления расширенного образа операционной системы и любого временного хранилища. Внутри виртуальной машины это обычно представляется как два виртуальных жестких диска (например, /dev/vda и /dev/vdb соответственно). Однако внутри OpenStack это можно получить одним из следующих методов: lvm , qcow , rbd или flat , выбранным с помощью параметра images_type в nova.conf на вычислительном узле.

Вариант raw приемлем, но устарел в пользу flat . Плоская серверная часть использует либо необработанное хранилище, либо хранилище QCOW2. Он никогда не использует резервное хранилище, поэтому при использовании QCOW2 он копирует изображение, а не создает наложение. По умолчанию он создает необработанные файлы, но будет использовать QCOW2 при создании диска из QCOW2, если в конфигурации не задано значение force_raw_images.

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

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

Также можно использовать локальные тома LVM. Установите images_volume_group = nova_local, где nova_local — это имя созданной вами группы LVM.

Укажите модель процессора гостей KVM¶

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

  • Чтобы максимизировать производительность виртуальных машин, предоставив гостевой системе доступ к новым функциям центрального процессора.
  • Чтобы обеспечить одинаковый ЦП по умолчанию на всех компьютерах, уберите зависимость от переменных значений по умолчанию QEMU

В libvirt ЦП указывается путем предоставления имени базовой модели ЦП (которое является сокращением для набора флагов функций), набора дополнительных флагов функций и топологии (сокеты/ядра/потоки). Драйвер libvirt KVM предоставляет ряд стандартных названий моделей ЦП. Эти модели определены в файле /usr/share/libvirt/cpu_map.xml. Проверьте этот файл, чтобы определить, какие модели поддерживаются вашей локальной установкой.

Два параметра конфигурации Compute в группе [libvirt] файла nova.conf определяют, какой тип модели ЦП предоставляется гипервизору при использовании KVM: cpu_mode и cpu_model .

Параметр cpu_mode может принимать одно из следующих значений: none , host-passthrough , host-model и custom .

Хост-модель (по умолчанию для KVM и QEMU)¶

Если ваш файл nova.conf содержит cpu_mode=host-model , libvirt идентифицирует модель ЦП в файле /usr/share/libvirt/cpu_map.xml, которая наиболее точно соответствует хосту, и запрашивает дополнительные флаги ЦП для завершения сопоставления. Эта конфигурация обеспечивает максимальную функциональность и производительность и поддерживает хорошую надежность.

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

Проход через хост¶

Если ваш файл nova.conf содержит cpu_mode=host-passthrough , libvirt сообщает KVM о необходимости прохождения через центральный процессор без каких-либо изменений. В отличие от модели хоста, вместо того, чтобы просто сопоставлять флаги функций, сопоставляется каждая последняя деталь процессора хоста. Это дает наилучшую производительность и может быть важно для некоторых приложений, которые проверяют низкоуровневую информацию о ЦП, но это связано с затратами в связи с миграцией.

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

  • ваши вычислительные узлы имеют очень высокую степень однородности (т. е. практически все ваши вычислительные узлы используют одно и то же поколение и модель ЦП), и вы обязательно выполняете динамическую миграцию только между хостами с точно совпадающими версиями ядра, или< /li>
  • по какой-то причине и вопреки общепринятым рекомендациям вы решили, что ваша вычислительная инфраструктура вообще не должна поддерживать динамическую миграцию.

Пользовательский¶

Если ваш файл nova.conf содержит cpu_mode=custom , вы можете явно указать одну из поддерживаемых именованных моделей, используя параметр конфигурации cpu_model. Например, чтобы настроить гостей KVM для доступа к процессорам Nehalem, ваш файл nova.conf должен содержать:

Выбирая настраиваемый режим вместе с cpu_model, который соответствует самому старому из ЦП вашего вычислительного узла, вы можете гарантировать, что динамическая миграция между вычислительными узлами всегда будет возможна. Однако вы должны убедиться, что выбранная вами модель cpu_model передает гостю правильные флаги функций ЦП.

Нет (по умолчанию для всех гипервизоров на основе libvirt, кроме KVM и QEMU)¶

Если ваш файл nova.conf содержит cpu_mode=none , libvirt не указывает модель процессора. Вместо этого гипервизор выбирает модель по умолчанию.

Установить флаги функций ЦП¶

Независимо от того, какой режим cpu_mode выбран: host-passthrough , host-model или custom , также можно выборочно включить дополнительные флаги функций. Предположим, что выбранная вами пользовательская модель ЦП — IvyBridge, которая обычно не включает флаг функции pcid, но вы хотите передать pcid в свои гостевые экземпляры. В этом случае вы должны установить:

Поддержка вложенных гостей¶

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

Поддержка вложенных гостевых систем в модуле ядра KVM¶

Чтобы включить вложенные гостевые системы KVM, ваш вычислительный узел должен загрузить модуль kvm_intel или kvm_amd с параметром nested=1 . Вы можете включить вложенный параметр на постоянной основе, создав файл с именем /etc/modprobe.d/kvm.conf и заполнив его следующим содержимым:

Чтобы изменения вступили в силу, может потребоваться перезагрузка.

Вложенная гостевая поддержка в nova.conf ¶

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

Проход через хост

В этом режиме вложенная виртуализация автоматически включается после загрузки модуля ядра KVM с поддержкой вложенности.

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

В этом режиме вложенная виртуализация автоматически включается после загрузки модуля ядра KVM с поддержкой вложенности, если соответствующая модель ЦП по умолчанию предоставляет гостям флаг функции vmx (вы можете проверить это с помощью возможностей virsh на вашем вычислительном узле). .

Опять же, рассмотрим другие последствия, которые относятся к режиму модели хоста (по умолчанию для KVM и Qemu).

Ограничения поддержки вложенных гостевых систем¶

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

.
  • не удалось завершить динамическую миграцию;
  • не удается возобновить работу из приостановки.

Дополнительную информацию об этих ограничениях см. в документации KVM.

Поддержка гостевого агента¶

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

Чтобы включить эту функцию, необходимо установить hw_qemu_guest_agent=yes в качестве параметра метаданных образа, который вы хотите использовать для создания экземпляров с поддержкой гостевого агента. Вы можете явно отключить эту функцию, установив hw_qemu_guest_agent=no в метаданных изображения.

Улучшения производительности KVM¶

Модуль ядра VHostNet повышает производительность сети. Чтобы загрузить модуль ядра, выполните следующую команду от имени пользователя root:

Устранение неполадок с KVM¶

Попытка запустить новый экземпляр виртуальной машины завершается ошибкой с состоянием ERROR, и в файле /var/log/nova/nova-compute.log появляется следующая ошибка:

Это сообщение указывает на то, что модули ядра KVM не загружены.

Если вы не можете запустить виртуальные машины после установки без перезагрузки, возможно, разрешения установлены неправильно. Это может произойти, если вы загрузите модуль KVM до установки nova-compute. Чтобы проверить, настроена ли группа на kvm , запустите:

[РЕШЕНО] Buster: virt-manager - KVM недоступен.

[РЕШЕНО] Buster: virt-manager - KVM недоступен.

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

В BIOS включена виртуализация (ЦП поддерживает VT-x, VT-d и EPT) и установлены qemu-kvm, libvirt-daemon, libvirt-clients и virt-manager, но когда я пытаюсь создать новую виртуальную машину в virt -manger Я получаю сообщение:

похоже, модули загружены нормально.

После создания виртуальной машины гипервизор отображается в конфигурации виртуальной машины как QEMU TCG вместо KVM.

Если я запускаю kvm из окна терминала, он запускается и пытается выполнить загрузку PXE.

Я создал live CD Ubuntu 19, все установил, и все сразу заработало.

У кого-нибудь корректно работает kvm и virt-manager под Бастером?

4D696B65 Администратор сайта
Сообщений: 2791 Присоединился: 28.06.2009 06:09 Поблагодарили: 32 раза

Спасибо за ссылку, но она не решает мою проблему.

Он работает на моем сервере Stretch, и мне потребовалось 20 минут, чтобы настроить и запустить виртуальную машину на том же оборудовании с помощью Ubuntu Desktop 19 Live USB.

Я не использую virt-manager, но QEMU/KVM отлично работает в моей системе Buster, я использую его постоянно.

Пакет qemu-kvm — это просто скрипт-оболочка.

Установили ли вы пакет микрокода для своего процессора? Я не знаю, будет ли это иметь значение, но это единственное, о чем я могу думать.

Черные жизни имеют значение

С точки зрения хоста все выглядит хорошо.
(Редактировать: предыдущий список с неправильного сервера, на новом сервере есть IOMMU)

Когда я запускаю это в терминале с графическим интерфейсом, он загружается и пытается выполнить загрузку PXE.

Кажется, все указывает на то, что virt-manager не проходит проверку.

Я написал приведенный выше скрипт, который загружает последнюю версию virt-manager с github (2.2.1) и запускает ее.

Точно так же, как версия в репозитории Buster (2.0.0-3):

Я пока не понимаю вашей проблемы. В мае прошлого года я взялся за гипервизор (первоначально Jessie) и все проверил. Он запустил виртуальную машину с поддержкой vfio на одной платформе и ушел в ящик. Я поместил его на другую платформу для тестового сеанса всего amdgpu, обновил до текущего buster (~ 2 недели назад), проверил сетевое управление его vm теперь на видео qxl (без аппаратной помощи, тест с несколькими amdgpu не прошел). и эти виртуальные машины запустились и нормально подключились к сети. сделал кучу других вещей и создал образ этого диска в файл, и диск вернулся в ящик.

Так что да, в ящике стола! Мой ежедневник все еще растянут, в основном потому, что тунар Бастера сломался, насколько я понимаю. Мой опыт показывает, что работающее обновление работает, но не подтверждает новую установку. Значит, это где-то в вашей конфигурации.

Это чистая установка Buster и конфигурация libvirt ванильная.

Единственное, что я пока установил на хосте, это dhcp/dns/nfs/samba и docker. Все остальные мои сервисы находятся примерно в 12 док-контейнерах.

Таким образом, KVM уверен, что все работает нормально.

Я удалю libvirt и переустановлю, чтобы посмотреть, смогу ли я воспроизвести его.

и удалил все найденные файлы, каталоги или строки файла конфигурации.

Для запуска KVM необходим процессор, поддерживающий аппаратную виртуализацию. Intel и AMD разработали расширения для своих процессоров, называемые соответственно Intel VT-x (кодовое имя Vanderpool) и AMD-V (кодовое имя Pacifica). Чтобы узнать, поддерживает ли ваш процессор один из них, вы можете просмотреть вывод этой команды:

Если 0, это означает, что ваш ЦП не поддерживает аппаратную виртуализацию.

Если 1 или более, то да, но вам все равно нужно убедиться, что виртуализация включена в BIOS.

По умолчанию, если вы загрузили ядро ​​XEN, оно не будет отображать флаг svm или vmx с помощью команды grep. Чтобы узнать, включена ли она из xen, введите:

Вы должны увидеть флаги hvm в выводе.

В качестве альтернативы вы можете выполнить:

что может привести к следующему выводу:

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

ПРИМЕЧАНИЕ. Вы можете увидеть сообщение типа "Ускорение KVM можно/НЕЛЬЗЯ использовать". Это вводит в заблуждение и означает только то, что KVM *в настоящее время* доступен (т. е. «включен»), *но не*, если он поддерживается.

Используйте 64-битное ядро ​​(если возможно)

Чтобы узнать, является ли ваш процессор 64-разрядным, вы можете запустить эту команду:

Если напечатано 0, это означает, что ваш процессор не 64-разрядный.

Если 1 или выше, да. Примечание. lm означает "длинный режим", который соответствует 64-разрядному процессору.

Теперь проверьте, является ли ваше работающее ядро ​​64-разрядным, просто введите следующую команду:

x86_64 указывает работающее 64-разрядное ядро. Если вы используете See i386, i486, i586 или i686, вы используете 32-битное ядро.

Примечание. x86_64 является синонимом amd64.

Установка KVM

Установите необходимые пакеты

Для следующей настройки мы предполагаем, что вы развертываете KVM на сервере и, следовательно, на компьютере нет X-сервера.

Сначала необходимо установить несколько пакетов:

Cosmic (18.10) или более поздняя версия

Lucid (10.04) или более поздняя версия

Вы также можете установить virt-viewer для просмотра экземпляров.

Добавить пользователей в группы

Karmic (9.10) и более поздние версии (но не 14.04 LTS и 18.10)

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

После этого вам необходимо повторно войти в систему, чтобы ваш пользователь стал действительным членом группы libvirtd. Члены этой группы могут запускать виртуальные машины. (Вы также можете использовать «newgrp kvm» в терминале, но это повлияет только на этот терминал.)

Bionic (18.04 LTS) и выше

Название группы изменено на libvirt, и вы также должны быть членом 'kvm':

Выпуски до Karmic (9.10)

Необходимо убедиться, что ваше имя пользователя добавлено в группы: kvm и libvirtd.

Чтобы добавить себя в группы:

После установки вам необходимо повторно войти в систему, чтобы ваш пользователь стал действительным членом групп пользователей kvm и libvirtd. Члены этой группы могут запускать виртуальные машины.

Проверка установки

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

Если, с другой стороны, вы получите что-то вроде этого:

Что-то не так (например, вы не вошли в систему повторно), и вы, вероятно, захотите исправить это, прежде чем двигаться дальше. Критический момент здесь заключается в том, есть ли у вас права на запись в /var/run/libvirt/libvirt-sock.

Файл sock должен иметь следующие разрешения:

Кроме того, /dev/kvm должен находиться в правильной группе. Если вы видите:

У вас могут возникнуть проблемы при создании виртуальной машины. Вместо этого измените группу устройства на kvm/libvirtd:

Теперь вам нужно либо повторно войти в систему, либо перезапустить модули ядра:

Необязательно: установите virt-manager (графический пользовательский интерфейс)

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

Диспетчер виртуальных машин появится в меню Приложения -> Системные инструменты. Сначала создайте новое подключение к локальному экземпляру QEMU из меню Файл -> Добавить подключение. Localhost (QEMU) или QEMU/KVM должен появиться в списке виртуальных машин. Примечание: подключение Localhost (QEMU Usermode) уже существует, но оно не работает по крайней мере в Ubuntu 10.04.

Создайте новую виртуальную машину, нажав верхнюю левую кнопку панели инструментов Создать новую виртуальную машину.

Примечания для конкретной версии

8.10 (Бесстрашный) Примечания

или перезагрузите систему перед использованием.

Примечания 11.10 (Oneric)

Переключение на ядро ​​сервера может быть полезно, если возникают проблемы с запуском виртуальных машин (например, Windows XP зависает примерно один раз каждые 5 запусков)

KVM/Installation (последним исправленным пользователем hamishmb 23.03.2020 20:00:34)

Материалы этой вики доступны по бесплатной лицензии, подробности см. в разделе Авторские права / Лицензия
Вы можете внести свой вклад в эту вики, подробности см. в Руководстве по вики

В предыдущей главе мы рассмотрели создание гостевых операционных систем KVM и управление ими с помощью графического инструмента virt-manager. В этой главе мы обратим внимание на создание гостевой операционной системы KVM с помощью инструмента командной строки virt-install.

Инструмент virt-install позволяет создавать новые виртуальные машины с помощью списка параметров командной строки. В то время как большинство пользователей, вероятно, останутся с графическим инструментом virt-mamager, virt-install имеет то преимущество, что виртуальные машины могут быть созданы, когда доступ к графическому рабочему столу недоступен, или когда создание должно быть автоматизировано в скрипте.

В этой главе предполагается, что необходимые инструменты KVM установлены и после их установки система была перезагружена. Подробнее об этих требованиях читайте в разделе Установка и настройка виртуализации Fedora KVM.

Содержание

Подготовка системы к virt-install

virt-install предоставляет возможность поддержки графики для установки гостевой операционной системы. Это достигается за счет использования QEMU. Если поддержка графики отключена (по умолчанию она включена) во время сеанса virt-install, будет использоваться стандартный текстовый установщик.

сообщить об этом объявлении

Запуск virt-install для сборки гостевой системы KVM

  • DIRECTORY – путь к локальному каталогу, содержащему образ устанавливаемого дистрибутива.
  • nfs:host:/path или nfs://host/path — Расположение сервера NFS, содержащего образ устанавливаемого дистрибутива — Расположение сервера HTTP, содержащего образ устанавливаемого дистрибутива — Расположение сервера FTP, содержащего образ устанавливаемого дистрибутива
  • путь — путь к используемому носителю, существующему или нет. Существующий носитель может быть файлом или блочным устройством. При установке на удаленном хосте существующий носитель должен использоваться совместно как том хранилища libvirt. Указание несуществующего пути подразумевает попытку создания нового хранилища и потребует указания значения «размер». Если базовым каталогом пути является пул хранения libvirt на хосте, новое хранилище будет создано как том хранилища libvirt. Для удаленных хостов базовый каталог должен быть пулом хранения, если используется этот метод.
  • pool — имя существующего пула хранения libvirt для создания нового хранилища. Требуется указать значение «размер».
  • vol — существующий том хранилища libvirt для использования. Это указывается как «имя пула/имя тома».
  • устройство — тип дискового устройства.Значение может быть «cdrom», «disk» или «floppy». По умолчанию — «диск». Если указан компакт-диск и не выбран метод установки, в качестве установочного носителя используется компакт-диск.
  • bus — тип дисковой шины. Значение может быть «ide», «scsi», «usb», «virtio» или «xen». Значение по умолчанию зависит от гипервизора, поскольку не все гипервизоры поддерживают все типы шин.
  • perms — права доступа к диску. Значение может быть «rw» (чтение/запись), «ro» (только чтение) или «sh» (совместное чтение/запись). По умолчанию: «rw».
  • size – размер (в ГБ), используемый при создании нового хранилища.
  • sparse — следует ли полностью пропустить выделение вновь созданного хранилища. Значение является «истинным» или «ложным». По умолчанию установлено значение «true» (не выделять полностью). Первоначальное время, необходимое для полного выделения гостевого виртуального диска (запасной = false), обычно будет сбалансировано за счет более быстрого времени установки внутри гостя. Таким образом, рекомендуется использовать этот параметр, чтобы обеспечить стабильно высокую производительность и избежать ошибок ввода-вывода в гостевой системе в случае переполнения файловой системы хоста.
  • cache — используемый режим кэширования. Кэш-память хоста обеспечивает кэш-память. Значением кэша может быть «нет», «сквозная запись» или «обратная запись». 'writethrough' обеспечивает кэширование чтения. 'writeback' обеспечивает кэширование чтения и записи. См. раздел примеров для некоторых применений. Этот параметр исключает использование "--file", "--file-size" и "--nonsparse".
  • bridge:BRIDGE — подключение к мостовому устройству на хосте под названием «BRIDGE». Используйте этот параметр, если хост имеет статическую сетевую конфигурацию, а гостю требуется полное исходящее и входящее подключение к/от локальной сети. Также используйте это, если с этим гостем будет использоваться динамическая миграция.
  • network:NAME — подключение к виртуальной сети на узле под названием «NAME». Виртуальные сети можно просматривать, создавать и удалять с помощью инструмента командной строки «virsh». В немодифицированной установке «libvirt» обычно есть виртуальная сеть с именем «по умолчанию». Используйте виртуальную сеть, если хост имеет динамическую сеть (например, NetworkManager) или использует беспроводную связь. Гость будет подключен к локальной сети с помощью NAT, независимо от того, какое подключение активно.
  • пользователь — подключитесь к локальной сети с помощью SLIRP. Используйте это только при запуске гостя QEMU в качестве непривилегированного пользователя. Это обеспечивает очень ограниченную форму NAT.
  • Если этот параметр опущен, в гостевой системе будет создана одна сетевая карта. Если на хосте есть мостовое устройство с подчиненным физическим интерфейсом, оно будет использоваться для подключения. В противном случае будет использоваться виртуальная сеть с именем «по умолчанию». Этот параметр можно указать несколько раз, чтобы настроить более одной сетевой карты.

Пример команды virt-install

Ссылаясь на приведенный выше список аргументов командной строки, теперь мы можем рассмотреть пример конструкции командной строки с помощью инструмента virt-install.

Следующая команда создает новую виртуальную машину KVM, настроенную для работы под управлением Windows XP. Он создает новый образ диска размером 6 ГБ, выделяет 512 МБ ОЗУ для виртуальной машины, настраивает CD-устройство для установочного носителя и использует VNC для отображения консоли:

После создания гостевой системы появится экран virt-viewer, содержащий установщик операционной системы, загруженный с указанного установочного носителя:

Следуйте стандартной процедуре установки гостевой операционной системы.

Обзор

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

После завершения установки следующим шагом будет обучение администрированию системы виртуальных систем KVM. Этого можно добиться с помощью графического инструмента virt-manager. (см. Управление и мониторинг гостевых систем KVM на базе Fedora).

Поднимите свои навыки работы с Fedora Linux на новый уровень
Книга Fedora 31 Essentials теперь доступна в печатном (36,99 долл. США) и электронном (24,99 долл. США) изданиях. Узнать больше.

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