Proxmox VEシステムでLXCコンテナを使用してGNS3サーバーとKVM仮想化を実行するニッチユースケース(「本番」ではなく講義用ラボ環境)があります。
簡単に言えば、KVMを実行する必要があります。~へLXCコンテナこれは、ホストのCPU仮想化機能をコンテナに渡す必要があることを意味します。私が読んだいくつかのチュートリアルに基づいてこれを作成しましたが、わかりません。なぜ効果がある私はこの設定ファイルの行が実際に何をしているのかわからず、ただ盲目的にコピーして貼り付けました。
私のコンテナ構成は次のとおりです(/etc/pve/lxc/102.conf
)。
arch: amd64
cores: 2
hostname: ubuntu-gns3vm2-clone
memory: 4096
net0: name=eth0,bridge=vmbr0,hwaddr=86:4B:53:B7:66:0A,ip=dhcp,type=veth
ostype: ubuntu
rootfs: local-lvm:base-102-disk-0,size=16G
swap: 2048
template: 1
# LINES IN QUESTION
# This line seems to pass through the host CPU's virtualization features
lxc.cgroup.devices.allow: c 10:232 rwm
# These lines were needed for virtual machine networking to behave, I don't really understand them either
lxc.cgroup.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file
誰かが私がこれを解読するのを助けることができますか?10:232
そして数字はどこ10:200
から来ましたか? cgroupとは何ですか?実際には何をしますか/dev/net/tun
?
私が言ったように、問題はなく、すべてがうまく機能しています。私は完全に理解していないものを配布したくないだけです。 ELI5を自由にお試しください。
ベストアンサー1
私が知っている限り、コンテナにはハードウェアパススルーはありません。 USB デバイス、PCI デバイス、KVM などは、コンテナで使用されるさまざまな分離メカニズムによって権限が削除されない限り、常に使用できます。ドライバ/レイヤーにAware名前空間が含まれていない場合は、名前空間に応じて動作を変更できます。以下は、これらの分離メカニズムのおおよそのリストです。
能力。たとえば、次のようになります
/usr/share/lxc/config/common.conf
。# Drop some harmful capabilities lxc.cap.drop = mac_admin mac_override sys_time sys_module sys_rawio
cgroups。たとえば、次のようになります
/usr/share/lxc/config/common.conf
。# CGroup whitelist lxc.cgroup.devices.deny = a ## Allow any mknod (but not reading/writing the node) lxc.cgroup.devices.allow = c *:* m lxc.cgroup.devices.allow = b *:* m ## Allow specific devices ### /dev/null lxc.cgroup.devices.allow = c 1:3 rwm
[...]
秒単位で計算します。たとえば、次のようになります
/usr/share/lxc/config/common.seccomp
。kexec_load errno 1 open_by_handle_at errno 1 init_module errno 1 finit_module errno 1 delete_module errno 1
これが主なメカニズムであり、他のメカニズムもあります(たとえば、pivot_root
/mount
コンテナが起動したときに、特定の部分に偽のアイテムをインストールしたりアクセスを防ぐ/proc/
ため/sys/
)。
リソースの種類に応じて、さまざまな方法でパススルーをシミュレートできます。例: ほとんどのネットワーク相互作用(基本ハードウェア(または仮想...)ネットワークデバイスではありません)が直接サポートネームスペース問題なく名前空間の周りに移動できます。これがコンテナの基本概念です。全体的な時間旅行とは異なります装備仮想マシンを使用するのと同じです。
現在公開されているUSBシリアルデバイスの場合、/dev/ttyUSB0
これらの名前空間のサポートはありません。これを行うには、通常、単純な設定を容易にしない動的デバイスノード値を持つ関連エントリをコピーmknod
(使用)/dev/
し、このデバイスアクセスへのアクセスを復元するためにデフォルトで削除されるさまざまな権限(上記のcgroupsを参照)を追加する必要があります。します。繰り返しますが、関連するデバイスパスはありません。
KVMケースの場合です。アクセスは最初に削除され、次に(デフォルト
lxc.cgroup.devices.deny = a
)再度追加されます(lxc.cgroup.devices.allow: c 10:232 rwm
)。c 10:232
文字タイプ デバイスノードを記述します。キャラクターメイン10そして未成年者 232: 232 = /dev/kvm Kernel-based virtual machine (hardware virtualization extensions)
、これはKVMの予約済みタプルです。
QEMU/KVM が作成および使用中です。TUN/TAP
装備veth
(コンテナで使用されるインターフェイスの代わりに)ネットワーク接続が可能であるため、QEMU / KVMがそれを使用する権限を再追加する必要があります。これは以下のトンに関連する行です(Linux用に記録された項目は次のとおりです。c 10:200
例200 = /dev/net/tun TAP/TUN network device
)。また、LXCにはオリジナルがプリインストールされているため、mount
コンテナ内では/dev/net
使用できません/dev/net/tun
。別の方法は、コンテナ内にディレクトリを作成し、/dev/net
同じ node( c 10:200
) を作成することです/dev/net/tun
。
より多くのデバイスを追加する必要がある場合は、まずいくつかのテストを実行して、制限事項lxc-attach -e
(アクセスデバイス、使用量、またはmount
すべてrmmod
の操作)をバイパスし、設定にどの権限を追加する必要があるかを確認できます。