Возможно у эмулятора нет прав для поиска пути kvm
Хост Ubuntu Server 14.04 размещает гостя Ubuntu Server 14.04 через libvirt/qemu-kvm. Система работает нормально, но - как гость - у меня проблемы с записью в общую папку ( ) это сводит меня с ума. Обе машины являются относительными ванильными установками.
Я прикрепил данную папку следующим образом:
От гостя я монтирую файловую систему следующим образом:
Я использую www-data пользователь как таковой будет эффективным пользователем позже, а идентификаторы группы и пользователя должны совпадать, если используется p9, afaiu. Это также означает, что на хосте /data (который является разделом ext4, LVM на RAID, кстати) выглядит так
В гостевой системе, если я пытаюсь записать что-либо в общей файловой системе, я получаю ошибки разрешения (независимо от используемого пользователя):
Я могу читать файлы, хотя
Я пробовал разные вещи, особенно:
- остановил службу apparmor и позвонил по телефону (надеюсь, что это было эффективно)
- установить безопасность ни в одном /etc/libvirt/qemu.conf
- установить пользователя и группу в root /etc/libvirt/qemu.conf
/var/log/syslog и dmesg не показывают ничего подозрительного.
Есть указатели?! Благодарю.
3 ответа
Я знаю, что это старая тема, но я только что натолкнулся на похожую проблему и нашел решение, которое работает, по крайней мере, частично.
Я также изменил значения пользователя и группы в /etc/libvirt/qemu.conf болеть, как ты.
Но я также изменил dynamic_ownership установка, потому что описание звучало многообещающе:
- Ведущий: Debian 8 (Джесси)
- Гость: Debian 8 (Джесси)
- общая папка на хосте принадлежит root
- локальный пользователь с идентификатором 1000 является членом группы libvirt (может быть важно)
- точка монтирования на госте ( /mnt/data ) принадлежит пользователю 1000 ("александр")
Теперь я могу наконец-то записать файлы в смонтированную общую папку с правами root(0) и alexander(1000). (до того, как я это сделал, только root разрешалось записывать файлы здесь)
настройка dynamic_ownership 0 - это то, что должно быть сделано в "отображенном" режиме доступа.
Вот еще немного информации о моей настройке:
Странно то, что на госте эти два файла принадлежат разным пользователям (root и alexander), тогда как на хосте оба файла принадлежат одному пользователю (root:libvirt-qemu).:-О
Я не знаю точно, как работает это волшебство, но, очевидно, оно работает.
Надеюсь это поможет,
Александр
@ Александр дал отличный ответ. Я не делал все, что он делал, но это то, что я делал, чтобы получить права однопользователя, работающие в обоих направлениях в файловой системе 9p. (Этот способ предназначен для того, чтобы заставить 9p работать в обоих направлениях без проблем с безопасностью. Для большей безопасности вам понадобится другой метод или настройки)
ХОСТ (заказ не важен)
Я добавил своего хост-пользователя в следующую группу: (я также являюсь членом ). Этот шаг может быть ненужным, потому что:
в файле /etc/libvirt/qemu.conf вы можете изменить пользователя и группу, с которыми все ваши виртуальные машины проходят аутентификацию и выполняют.
(это мощное небольшое изменение, и последствия должны быть намечены, если вы пытаетесь достичь этого на чем-то вроде рабочего сервера)
(То, что делает вышеупомянутое изменение, говорит хосту виртуальной машины преобразовать все кросс-VM-запросы libvirt для любых гостевых виртуальных машин, которые вы запускаете, в , который вы установили; в том числе guest-VM . * Обратите внимание, что он это общесистемный параметр, касающийся libvirt и расширения qemu, если libvirt - ваш единственный интерфейс qemu.)
(кстати, "Сквош" ссылается на модель безопасности 9p. Это означает "нет" и является наиболее допустимой настройкой для этого контекста).
ГОСТЕВАЯ
(Я также добавил одну опцию, как описано в документе ниже) Моя команда монтирования:
Однако, если у вас нет разрешения на запись в общий ресурс или у вас ограниченное разрешение после того, как вы его настроите, то должно помочь отличное предложение от ответа @randomocean. То есть создайте папку под общим ресурсом и установите chmod 777 к этому.
У меня тоже была эта проблема, создал папку с именем /home/user/shared на хосте, а затем использовал virt-manager для добавления папки и смонтировал ее как 9p virtio на виртуальной машине qemu.
Я проверил настройки в /etc/apparmor.d/libvirt и там есть записи для нового /home/user/shared, и я заметил, что это было только r разрешение на /home/user/shared но это имеет rw для всех файлов в /home/user/shared/ , Я попытался добавить aw для прав на запись, но это, похоже, не сохранилось, поэтому я пошел на хост /home/user/shared и создал подкаталог и сделал chmod 777 для этого подкаталога. Это сработало, и гостевая виртуальная машина смогла записывать в директорию su любые файлы создания и редактирования.
tldr: создайте подкаталог в общей папке с разрешениями 777 и посмотрите, сможете ли вы написать в него.
Я столкнулся с той же проблемой, когда пытался смонтировать каталог с хоста Ubuntu на виртуальную машину Minikube. В вопросе не указан Minikube, но это не имеет значения, поскольку это виртуальная машина, управляемая QEMU/KVM. Приведенные ниже инструкции должны применяться к любой виртуальной машине QEMU/KVM. Я не смог найти конкретных инструкций о том, как смонтировать каталоги хоста в виртуальные машины KVM. Я много искал, и это было довольно утомительно. Я объясню, что я сделал для обработки ошибок разрешений, а также ошибок символических ссылок или ошибок "Неизвестная ошибка 526". Я собираюсь кратко упомянуть, почему была необходима эта настройка, просто чтобы включить несколько ключевых слов, которые могут использоваться кем-то, у кого есть те же проблемы, при поиске решения.
Решение проблем с разрешениями, которые могут возникнуть при запуске виртуальной машины
Решение
Определение объема монтирования
Затем добавьте Filesystem оборудование в Virtual Machine Manager :
- На хосте откройте Virtual Machine Manager бегом virt-manager
- Дважды щелкните виртуальную машину и выберите View > Details
- в Details окно, щелкните Add Hardware .
- Выбрать Filesystem и настройте его так:
- Нажмите Apply . Если виртуальная машина была запущена, изменения будут применены при следующей загрузке.
Squash режим важен, потому что он может обрабатывать символические ссылки. Остальные режимы дали мне too many levels of symbolic links ошибки. Passthrough режим решил проблемы, которые Mapped режим дал, но этого оказалось мало. Squash mode - это режим, который не выдал мне никаких ошибок.
Подключение тома к ВМ
Далее остается только смонтировать том в виртуальную машину. Войдите в виртуальную машину, в моем случае через minikube ssh , а затем смонтируйте том:
- cache=none : Это для повышения производительности. Вы можете изменить это значение на другое в зависимости от вашего случая. Значения объяснены здесь.
- msize=262144 : Это также для повышения производительности. Это определяет "количество байтов, используемых для полезной нагрузки пакета 9p", как объясняется здесь. Это значение по умолчанию, используемое minikube mount .
- rw : "Смонтировать файловую систему для чтения и записи", как описано в manmount . Это вариант mount команда.
Вот и все. Вы должны иметь возможность читать и записывать файлы / каталоги из виртуальной машины без каких-либо проблем. Если /etc/fstab файл внутри виртуальной машины можно изменить, логику подключения можно добавить в файл, чтобы том монтировался автоматически после запуска виртуальной машины. К сожалению, это невозможно для Minikube (см. Disadvantages раздел).
Сегодня хочу поделиться с вами одним из своих наработанных мануалов, который отточен многоразовым применением, про который с уверенностью могу сказать, что «точно работает!» без лишних танцев с бубном.
Ориентирована статья скорее на начинающих системных администраторов, чем на гуру (для них тут ничего нового нет :) ), и в ней я постараюсь раскрыть рабочий и довольно быстрый вариант развертывания сервера виртуальных машин, стараясь при этом охватись как можно больше нюансов и подводных камней.
Поправьте, если не так, но в поиске я не нашел реализации данной задачи именно на CentOS с подробным описанием всех шагов для новичков.
Хорошая серия статей написана librarian, но они для Debian.
Естественно, для бывалых админов, в этом никакой проблемы нет, но повторюсь, моя задача — описать подробную инструкцию для новичков.
Вопрос: в Интернете есть множество руководств для установки Qemu KVM под CentOS, возразите вы, и чем же данная статья будет интересна?
Ответ: здесь описывается полный цикл установки и настройки необходимых для виртуализации компонентов, установка гостевых виртуальных машин (ВМ), настройка белой и серой сети для ВМ, а также некоторые аспекты, которые помогут упростить управление ВМ, используя проброс графики с удаленного сервера на свой ПК и запуском virt-manager.
Начнем с того, что если Вы читаете это, то у вас уже готова ОС CentOS 6 (я использовал версию 6.3), причем для установки гостевых ВМ разной битности (32 или 64), хост-сервер (физический сервер, на котором и будем устанавливать KVM вместе с ВМ) должен быть именно с 64-битной ОС.
Все действия выполняются из-под пользователя root.
Итак, приступим к руководству.
1. Шаг — Подготовка
Проверяем, поддерживает ли CPU аппаратную виртуализацию:
Если вывод не пустой, значит — процессор поддерживает аппаратную виртуализацию.
Кому интересно, все действия выполнялись на конфигурации Intel Xeon Quad Core E3-1230 3.20 GHz / 8GB / 2x 1TB.
Устанавливаем KVM и библиотеки виртуализации:
Запускаем сервис KVM
Смотрим, загружен ли модуль KVM
Должны получить вывод:
В данном случае видим, что загружен модуль kvm_intel, так как произволитель CPU — Intel.
Проверка подключения к KVM
Должны получить вывод:
2. Шаг — Создание хранилища для виртуальных машин (Storage Pool)
Здесь приводится описание, как настроить хранилище разных видов.
В рассматриваемом же примере описан простой тип хранилища — для каждой ВМ создается свой файл *.img под виртуальный жесткий диск (или диски — если добавить их несколько), размещены они будут в директории /guest_images.
Только у нас эта директория будет точкой монтирования отдельного жесткого диска хост-сервера, специально отведенного для этих нужд.
Безопасность сохранения данных и то, что нужно создавать как минимум зеркальный raid массив, чтобы не потерять данные ВМ в случае сбоя жесткого диска, мы не будем, так как это — отдельная тема.
Просмотрим список физических дисков на хост-сервере:
На жестком диске sda установлена ОС, его не трогаем, а вот на sdb создаем раздел на все свободное место диска с файловой системой ext4:
(более подробно про следующие операции можно почитать здесь)
Выбираем диск для редактирования
Создаем новый раздел
Создаем файловую систему ext4 на всем свободном месте диска /dev/sdb
Создаем точку монтирования нашего жесткого диска для файлов виртуальных машин:
Многие советуют отключить вообще Selinux, однако мы выберем иной путь. Мы настроим его правильно.
Если выполнение этой команды не будет успешным, надо установить дополнительный пакет. Сначала узнаем, какой пакет предоставляет данную команду
После этого снова:
Смонтируем раздел /dev/sdb1 в /guest_images
Отредактируем файл /etc/fstab для того, чтобы при перезагрузке хост-сервера раздел с ВМ монтировался автоматически
Добавляем строку по примеру тех, что уже имеются в файле
Сохраняем файл и продолжаем создание хранилища:
Проверяем, создалось ли оно:
Добавляем в автозагрузку:
3. Шаг — Настройка сети на хост-сервере
. ВАЖНО.
Перед выполнением этого шага, надо убедиться, что на хост-сервере установлен пакет bridge-utils,
иначе при выполнении операций с сетью вы рискуете потерять связь с сервером, особенно обидно если он удаленный, и физического доступа к нему у вас нет. Если вывод предыдущей команды пустой, то:
Положим, что для выхода «в мир» использовался интерфейс eth0 и он был соответствующим образом настроен.
На нем настроен IP-адрес 10.110.10.15 из /24 сети, маска — 255.255.255.0, шлюз 10.110.10.1.
Продолжаем, создаем сетевой интерфейс типа «bridge» на хост-сервере
Содержимое файла
Приводим основной сетевой интерфейс, который использовался для выхода в «мир», к виду:
. Важно.
DEVICE=«eth0» Имя интерфейса должно остаться таким, как было в системе. Если у вас для выхода в Интернет использовался интерфейс eth1, тогда редактировать надо его.
HWADDR=«00:2C:C2:85:29:A3» МАС-адрес также должен остаться таким, как был в системе
Когда проверили все, перезагружаем сеть:
Проверяем состояние подключения типа «bridge»:
Получаем что-то вроде этого
Делаем настройки в iptables, чтобы трафик виртуалок «ходил» через соединение типа bridge
Опционально: можно улучшить быстродействие соединения bridge, поправив настройки в /etc/sysctl.conf
4. Шаг — Установка новой виртуальной машины
Установка CentOS на гостевую ВМ:
Примечание 1:
VMName_2 — имя новой виртуальной машины
–ram 1024 — кол-во виртуальной памяти
–arch=x86_64 — архитектура ОС виртуалки
–vcpus=1 — кол-во виртуальных процессоров
–os-type linux — тип ОС
–disk pool=guest_images_dir,size=50 — размещение хранилища, размер вирт. диска
–network=bridge:br0
Примечание 2:
Если на ВМ нужна «белая сеть», тогда ставим
--network=bridge:br0
Если на ВМ требуется «серая сеть», тогда ставим
--network=bridge:virbr0
В этом случае для ВМ будет присвоен серый IP по DHCP от хост-сервера.
--graphics vnc,listen=0.0.0.0,keymap=ru,password=some.password.here
Тут указываем пароль для подключения к ВМ по vnc
Установка Windows на гостевую ВМ:
Примечание:
Параметры такие же, как и в примере с установкой CentOS. Но есть различия.
При установке ОС Windows не увидит виртуального жесткого диска, поэтому надо подгрузить дополнительный виртуальный cdrom с драйверами /iso/virtio-win.iso — расположение файла ISO с драйверами виртуального диска. Взять можно отсюда.
Выполняем команду на установку новой ВМ, затем подключаемся по vnc к хост-серверу для продолжения установки ОС. Для того, чтобы узнать порт для подключения, выполняем:
При установке новой ВМ, порт vnc-сервера увеличится на 1. При удалении ВМ, порт освобождается,
и затем выдается новой ВМ. То есть, номер порта последней ВМ не обязательно самый большой из 590…
Чтобы узнать, на каком порту vnc виртуалка с определенным названием, вводим:
где VMName_1 — имя ВМ, :3 — номер по порядку порта, начиная с 5900, то есть подключаться надо на порт 5903, но в программе UltraVNC сработает и так 10.110.10.15:3
Примечание
Если при создании ВМ вылетает ошибка Permission denied, kvm не может открыть файл диска ВМ *.img,
значит, надо разрешить выполнение действий qemu-kvm из-под root (предполагается, что управление
ВМ производится из-под специально созданного для этих целей пользователя, например, libvirt). Но мы обойдемся и пользователем root.
Находим и раскомментируем в нем строки:
Полезно знать:
Конфиги ВМ находятся здесь /etc/libvirt/qemu/
Для того, чтобы отредактировать параметры (добавить процессор, ОЗУ или еще что-то),
ищем конфиг ВМ с нужным названием, редактируем:
К примеру, можно указать статический порт vnc для конкретной ВМ, чтобы всегда подключаться к нужному порту
Теперь у этой ВМ порт vnc будет — 5914. Не забудьте перезагрузить libvirtd для применения изменений. Саму ВМ тоже следует перезагрузить. Поэтому изменяйте конфигурационный файл ВМ пока она выключена, далее выполняйте service libvirtd reload, затем стартуйте ВМ.
Команды для управления ВМ:
5. Шаг — Настройка сети в случае «серых» IP-адресов в ВМ
Если на 4 шаге вы выбрали серую сеть для новой ВМ (--network=bridge:virbr0), то надо выполнить следующие действия (на хост-сервере!) для проброса трафика на ВМ
Разрешить форвардинг трафика на уровне ядра ОС:
Здесь 10.110.10.15 — белый (внешний) IP хост-сервера. 192.168.122.170 — серый IP-адрес гостевой ОС.
На примере установки ОС CentOS на гостевой машине, когда установка перешла в графический режим, и предлагает подключиться на локальный порт 5901 гостевой ОС.
Подключаемся из ПК, за которым сидите, по vnc к 10.110.10.15:5910 или 10.110.10.15:10 тоже сработает в UltraVNC.
По такому же принципу можно прокинуть порт (стандартный) RDP 3389 или SSH 22 в гостевую ОС.
6. Шаг — Подготовка к управлению виртуальными машинами удаленного сервера с удобным графическим интерфейсом (используя virt-manager)
Есть много способов «прокинуть» графику удаленного сервера на ПК, за которым выполняете действия администрирования. Мы остановимся на ssh-туннелировании.
Положим, что вы выполняете действия с локального ПК под управлением Windows (в операционных системах под управлением Linux сделать это куда легче :), нужно выполнить всего одну команду ssh -X username@12.34.56.78, конечно, с оговоркой, что на удаленном сервере X11 forwarding разрешен и вы сидите за локальным Linux ПК c графической оболочкой), тогда нам необходимо
1. Всем знакомый PuTTY,
2. Порт сервера X для Windows — Xming
3. В настройках PuTTY включить «Enable X11 Forwarding»
Сделать, как показано на картинке:
В момент подключения к удаленному серверу Xming должен быть уже запущен.
На хост-сервере с CentOS для SSH включить X11 Forwarding, для этого отредактируйте файл sshd_config:
Устанавливаем virt-manager на хост-сервере:
Еще один компонент
Чтобы окна отображались без крякозябр
7. Шаг — Непосредственный запуск virt-manager
После этого надо перезайти по SSH к удаленному серверу. Xming должен быть запущен.
Запускаем графическую утилиту управления виртуальными машинами
Откроется окно virt-manager
Консоль управления ВМ
Конфигурация ВМ и ее изменение
Надеюсь, читателю понравилась статья. Лично я, прочитай бы подобную в своё время, резко сократил бы потраченное время на то, чтобы перелопатить множество мануалов от разных админов, для разных ОС; сохранил бы кучу времени, потраченное на гугление, когда появлялись все новые и новые нюансы.
Вопрос 1: /usr/bin/kvm - это нормально? Особенно в сочетании с «qemu probably failed». Лично у меня там написано /usr/bin/qemu-kvm.
вот дамп с полностью работающей виртуалки на другом серваке (делал все аналогично, это уже здесь для тестов совсем выключил сеть)
Debian 6.0.5 у меня если это важно
2 дня читал гугл, настройки appamor какие то делал, еще проверки - ничего не помогает (((
libvirt при старте домена пишет в лог как именно он запускал qemu/kvm. Повторить его запуск из консоли пробовал? И желательно, с расширенной диагностикой (если оно такое умеет).
И желательно, с расширенной диагностикой (если оно такое умеет).
пробовал смотреть, но ничего понять не могу (((
он получается просто ОГРОМНЫМ.
может в этих словах какой то косяк
Using KVM without synchronous MMU, balloon unavailable
где то тут на форуме про этот непонятный балон читал и что его якобы отключить надо - но где и зачем не пойму.
ДА МЕНЯ НЕ ИНТЕРЕСУЕТ ЛОГ ВСЕГО LIBVIRT.
НАЙДИ ЛОГ КОНКРЕТНОГО ДОМЕНА - В НЕМ ЕСТЬ КОМАНДА КОТОРОЙ LIBVIRT ЗАПУСКАЕТ КОНКРЕТНУЮ VM!
ЗАПУСТИ ЭТУ ЖЕ КОМАНДУ ИЗ ТЕРМИНАЛА, И ПОСМОТРИ КАК ОНА ПАДАЕТ ИЛИ НЕ ПАДАЕТ.
это и есть лог запуска конкретной машины, командой
лог уровня варингов содержит как я уже и писал
warning : qemudParsePCIDeviceStrs:1422 : Unexpected exit status '1', qemu probably failed
и больше ничего.
Вот эту команду добей чтобы она запускалась и VM работала.
в логе тишь да гладь, а машина все равно не запускается
причем еще и «висит» чего то ожидая (тоже самое было когда сеть конфигурировал)
машина не запускается, но через ссш тунель теперь подключение «как бы» происходит, но висит статус
Negotiate Protocol Version
а может такое быть что у бриджа и у интерфейса один мак и из-за этого косяк? т.к. на рабочей машине они разные
modprobe tun сделан?
нет, но я и не другой не делал
выполнил принудительно и проверил, ничего не меняется (((
а может такое быть что виртуализация в биосе выключена?
Здравствуйте! В linux-мире я новичок, поэтому нуждаюсь в вашей помощи. Собственно, сабж: поставил KVM & virt-manager, после запустил последний и пытаясь создать новое подключение получаю: Соединение с libvirt не удалось.
Убедитесь, что служба libvirtd запущена. И лог: Libvirt URI is: qemu:///system
Traceback (most recent call last): File «/usr/share/virt-manager/virtManager/connection.py», line 862, in _do_open self._backend.open(self._do_creds_password) File «/usr/share/virt-manager/virtinst/connection.py», line 161, in open open_flags) File «/usr/lib/python2.7/site-packages/libvirt.py», line 105, in openAuth if ret is None:raise libvirtError('virConnectOpenAuth() failed') libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Нет такого файла или каталога Как запустить этого демона?
попробуй добавить своего юзера в группу либвирт
А демон libvirtd запущен? Какой дистрибутив?
Демон не запущен, дистрибутив - manjaro. P.s обратился к archwiki (хотел посмотреть список всех групп), нашел команду $ cat /etc/group, ввел в терминале но он начал ругаться. Ладно, решил проверить в ФС наличие каталога group, так вот, его там (в /etc) не оказалось.
Ну вот и решение проблемы. Запусти.
Спасибо, это действительно то, что нужно! Но теперь появилась другая проблема - «внутренняя ошибка: Не удалось найти эмулятор для x86_64»
ппц, где вы все эти ошибки собираете? Мрак какой-то.
Чтобы демон запускался автоматически при старте машины сделай ещё systemctl enable libvirtd . Это же всё в вики есть, надо же хоть немного знать основы своего дистрибутива.
Не удалось найти эмулятор для x86_64
А ты qemu поставил?
Некоторые просто, кажется, не читают вики, перед тем как пытаться чего-то добиться :)
Ну я тоже на этапе первых проб вики не читал. Но я почему-то не помню подобных вопросов со своей стороны. Может быть, забыл, я хз. Может быть, дело в дистрибутиве?
Премногоблагодарен! Имело место моя неосведомлённость, установил kvm и virt-manager, при этом полагая что kvm и qemu - синонимы (: Не могли бы посоветовать какой-либо ресурс для освоения линукса в общем, и manjaro/arch в частности?
Просто арчвики не полностью соответствует моему дистрибутиву. Возможно не стоило ставить производную, но арч я не осмелился ставить в кач-ве первого десктоп дистрибутива линукс;)
при этом полагая что kvm и qemu - синонимы
виртуализация и эмуляция - это разные вещи. Одно разделяет имеющиеся ресурсы, другое имитирует ресурсы.
арчвики не полностью соответствует моему дистрибутиву
Хм. А какие там у Manjaro отличия от ванильного Arch? Вроде ж просто сборочка, обратно совместимая (?). Но не знаю, на самом деле.
Возможно не правильно выразился, но как я написал выше, у Manjaro отсутствует (скорее находится где-то в другом месте) директива /etc/group, что ввело меня в лёгкий ступор..
Это не директория, а файл. И зачем в него руками лезть? Чего-то я не понимаю, никогда такой необходимости не встречал. Добавить юзера в какую-то группу? Так это через gpasswd -a $USER group делается, ЕМНИП
Осталось самое тяжелое и непонятное для меня - создать сетевой мост. Установил bridge-utils, а дальше котелок не варит :( С чего начать?
А что ты вообще пытаешься сделать? Насчёт сетевых мостов и тому подобного - понятия не имею, что это, зачем и как делается, прошу прощения :( Попробуй добавить в теги темы раздельно qemu, kvm, libvirt, virt-manager - может кто умный в тему придёт (если каст по тегам сработает)
Пытаюсь создать виртуальную машину:) Собственно, при попытке 'завершить' 5 шаг выскакивает «Не удалось запустить виртуальную сеть 'default': внутренняя ошибка: Failed to initialize a valid firewall backend» В Network selection стои «Виртуальная сеть 'default' : NAT неактивен»
Думаю, ты это сделал, но процитирую вики:
ebtables не было, - поставил. Траблы с сетью пока что удалось обойти, поставив галочку в «Изменить настройки перед установкой» (Наконец-то, подумал я, произнося мантру). В общем я попал в окно со списком оборудования и обзора основных параметров. Но радость моя была не долгой, т.к нажав «Начать установку» я увидел «Не удалось завершить установку: 'внутренняя ошибка: Процесс завершился при подключении к монитору: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied '»
cat /etc/group | grep kvm
cat /etc/libvirt/qemu.conf | grep group=
Проверь, равны-ли значения?
И выхлоп ls -l /dev/kvm
Значения одинаковы и равны 78, последняя команда вывела «crw-rw----+ 1 root kvm 10, 232 сен 10 20:32 /dev/kvm»
Хм. lsmod | grep kvm ?
kvm_amd 63268 0
kvm 426660 1 kvm_amd
Пошаговый копипаст успехом не увенчался ):
Сделай сначала один бридж, через который будет сам хост работать. Ты уверен в выборе дистриба?
Возможно как-то поможет, вот.. Лог ошибки:
е удалось завершить установку: 'внутренняя ошибка: Процесс завершился при подключении к монитору: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied '
Traceback (most recent call last): File «/usr/share/virt-manager/virtManager/asyncjob.py», line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File «/usr/share/virt-manager/virtManager/create.py», line 1873, in do_install guest.start_install(meter=meter) File «/usr/share/virt-manager/virtinst/guest.py», line 414, in start_install noboot) File «/usr/share/virt-manager/virtinst/guest.py», line 478, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File «/usr/lib/python2.7/site-packages/libvirt.py», line 3585, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: внутренняя ошибка: Процесс завершился при подключении к монитору: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied
Прости, не знаю что с этим делать. Заведи новую тему насчёт этой ошибки (..Permission denied..) и поставь теги qemu, kvm, libvirt, virt-manager. Может кто-нибудь из знающих эту кухню когда-нибудь придёт и поможет.
Уверен (это же не голый арч, чёрт побери!) Я планировал поставить один из дистрибутивов и параллельно осваивать линукс, вот. Но мне срочно понадобилась виртуалка с виндой, вернее одна из майкрософтских софтин, но т.к на винду я возвращаться не хочу, решил обзавестись хотя бы виртуалкой, сорри за тавтологию. Есть где-гить на просторах сети адекватный мануал по созданию бриджа?
Попробуй trusty или wheezy/jessie, для начала. У меня не было вообще никаких сложностей.
срочно понадобилась виртуалка с виндой
Возможно, быстрее будет накатить обычный пролетарский VirtualBox, чем бодаться с libvirt. Тем более в нём вроде поддержка KVM появилась, если я ничего не путаю.
А под Wine не пойдёт?
fludardes ★★ ( 11.09.15 00:42:44 )
Последнее исправление: fludardes 11.09.15 00:43:38 (всего исправлений: 1)
Я не в курсе пойдет ли MS Access под Wine. А разве VirtualBox поддерживает x64 архитектуру?
А разве VirtualBox поддерживает x64 архитектуру?
x86_64 - гость? А почему он не должен поддерживать? У меня 64-битная винда в нём стоит. На x86_64-системе.
Поставил VirtualBox, создаю виртуальный жесткий диск и.. И иду спать. Спасибо за помощь! Но всё же наслышан профитом Qemu по сравнению с VirtualBox, посему завести этого демона в буквальном смысле - дело принципа :)
Удачи. Про вики не забывай - там с VirtualBox не всё так просто.
У них обоих (VB и QEMU/KVM) есть как сильные, так и слабые стороны. Лично я бодался-бодался с QEMU/KVM, подержал пару виртуалок, и забил, перейдя на VBox - ибо он в некоторых местах много проще.
Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied
После добавления пользователя в группу пользователь должен перевойти в систему, для получения реальных прав группы.
Есть. Гугл в помощь, неужели это так сложно?
dvrts ★★★ ( 11.09.15 07:55:09 )
Последнее исправление: dvrts 11.09.15 07:55:24 (всего исправлений: 1)
Тем более в нём вроде поддержка KVM появилась, если я ничего не путаю.
На прошлой неделе поставил Debian, актуальная версия с сайта.
уже узнал что такое терминал, как установить qemu-kvm, virt-manager и прочее что писали в разных статьях.
В общем я удачно смог запустить виртуальную машину через virt-manager и пробросить через «Add Device» оба устройства. Система на ВМ на момент проброса уже была установлена, гостевая винда увидела новое устройство, аудио стало сразу, на gpu скачал драйвера, все встало но после перезагрузки ВМ - синий экран.
Соответственно в проце есть своя vga, которую я использую на хосте, а pci карту пробрасываю в ВМ. Соответственно grub и bios настроены, аппаратная виртуализация в целом работает. У меня: Intel core i7 4x3.6GGz GT, Asus Strix GTX 970
Подумал, что проблема в самой настройке ВМ. На форумах узнал что NVidia на уровне драйверов блокирует запуск на kvm, если видит данный параметр.
Далее куда надо прописать параметры, которые указаны для запуска?
Люди добрые, подскажите, по шагам, как мне сделать ВМ с пробросом моей карты?
Может где есть полная статья под debian, от того какие компоненты и как надо установить, до того, как запустить ВМ с аналогичными командами (Куда их прописать?), тогда я подставлю эти команды с поправкой на адреса моей карты и вуаля.
В общем я пытался найти всю информацию сам, но понял, что без помощи я здесь не разберусь :)
Для включения проброса надо добавить в /etc/default/grub:
Создать файл /etc/modprobe.d/pci-stub.conf следующего содержания:
Где 1002:6718 и 1002:aa80 заменить на свои значения, соответствующие видео карточке и её звуку (lspci -n). Этот шаг не обязателен, если у тебя в системе нет двух карточек, использующих один и тот же драйвер, и одну из них ты хочешь пробросить в виртуалку. В противном случае проще запретить загрузку драйвера для свой видео карточки, создав файл /etc/modprobe.d/.conf:
Создать файл /usr/sbin/vfio-bind:
Создать файл /etc/systemd/system/vfio-bind.service:
Если ты нигде не накосячил, если смог загрузиться, если твоя система поддерживает проброс, то в каталоге /dev/vfio у тебя должен появиться файлик с именем «XX», где XX - какие-то цифры (у меня они - 26). Если используешь virt-manager, то в файле /etc/libvirt/qemu.conf найти параметр cgroup_device_acl и изменить его примерно таким образом:
где XX - твои циферки. Перезапустить сервис командой systemctl restart libvirtd.service. После чего можно пробовать запустить виртуалку через virt-manager.
Конфиг моей машины выглядит примерно следующим образом:
Для nvidia в раздел features надо добавить строчки:
Спасибо за инструкцию!
Но опять синий экран.
Все сработало без косяков. Оба PCI пробросил через «Добавить устройство» в virt-manager. Через virsh edit добавил kvm hidden=on как написано в инструкции) После установки VGA с сайта NVIDIA драйверов на ВМ - экран смерти. Запустил восстановление, винда заработала)
Я заметил что у меня нет тега commandline, мне его тоже надо скопировать?
Также не могу пробросить USB HDD или подключить какую-нить папку для обмена файлами между хостом и гостем. при пробросе USB не встают дрова на винде, а filesystem вообще винда не видит.
Видеокарточку не надо добавлять через диалог virt-manager - скорее всего работать не будет. Лучше делать это через virsh. Для этого в конфиге виртуалки должны присутствовать следующие строчки:
Чтобы проверить работоспособность карточки в виртуалке, можно сделать следующее: отключить эмуляцию видео. Если карточка работает, то ты сразу увидишь на экране загрузку виртуалки, начиная с биоса. Для этого надо отредактировать конфигурацию вм следующим образом:
Плюс надо удалить из конфига секции
Ещё попробуй пробросить только видео, без hdmi-audio. Но его всё равно надо будет забиндить на vfio, даже если в виртуалку его не будешь пробрасывать. У меня на интеле вм категорически отказывается работать, если я пробросил hdmi-audio. Хотя, на амд с этой же карточкой всё работало без всяких проблем в любых конфигурациях.
Кстати, на амд у меня работал проброс видео и аудио через добавление устройств в virt-manager. Для этого даже не требовалось биндить видео к vfio, а достаточно было только добавить pci-stub.conf. А материнка под интел в этом плане оказалась на редкость капризной, причём, винда 8 и 10 работают с эмулированной карточкой, а 7 в той же конфигурации ни в какую.
Проблема
Я запускал Minikube через VirtualBox. VirtualBox может монтировать /Users на MacOS или /home в Linux - в виртуальную машину, и вам не нужно решать проблемы с монтированием в такой степени, как с KVM. Мне нужно было разработать приложение для Android, серверная часть которого должна работать на Kubernetes. Чтобы протестировать приложение Android, мне нужно запустить виртуальные устройства, которые запускаются через KVM в Linux. Невозможно запустить виртуальную машину на VirtualBox и виртуальную машину на KVM одновременно, потому что только одна из них может использовать технологию виртуализации процессора одновременно. Было бы довольно неудобно выключать Minikube, когда мне нужно было что-то проверить в приложении для Android или наоборот. Поскольку на KVM можно запускать несколько виртуальных машин одновременно, я решил запустить Minikube на KVM только для того, чтобы одновременно запускать и Minikube, и виртуальные устройства Android. Также с VirtualBox можно запускать несколько виртуальных машин одновременно,но виртуальные устройства Android по умолчанию не работают на VirtualBox. Похоже, Genymotion использует VirtualBox, но это платное решение.
Моей целью было смонтировать каталог, содержащий файлы моего приложения, точно так же, как монтирует VirtualBox. Minikube может монтировать каталоги с хоста через minikube mount команда, но на момент написания она по какой-то причине не является надежной. Это дало мне Unknown error 526 пока я пытался получить доступ к файлам. Это тоже очень медленно.
Ответ @Alexander помог мне решить проблему. Но этого было недостаточно, так как я не хотел запускать виртуальные машины как root . Когда они запускаются как root файлы и / или каталоги, созданные внутри виртуальных машин, имеют root:root разрешение в хосте, чего я не хочу.
Определение пользователя, который запускает виртуальные машины
Прежде всего, я редактировал /etc/libvirt/qemu.conf файл (на хосте), чтобы изменить пользователя, который запускает процессы виртуальной машины от имени моего пользователя, то есть ubuntu , и отключить dynamic_ownership :
После внесения вышеуказанного изменения я перезапустил свой хост-компьютер, поскольку не знаю, как применить изменения в противном случае. Без перезапуска виртуальные машины продолжали работать от имени предыдущего пользователя, который был libvirt-qemu . Чтобы убедиться, что изменение было применено, сделайте следующее:
- На вашем хост-компьютере запустите ps aux | grep kvm
- Проверьте пользователя, который запускает процессы виртуальной машины. Тебе следует увидеть ubuntu в этом случае.
Читайте также: