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によって提供されますか?
kvm
libvirtdを実行しているユーザーはグループにあります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の説明を参照してください。)
役に立ったことを願っています!