libvirtを使用してKVM / qemuで複数の仮想マシンを実行しましたが、ネットワークはほとんどうまく機能します。
これで、仮想マシンが root 以外のユーザーとして実行されると、ネットワークの動作が停止します。私はlibvirtと同様のドキュメントページで有用な情報を見つけました。ほとんどの人は、仮想マシンをシステムユーザーとして実行したいと思っているようですが、そうではありません。
だから：ルート以外のユーザーとしてネットワーキングを使用して仮想マシンを実行するための前提条件（正確にはゲストからのWeb検索）は何ですか？
私は次の場所にいますmyvm.xml：
94 <interface type='user'>
95 <mac address='52:54:00:82:f1:27'/>
96 <model type='virtio'/>
97 <link state='up'/>
98 <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
99 </interface>
このインターフェイスはゲスト内に表示され、DHCP クライアントをイネーブルにするとアドレス 10.0.2.5 が表示されます。デフォルトパスは10.0.2.2で、ネットワーク内でpingできます。この範囲外ではすべて失敗します。
私のホストにはブリッジ（またはlibvirtd用のエントリ）はありませんが、user-libvirtdでユーザーモードNATを実行する必要はありません。そうですか？技術的には、ネットワークアクセスはuser-libvirtdによって提供されますか？
kvmlibvirtdを実行しているユーザーはグループにありますlibvirt。 何のためにどれが必要ですか？ 後者は仮想マシンを実行するために必要ではなく、私の問題には影響しません。
libvirtdホストコンピュータでrootとして有効にして起動しました。これはブリッジを提供しますvirbr0が、root以外のユーザーはそれにアクセスできないようです。 私にそれが必要libvirtdですか？
VMはrootとして実行されない可能性があるため、これは私にとって適切なソリューションではありません。ユーザーは、同じホスト上の他の人の仮想マシンに対する高い権限またはアクセス権を持つことはできません。
答え1
うわー！ 3ラウンドをやろう！ついに成功できるか見てみようスタート。
まず、私の仮想マシンは実際に以前はqemu:///session ではなく qemu:///system にあります。そのため、rootパスワードを入力しなくても、VMはrootとして実行する必要があります（？！なぜそうするのですか？！）。したがって、qemu:///sessionで仮想マシンを試してみたいと思います。 （問題を再現して修正できるかどうかを確認するために手順を進めながらこれを入力しているので、実行するときに少し計画されていないように見えたらそうです。）
それで、まずvirt-managerに行き、プライマリ接続とは異なるQEMU / KVMへの新しい接続を作成し始めました。今回は「QEMU/KVM User Session」を使用しました。 virt-managerでこれを選択すると、「ネットワークオプションは非常に制限されています」というメッセージが表示されます。問題はここから始まるようです。私がその問題を解決できるかどうか見てみましょう。
接続が確立したら、新しいKolibriOS VMを作成し、何が起こるかを見てみましょう。
そのため、VMの作成中にvirt-managerはVMインストールプログラムを含むISOファイルディレクトリを表示できなくなります。したがって、実際に仮想マシンを作成できるように、ISOファイルを指す新しいストレージプールを追加します。 （ディレクトリ：/home/user/ISOファイル）
いいですね。これでISOにアクセスできます。次に、"kolibri.iso"ファイルを使用して新しいKolibriOS VMを作成します。 （OSタイプ：汎用デフォルト、CPU数：1、メモリ：256MB。Kolibriは小さなオペレーティングシステムです。）
KolibriOSはISOの外部で直接使用するように設計されているため、仮想マシンにディスクストレージを提供しません。
さて、最後に興味深い事実を見つけました。ユーザーモードネットワーキングを使用するか、デバイス名を共有するオプションがあります。ユーザーモードネットワーキングから始めましょう。それでも機能しない場合は、共有デバイス「virbr0」を使用してもう一度やり直して、何が起こっているのかを見てみましょう。
私は「完了」ボタンをクリックしました。これで仮想マシンがすばやく起動します。
さて、起動し、「今ネットワークに接続しました」というメッセージが表示されます。有望に見えます。
さて、WebViewが開いているので、「Kolibri Stuff」に行き、何が起こるのか見てみましょう。うまくいけば、Googleにアクセスできることを確認しましょう。
「Kolibri 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）。ついに！点灯しました！
したがって、ユーザーモードVMの内部を正常にナビゲートできるため、これが有効であると仮定します。 「virsh -c qemu:///session list」は、私の「UserKolibriOS」VMが実行中であることを示します。これが示すものです：
Id Name State
-------------------------------
1 UserKolibriOS running
「virsh -c qemu:///system list」が次のように表示されます。
Id Name State
--------------------
だから私はインターネットにうまくアクセスできるユーザーモードの仮想マシンを持っています。それではもう一度やり直して、同じことをしましょう。ただし、今回はLubuntu 18.04を使用してvirtioネットワークアダプタを入手してください。 （私は多くの設定ファイルをダンプする前にすべてが正しく機能していることを絶対に確認したいので、この一連のテストを実行しています。）
これは私のLubuntu 18.04 VM構成です。 CPU 2個、1024MB RAM、ユーザーモードネットワーキング、仮想ハードディスクなし。
わかりました。 VMが起動します。何が起こるのか見てみましょう。
仮想マシンが起動します。ネットワークに接続されていると思われるようです。 Googleを開き、「死のブルースクリーン」を検索して何が起こるのか見てみましょう。
うわー！仮想マシンのインターネットが実際のシステムのインターネットよりも速く実行されているようです。私の検索では、ウィキペディアで「ブルースクリーンの死」を見つけて開きました。私は現在、仮想マシンウィンドウでWindows 10の比較的暗いイメージを見ています。だから私は、ユーザーモードネットワーキングが仮想マシンでのWeb検索に適していると結論付けました。それでは、私の設定が何をしているのか見てみましょう。
まず、KolibriOS VMを起動し、Lubuntu 18.04 VMを起動したときに「connected to 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""のビットが欠落していることを除いて、あなたの設定と同じように見えます。しかし、私のネットワークは機能しますが、あなたのネットワークは機能しません。よく…
今考えているのは、仮想マシンのオペレーティングシステムのネットワーク設定が正しく機能してはならず、仮想マシン自体が完全に構成されていることだけです。
最後に、共有デバイス「virbr0」を使用して最後のテストであるLubuntu 18.04を実行します。ユーザーモードのVMであっても、ブリッジと連携するかどうかを見てみましょう。
完全失敗！すると、画面に次の内容が表示されます。
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''
何？ ！明らかに私のブリッジに接続したくないようです。私の考えでは、ブリッジネットワーキングがユーザーモードVMでは機能しないことが正しいです。ただし、ユーザーモードネットワーキングは機能するため、必要ありません。
ユーザーモードネットワーキング情報についてあなたが提供したリンクから何かを見つけました。これには、ユーザーモードネットワーキングで終わるQEMUネットワーキングのページへのリンクがあります。 「このオプションは非常に便利なデフォルト値を提供します。ゲストオペレーティングシステムは、ホスト上で実行されている他のすべてのアプリケーションと同様に、本質的に透過的なネットワークアクセスを持つためです。」（このオプションは「https://people.gnome」の下にあります。 ) .org/~markmc/qemu-networking.html".) QEMUは実際にインターネット接続を許可していますか、それとも何らかの方法でブロックされていますか?また、QEMU を接続できない場合、VM も接続できません。
したがって、最終的な結論 - これは仮想マシンの構成の問題ではなく、仮想オペレーティングシステムの問題であると考えられます。 Lubuntu 18.04をお試しください。すぐに利用可能です。ここからダウンロードできます： "https://lubuntu.me/downloads/"。そのネットワークが機能していることを確認してください。それ以外はすべてのことをしっかりしているようです。
編集 - この問題は、仮想OSの "/etc/resolv.conf"でいくつかのエントリを編集することで最終的に解決されました。これはUbuntuとArch Linuxで動作します。これで、ユーザーモードネットワーキングが機能します。ありがとう、Ned64！ （詳細については、以下のNed64の説明を参照してください。）
役に立ったことを願っています！
答え2
最新バージョンのQEMU/KVM/LibVirtを使用しています。私のネットワークはroot以外のユーザーではうまく機能しますが、する私のシステムにネットワークブリッジがあります。また、VMを起動すると、VMの起動時にホストシステムが「tun vnet0」に接続されたことを示す「接続設定」というメッセージが表示されます。 （もちろん、同時に実行する追加のVMごとに数が増えます。2番目のVMはvnet1に接続するなどの原因になります。）ブリッジが不足して問題になることがあります。
私がこの理論をテストしたとき、これが起こりました。 KolibriOSを実行している仮想マシンがあり（インストールするのは少し大変でしたが、最終的には機能しました！）、元のブリッジをオンにした状態で作成しました。インターネットは最初から見事に働いた。ブリッジの電源を入れた状態でKolibriOSを起動し、フルブート後にブリッジをオフにします。これにより、仮想マシン内からインターネットにアクセスできなくなります。ホストのvnet0接続が失われたことを確認しました。ブリッジを再びオンにしたが、VMはまだ接続できません。その後、VMをシャットダウンしてブリッジをオフにします。これにより、「プライマリ」ネットワークに問題があるため、仮想マシンを起動することもできません。ブリッジを再びオンにしてVMを起動してみました。ウィンドウが開き、インターネットに再接続できます。
したがって、あらゆる種類のネットワークにアクセスするにはブリッジが必要であるという結論に達しました。足を開けてみてください。ブリッジを使用するためにVMの仮想ネットワークアダプタ（NAT）をいくつか変更する必要があるかもしれません。
また、マイ仮想マシンは、仮想ネットワークアダプタのリンク状態がアクティブな場合にのみネットワークに接続できます。 VMウィンドウの詳細画面に移動してNICエントリをクリックし、リンクステータス：アクティブチェックボックスが選択されていることを確認します。しかし、XMLコードに 。
最後に、インターネットに接続できるようにするKolibriOS VMの仮想ネットワークアダプタにあるXMLコードは次のとおりです。
<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>
これが役立つことを願っています！ゲストでのWebナビゲーションはこの設定で完全に機能します。 WebViewツールを使用してKolibriOSのホームページとGoogleにアクセスできますが、ブリッジがダウンしてもアクセスできません。
私はroot以外のユーザーとしてこれをすべてしました。完全な実験を完了するためにパスワードを入力する必要はありませんでしたので、ルートアクセスなしでうまく機能します。
答え3
これは私の以前の答えに対するNed64の2つのコメントに対する答えです。ゲストとして文を書いてみると、コメントにただ返信することができません。まったく新しい返信を書く必要がありますが、「なぜコメントに返信するのですか？と気になった方はもうご存じでしょう。また、私の答えはかなり強力であることが判明したので、とにかくコメントセクションに合わないでしょう。
さて、今行きます。
役に立ついくつかの情報 - 私はvirt-managerを使って仮想マシンを管理して作業しています。私のコンピュータはLubuntu 20.04 64ビットオペレーティングシステムを使用しています。私のすべての仮想マシン（KolibriOS、PuppyLinux、Lubuntu 18.04）はインターネットにアクセスできます。
私のために足を作る人は誰もいません。 QEMU、libvirt、virt-managerをインストールした後から存在しました。しかし、これらすべてをインストールすると、新しいユーザー（libvirt-qemuと呼ばれる）と3つの新しいグループ（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」ネットワークに接続します。
VMが動作してインターネットに接続している間に "brctl show"を実行すると、次のことが発生することがわかりました。
bridge name bridge id STP enabled interfaces
virbr0 8000.5254006b64fb yes virbr0-nic
vnet0
また、VMがオンの場合、アクティブな接続に「vnet0」が表示され、VMをシャットダウンすると消えます。
仮想マシンを実行せずに「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>
VMの実行中に「virsh net-dumpxml default」も実行しましたが、違いはありませんでした。
役に立つかもしれないもう一つの注意 - 私のユーザーはlibvirtグループに属していますが、kvmグループには属していません。これは役に立つかもしれませんし、混乱するかもしれません。
最後の注意 - 「e1000」モデルタイプを使用する正しいネットワーク上のVMのXMLコードが表示されますが、VMは「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>
これはISOファイルを実行するLive Lubuntu 18.04 64ビットVMです。このVMではインターネットに正常にアクセスできます。
役に立ったことを願っています！