qemu/KVM/libvirt usermode networking :VM в качестве -не root-пользователя, что мне нужно, чтобы root -меньше работал в сети?
Путем запуска дочерней оболочки для каждой строки ввода вxargs:
xargs -I {} sh -c 'cmd1 "$1" && cmd2 "$1" && cmd3 "$1"' sh {}
xargs -I {} sh -c 'cmd1 "$1"; cmd2 "$1"' sh {}
Это запускает sh -c, который выполняет данную строку как сценарий оболочки. Аргументы sh -cпосле самого скрипта передаются $0и $1внутри скрипта. Значением $0обычно должно быть имя оболочки, поэтому мы передаем shв качестве этого аргумента (, оно будет использоваться в сообщениях об ошибках ).
Как вариант,
xargs sh -c '
for arg do
cmd1 "$arg" && cmd2 "$arg" && cmd3 "$arg"
done' sh
xargs sh -c '
for arg do
cmd1 "$arg"
cmd2 "$arg"
done' sh
Эти варианты будут принимать как можно больше аргументов, а затем применять к ним код в цикле внутри скриптов sh -c.
Как всегда, при использовании xargsнеобходимо соблюдать осторожность, чтобы аргументы, передаваемые данной утилите(sh -cздесь ), были правильно разделены.
Уф! А вот и третий раунд! Посмотрим, сможем ли мы заставить это работать в конце концов. Вот оно.
Во-первых, моя виртуальная машина на самом деле была в qemu :///системе, а НЕ в qemu :///сеансе. Итак, хотя мне не нужно было вводить пароль root, виртуальная машина все равно должна была работать как root (?! Зачем они это сделали?! ). Итак, пробуем виртуальную машину в qemu :///session. (Я пишу это, когда выполняю шаги, чтобы увидеть, смогу ли я воспроизвести вашу проблему и исправить ее, поэтому, если это кажется немного незапланированным, потому что это так.)
Итак, сначала я зашел в виртуальный -менеджер и начал устанавливать новое соединение с QEMU/KVM, отличное от соединения по умолчанию -, на этот раз я использую «пользовательскую сессию QEMU/KVM». Когда я выбрал его в диспетчере virt -, он сказал мне, что «сетевые возможности очень ограничены». Так что это похоже на то, где начинается проблема. Посмотрим, смогу ли я обойти это.
Установив соединение, сейчас я создам в ней новую виртуальную машину KolibriOS и посмотрю, что произойдет.
Таким образом, во время создания ВМ менеджер virt -больше не видит мой каталог файлов ISO, содержащий мои установщики ВМ. Поэтому я собираюсь добавить новый пул хранения, указывающий на мои файлы ISO, чтобы я мог создать виртуальную машину. (каталог :/home/user/ISO Files)
Хорошо, теперь у меня есть доступ к моим ISO. Теперь я собираюсь создать новую виртуальную машину KolibriOS с моим файлом «kolibri.iso». (Тип ОС :Общее значение по умолчанию, количество процессоров :1, память :256 МБ. Kolibri — крошечная ОС.)
Я не собираюсь выделять виртуальной машине какое-либо дисковое пространство, так как KolibriOS предназначена для использования непосредственно вне ISO-образа.
Теперь, наконец, я дошел до конца и заметил одну интересную вещь. Мне предоставляется возможность использовать либо сеть пользовательского режима, либо имя общего устройства. Я собираюсь начать с сети в режиме пользователя, и если это не сработает, мы попробуем еще раз с общим устройством «virbr0» и посмотрим, что произойдет.
Я нажал кнопку «Готово». Теперь моя виртуальная машина должна загрузиться в кратчайшие сроки.
ОК, он загрузился, и я получил "Теперь вы подключены к сети". Кажется многообещающим.
Теперь я открыл WebView и собираюсь зайти в "Kolibri Stuff" и посмотреть, что произойдет. Если это сработает, я посмотрю, смогу ли я добраться до Google.
Кнопка "Колибри Stuff" сработала -теперь я вижу страницу " http://store.kolibri-n.org/en.html". Теперь попробуем Google.
Конечно же, есть Google со ссылкой на Политику конфиденциальности. Посмотрим, что произойдет, если я нажму на нее.
Ну, совершенно очевидно, что WebView не понимает, что, черт возьми, написано на этой странице, но я получил на своем экране большую кучу запутанного JavaScript, так что, очевидно, он что-то загрузил. Давайте попробуем NSInstall.
Хорошо, нужно загрузить приложение NetSurf. Если он может загрузить это, я предполагаю, что сеть работает.
Загрузка завершена. Теперь давайте снова попробуем Google.
Ладно, NetSurf не понравился Google.Попробуем Дедоимедо. По сути, это куча обзоров Linux и тому подобного.
Окончательный вывод -NetSurf воняет! Я возвращаюсь к WebView.(http://www.dedoimedo.com/index.html). Ну наконец то! Он открылся!
Итак, поскольку я могу успешно перемещаться внутри своей виртуальной машины пользовательского режима, я предполагаю, что это работает. «virsh -c qemu :///список сеансов» теперь показывает мою работающую виртуальную машину «UserKolibriOS». Вот что он показывает:
Id Name State
-------------------------------
1 UserKolibriOS running
И "virsh -c qemu :///системный список" теперь показывает это:
Id Name State
--------------------
Итак, у меня есть виртуальная машина пользовательского режима, которая нормально подключается к Интернету. Теперь попробуем еще раз, проделав то же самое, но на этот раз с Lubuntu 18.04, чтобы мы получили сетевой адаптер virtio. (Я провожу эту серию тестов, потому что хочу быть абсолютно уверенным, что все работает, прежде чем выгружать на вас кучу файлов конфигурации.)
Вот моя конфигурация виртуальной машины Lubuntu 18.04 :2 ЦП, 1024 МБ ОЗУ, сетевое подключение в пользовательском режиме, без виртуального жесткого диска.
OK, виртуальная машина загружается. Давай посмотрим что происходит.
ВМ загружена. Кажется, что он подключен к сети. Я собираюсь открыть Google и выполнить поиск «синий экран смерти» и посмотреть, что произойдет.
Ого! Интернет в моей виртуальной машине почти работает быстрее, чем Интернет в моей физической системе. Я смог найти «Синий экран смерти» в Википедии из своего поиска и открыл его. Теперь я смотрю на относительно мрачную картину хмурой Windows 10 в окне моей виртуальной машины. Итак, я пришел к выводу, что сеть в пользовательском режиме отлично работает для просмотра веб-страниц на виртуальной машине. Теперь давайте посмотрим, что делает моя конфигурация.
Во-первых, я заметил, что при запуске виртуальной машины KolibriOS и при запуске виртуальной машины Lubuntu 18.04 на моем экране не появлялось сообщение «подключено к tun vnet0».
А теперь конфигурация сетевого адаптера, сначала для KolibriOS:
<interface type="user">
<mac address="52:54:00:6f:ab:33"/>
<model type="e1000"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/>
</interface>
Итак,вот как выглядит Lubuntu 18.04:
<interface type="user">
<mac address="52:54:00:7d:63:ba"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
Итак, теперь моя конфигурация выглядит идентично вашей, за исключением того, что в моей конфигурации отсутствует бит о "link state="up"". Тем не менее, моя сеть работает, а ваша нет. Хм...
Теперь я могу думать только о том, что сетевые настройки в ОС вашей виртуальной машины не должны работать, а сама ваша виртуальная машина должна быть настроена идеально.
Наконец, я собираюсь провести последний тест -Lubuntu 18.04 с общим устройством «virbr0». Давайте посмотрим, работает ли он с сетевым мостом, даже если это виртуальная машина пользовательского режима.
Полный провал! Я получил этот беспорядок на моем экране, когда я попробовал:
Unable to complete install: 'internal error: /usr/lib/qemu/qemu-bridge/helper
--br=virbr0 --fd=29: failed to communicate with bridge helper: Transport
endpoint is not connectedH001F007F stderr=failed to parse default acl file`/
-etc/qemu/bridge.conf''
Что?! Очевидно, он не хочет подключаться к моему сетевому мосту. Я думаю, что вы правы в том, что мостовая сеть вообще не будет работать с виртуальной машиной пользовательского режима. Но сеть в пользовательском режиме работала, так что в этом нет необходимости.
Я заметил кое-что в ссылке, которую вы мне дали, на информацию о сети в пользовательском режиме. В нем была ссылка на страницу о сети QEMU, которая заканчивалась на сети пользовательского режима. В конце было сказано, что «эта опция обеспечивает очень полезное значение по умолчанию, поскольку гостевая ОС будет иметь в значительной степени прозрачный доступ к сети, почти как любое другое приложение, работающее на хосте». (Это было в " https://people.gnome.org/~markmc/qemu-networking.html". )Действительно ли QEMU разрешено подключаться к Интернету? Или он каким-то образом заблокирован? Не уверен, что вообще возможно заблокировать доступ в Интернет для одного процесса в Linux, но может, Если QEMU не может подключиться, виртуальная машина не сможет подключиться
.Итак, окончательный вывод -Я думаю, что это проблема с виртуальной ОС, а не с конфигурацией вашей виртуальной машины. Попробуйте Lubuntu 18.04 -заработало сразу, прямо из коробки. Вы можете скачать его отсюда :" https://lubuntu.me/downloads/". Посмотрите, работает ли там сеть. В остальном, похоже, вы все делаете правильно.
Изменить -Эта проблема была наконец решена путем редактирования некоторых вещей в "/etc/resolv.conf" в виртуальной ОС. Это работало на Ubuntu и Arch Linux. Сеть в пользовательском режиме теперь работает. Спасибо Нед64! (Подробнее см. комментарий от Ned64 ниже.)
Надеюсь, это поможет!
Это ответ на два комментария от Ned64 к моему последнему ответу. Я пишу как гость, поэтому я не могу просто ответить на комментарий -Мне нужно написать совершенно новый ответ, поэтому, если вы задаетесь вопросом: «Почему бы просто не ответить на комментарий?», теперь вы знать. Кроме того, мой ответ оказался довольно громоздким, поэтому он все равно не поместился бы в разделе комментариев.
Хорошо, поехали.
Некоторая информация, которая может оказаться полезной. -Я использую диспетчер virt -для управления и использования моих виртуальных машин. Я использую на своем компьютере 64-битную операционную систему Lubuntu 20.04 -. Все мои виртуальные машины (KolibriOS, PuppyLinux и Lubuntu 18.04 )имеют доступ в Интернет.
Никто другой не создавал мне сетевой мост. Именно там я установил QEMU, libvirt и virt-manager. Однако, когда я установил все это, появился новый пользователь (с именем libvirt -qemu ), а также три новые группы (с именами libvirt, libvirt -qemu и libvirt -dnsmasq ), и я заметил, что он имеет доступ к некоторым каталогам (, таким как /var/lib/libvirt/images ), к которым мой обычный пользователь не может получить доступ, поэтому я предполагаю, что libvirt -qemu отвечает для моего сетевого моста. Кроме того, мой пользователь по умолчанию находится в группе libvirt, чего мне не нужно было делать самому -снова, процедура установки, должно быть, сделала это за меня.
Вот результат моего "brctl show":
bridge name bridge id STP enabled interfaces
virbr0 8000.5254006b64fb yes virbr0-nic
Как бы то ни было, если я щелкну значок своей сети, я увижу «virbr0» в списке активных подключений, поэтому мой физический компьютер подключен к сети «virbr0», как к реальной сети Ethernet..
Я заметил, что «brctl show» выглядит немного иначе, если я делаю это, когда виртуальная машина запущена и подключена к Интернету; вот что будет, если я это сделаю:
bridge name bridge id STP enabled interfaces
virbr0 8000.5254006b64fb yes virbr0-nic
vnet0
Кроме того, «vnet0» появляется в моих активных подключениях, когда виртуальная машина включена, и исчезает, когда я выключаю свою виртуальную машину.
Вот что я получил от «virsh net -dumpxml default» без запущенных виртуальных машин:
<network>
<name>default</name>
<uuid>940f02c2-f3ba-4f25-ad0f-5876a41b5d3b</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:6b:64:fb'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.122.2' end='192.168.122.254'/>
</dhcp>
</ip>
</network>
Я также сделал "virsh net -dumpxml default" во время работы виртуальной машины -, это не имело значения.
Еще одно потенциально полезное замечание -Мой пользователь находится в группе libvirt, но НЕ входит в группу kvm. Это может быть полезно, а может просто сбивать с толку.
И последнее замечание. -Я вижу, что XML-код моей виртуальной машины с правильным подключением к сети использует тип модели "e1000", но ваша виртуальная машина использует "virtio". Вот код виртуальной машины с работающим Интернетом, которая использует сетевой адаптер virtio:
<interface type="network">
<mac address="52:54:00:97:df:ec"/>
<source network="default" portid="59b9b7c2-9453-43b6-8420-99961b5065c7" bridge="virbr0"/>
<target dev="vnet0"/>
<model type="virtio"/>
<alias name="net0"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
Это живая 64-битная виртуальная машина Lubuntu 18.04 -, работающая на основе файла ISO. -Я могу без проблем получить доступ к Интернету внутри нее.
Надеюсь, это поможет!
Я использую самую новую версию QEMU/KVM/LibVirt от -до -. Моя сеть отлично работает на -не root-пользователе, но у меня есть сетевой мост в моей системе. Кроме того, когда я запускаю виртуальную машину, я получаю сообщение «Соединение установлено» при запуске виртуальной машины, показывающее, что хост-система подключена к «tun vnet0» при запуске виртуальной машины. (Конечно, количество увеличивается для каждой дополнительной ВМ, работающей одновременно -вторая ВМ вызывает подключение к vnet1 и т. д. )Отсутствие сетевого моста может быть проблемой.
Итак, вот что произошло, когда я проверил теорию. У меня есть виртуальная машина под управлением KolibriOS (, которую сложно установить, но в конце концов она сработала! )Первоначально я создал его, когда сетевой мост был включен. Интернет работал отлично с самого начала. Я запустил KolibriOS с включенным сетевым мостом, а затем выключил сетевой мост после полной загрузки. Затем я не смог получить доступ к Интернету из виртуальной машины. Я заметил, что соединение vnet0 было потеряно на хосте. Я снова включил сетевой мост, но виртуальная машина по-прежнему не могла подключиться. Затем я выключил виртуальную машину и снова отключил сетевой мост. Тогда я даже не смог загрузить виртуальную машину, так как у нее была проблема с сетью «по умолчанию». Я снова включил сетевой мост, затем попытался запустить виртуальную машину. Он включился, и снова появился доступ в Интернет.
Итак, это приводит меня к выводу, что сетевой мост необходим для доступа к любой сети любого типа. Попробуйте включить сетевой мост. Вам также может потребоваться внести некоторые изменения в виртуальный сетевой адаптер (NAT )вашей виртуальной машины, чтобы она использовала сетевой мост.
Кроме того, моя виртуальная машина может подключаться к сети только в том случае, если состояние связи виртуального сетевого адаптера активно. Перейдите на экран «Подробности» в окне виртуальной машины, щелкните запись сетевой карты и проверьте, установлен ли флажок «Состояние канала :активно». Сомневаюсь, что проблема в этомхотя, поскольку ваш XML-код говорит.
Наконец, вот код XML в виртуальном сетевом адаптере моей виртуальной машины KolibriOS, который может подключаться к Интернету:
<interface type="network">
<mac address="52:54:00:18:a8:56"/>
<source network="default" portid="2090855d-4e56-4e55-ad97-9fad39d782ba" bridge="virbr0"/>
<target dev="vnet0"/>
<model type="e1000"/>
<link state="up"/>
<alias name="net0"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0"/>
</interface>
Надеюсь, это поможет! Просмотр веб-страниц в гостевом режиме отлично работает с этой настройкой -Я могу получить доступ к домашней странице KolibriOS и Google из инструмента WebView, тогда как я не мог, когда сетевой мост был отключен.
Я сделал все это как -не root-пользователь. -Мне ни разу не пришлось вводить пароль, чтобы провести весь эксперимент, так что все должно работать без root-доступа.