4:53 p.m.
Hi,
ok i tried:
<vcpu placement='static'>2</vcpu>
<iothreads>2</iothreads>
<iothreadids>
<iothread id='1'/>
<iothread id='2'/>
</iothreadids>
<cputune>
<vcpupin vcpu='0' cpuset='0'/>
<vcpupin vcpu='1' cpuset='1'/>
<emulatorpin cpuset='0-1'/>
<iothreadpin iothread='1' cpuset='0'/>
<iothreadpin iothread='2' cpuset='1'/>
</cputune>
aswell as
<vcpu placement='static' cpuset='0-1'
current='2'>4</vcpu>
and, it shows in the cpuset cgroup:
#cat cpuset.cpus
0-1
# cat cpuset.effective_cpus
0-1
And yes, the CPU power is reduced to two cores.
But still, /proc/cpuinfo will show _all_ cpu cores of the hostmachine.
Also the total cpu usage / load, if queried, will be the cpu usage /
load of the hostmachine.
That confuse the applications as they monitor the cpu load/count and try
to balance out things.
Is there really no way to tell libvirt to create the cgroups in a way to
just show X cpu's to the system ?
When i run purely lxc or lxd, its no problem. But i would like to handle
things through libvirt because also the qemu-kvm stuff is handled
through libvirt.
Any ideas ? I also take dark hacking stuff :)
Greetings
Oliver
Am 16.09.19 um 10:58 schrieb Martin Kletzander:
On Sun, Sep 15, 2019 at 12:21:08PM +0200, info(a)layer7.net wrote:
> Hi folks!
>
> i created a server with this XML file:
>
> <domain type='lxc'>
> <name>lxctest1</name>
> <uuid>227bd347-dd1d-4bfd-81e1-01052e91ffe2</uuid>
> <metadata>
> <libosinfo:libosinfo
> xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0"...
> <libosinfo:os id="http://centos.org/centos/6.9"/>
> </libosinfo:libosinfo>
> </metadata>
> <memory unit='KiB'>1024000</memory>
> <currentMemory unit='KiB'>1024000</currentMemory>
> <vcpu>2</vcpu>
> <numatune>
> <memory mode='strict' placement='auto'/>
> </numatune>
> <resource>
> <partition>/machine</partition>
> </resource>
> <os>
> <type arch='x86_64'>exe</type>
> <init>/sbin/init</init>
> </os>
> <idmap>
> <uid start='0' target='200000' count='65535'/>
> <gid start='0' target='200000' count='65535'/>
> </idmap>
> <features>
> <privnet/>
> </features>
> <clock offset='utc'/>
> <on_poweroff>destroy</on_poweroff>
> <on_reboot>restart</on_reboot>
> <on_crash>destroy</on_crash>
> <devices>
> <emulator>/usr/libexec/libvirt_lxc</emulator>
> <filesystem type='mount' accessmode='mapped'>
> <source dir='/mnt'/>
> <target dir='/'/>
> </filesystem>
> <interface type='network'>
> <mac address='00:16:3e:3e:3e:bb'/>
> <source network='Public Network'/>
> </interface>
> <console type='pty'>
> <target type='lxc' port='0'/>
> </console>
> </devices>
> </domain>
>
>
> I would expect it to have 2 cpu cores and 1 GB RAM.
>
>
> The RAM config works.
> The CPU config does not:
>
You probably checked /proc/meminfo. That is provided by libvirt using fuse
filesystem, but at least it is guaranteed thanks to cgroups. We do not
(and I
don't think we even can, at least reliably) do that with cpuinfo.
[...]
> It gives me all CPU's from the host.
>
Although if you ran some perf benchmark it should just cap at 2 cpus.
> I also tried it with
>
> <cpu>
> <topology sockets='1' cores='2' threads='1'/>
> </cpu>
>
We should not allow this, IMO. The reason is that we cannot guarantee
or even
emulate this (or even the number of CPUs for that matter). That's not how
containers work. We can provide /proc/cpuinfo through a fuse
filesystem, but if
the code actually asks the cpu directly there is no layer in which to
emulate
the returned information.
> That didnt help too.
>
> I tried to modify the vcpus through virsh:
>
>
>
> #virsh -c lxc:/// setvcpus lxctest1 2
>
> error: this function is not supported by the connection driver:
> virDomainSetVcpus
>
This should not work for LXC, but it does not make sence because if you
look at
the XML we allow `<vcpus>2</vcpus>`.
> Which didnt work too.
>
>
> This happens on:
>
Unfortunately anywhere, for the reasons said above. Ideally it should
not be
able to specify <vcpus/>, but rather just <cputune/>, but I don't think
we can
change that semantics now that we supported the former for quite some time.