Limits.cpu limit not working?

I’m using LXD on ArchLinux.

lxd --version
lxc --version

Here is my default profile:

  boot.autostart: "true"
  limits.cpu: "36"
  nvidia.runtime: "true"
description: Default LXD profile
    name: eth0
    nictype: macvlan
    parent: enp5s0
    type: nic
    type: gpu
    path: /
    pool: default
    type: disk
name: default
- /1.0/containers/demo

I have 48 CPUs on host system, and set limits.cpu = 36. However, htop in container demo shows that there are 48 CPUs in the container. Anything goes wrong?

I notice that lxcfs is not installed. And lxd is not available in ArchLinux official repo, I install it from ArchLinuxCN repo. After install lxcfs, and start lxcfs.service, things works as expected.
Do lxd or lxc depends on lxcfs? Maybe there is a package issue in ArchLinux repo.

This key limits the number of cores that the container will be using.
It does not hide (at this time?) the number of cores of the CPU to show only those that you have specified.
I think that the parent process of the container is the one that will perform the limit of the number of cores, therefore even if the container sees 48 cores, it can’t touch all of them.

Can you explain for us mere mortals what does that mean? In my setup
if I

lxc config set xenial-www limits.cpu 5
then my nproc and htop show only 5 cpus. This is on a 12 core system having only a single physical processor.

lxc --version

On the bare metal:

cat /proc/cpuinfo shows

processor	: 0 to 11
vendor_id	: GenuineIntel
cpu family	: 6
model		: 44
model name	: Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
stepping	: 2
microcode	: 0x1f
cpu MHz		: 1595.905
cache size	: 12288 KB
physical id	: 0
siblings	: 12
core id		: 9
cpu cores	: 6
apicid		: 19
initial apicid	: 19
fpu		: yes
fpu_exception	: yes
cpuid level	: 11
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid dtherm ida arat flush_l1d
bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips	: 4787.67
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual

The containers do not have a full view of the hardware of the host, and whatever view they have, is controlled by LXCFS. It is up to what is supported currently by LXCFS, whether a container sees the full number of the cores, or a reduced number.

Here is the latest release of LXCFS, along with the list of changes,

You can see that in the recent changes, there is even better virtualization support for /proc/cpuinfo and other resources in /proc.

But which version of LXCFS does your LXD installation have?
If it is the snap (3.16), here is the command to check the version. If using the deb package, adapt the pathname accordingly.

/snap/lxd/current/bin/lxcfs --version

You are reporting that on LXD 2.0, the container sees only the number of CPUs that you have set in limits.cpus. I verify that the same happens in LXD 3.16, therefore this feature (viewing the number of cores in /proc/cpuinfo) has been supported since at least LXD 2.0.

Apparently, in the case of ArchLinux and the packaging of LXD, the lxcfs package is likely recommended (not required), hence the users should manually check that it gets installed.