[libvirt-users] virsh -c lxc:/// setvcpus and <vcpu> configuration fails

[info at layer7.net]

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 at 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.