As far as I known, there's no hardware passthrough in containers: USB devices, PCI devices, KVM, etc. are always available as long as permissions to use them are not removed by various isolation mechanisms used in containers, or perhaps unless their driver/layer include namespace awareness allowing them to change behaviour depending on namespace. Here's a non exhaustive list of such isolation mechanisms:
capabilities . Eg in
# Drop some harmful capabilities
lxc.cap.drop = mac_admin mac_override sys_time sys_module sys_rawio
cgroups. Eg in
# 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
lxc.cgroup.devices.allow = c 1:3 rwm
seccomp. Eg in
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1
These are the main machanisms, there are others (eg:
mount when the container is started, or mounting fake entries over some portions of
/sys/ to prevent access).
Mimic-ing a passthrough can be done in multiple ways depending on the kind of ressource. Eg: most network interfaces (not their underlying hardware (or virtual...) network device) have direct support for namespaces and can be moved around namespaces without trouble. It's a base concept for containers. It's not the same as passing through the whole device like is done with a VM.
Now if it's an USB serial device exposing for example
/dev/ttyUSB0, there's no such namespace support. This requires copying (using
mknod) the relevant
/dev/ entry, which usually has a dynamic device node value which won't help making a simple configuration, and adding various permissions that were removed by default (see cgroups above) to restore access to this device. Again, there was no device passthrough involved.
So, for your KVM case. Access was first removed (that's the default
lxc.cgroup.devices.deny = a), and you add it back (
lxc.cgroup.devices.allow: c 10:232 rwm).
c 10:232 describes a device node of type character with char major 10 and minor 232:
232 = /dev/kvm Kernel-based virtual machine (hardware virtualization extensions), that's the reserved tuple for KVM.
QEMU/KVM is creating and using
TUN/TAP devices (instead of
veth interfaces used with containers) to have network connectivity, so permission to use them by QEMU/KVM should be added back, that's what are the lines related to tun below (the Linux documented entry for
c 10:200 is
200 = /dev/net/tun TAP/TUN network device). Also, as
mount is forbidden inside the container, LXC pre-mount the original
/dev/net for it to be able to use the original
/dev/net/tun. I think an other method would have been, in the container, to create the directory
/dev/net and create the same node (
If you have to add more devices, you can first do some tests with
lxc-attach -e which bypasses all limitations (eg: access to a device, using
rmmod all work) and then see what permissions should be added back in the configuration.