<div dir="ltr"><div dir="ltr">Hi Sean,<div><br></div><div>I have tested cpu topology, numa and cpu soft pinning on one of my production compute node with AMD EPYC CPUs. It works perfectly fine.</div><div><br></div><div>Here is the xmldump.</div><div><br></div><div>  <memory unit='KiB'>33554432</memory><br>  <currentMemory unit='KiB'>33554432</currentMemory><br>  <vcpu placement='static'>32</vcpu><br>  <cputune><br>  Â  <shares>32768</shares><br>  Â  <vcpupin vcpu='0' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='1' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='2' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='3' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='4' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='5' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='6' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='7' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='8' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='9' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='10' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='11' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='12' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='13' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='14' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='15' cpuset='4-31,64-95'/><br>  Â  <vcpupin vcpu='16' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='17' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='18' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='19' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='20' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='21' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='22' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='23' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='24' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='25' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='26' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='27' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='28' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='29' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='30' cpuset='32-63,96-122'/><br>  Â  <vcpupin vcpu='31' cpuset='32-63,96-122'/><br>  Â  <emulatorpin cpuset='4-122'/><br>  </cputune><br>  <numatune><br>  Â  <memory mode='strict' nodeset='0-1'/><br>  Â  <memnode cellid='0' mode='strict' nodeset='0'/><br>  Â  <memnode cellid='1' mode='strict' nodeset='1'/><br>  </numatune><br> .........<br>  <cpu mode='custom' match='exact' check='full'><br>  Â  <model fallback='forbid'>EPYC-Rome</model><br>  Â  <vendor>AMD</vendor><br>  Â  <topology sockets='2' cores='8' threads='2'/><br>  Â  <feature policy='require' name='x2apic'/><br>  Â  <feature policy='require' name='tsc-deadline'/><br>  Â  <feature policy='require' name='hypervisor'/><br>  Â  <feature policy='require' name='tsc_adjust'/><br>  Â  <feature policy='require' name='spec-ctrl'/><br>  Â  <feature policy='require' name='stibp'/><br>  Â  <feature policy='require' name='arch-capabilities'/><br>  Â  <feature policy='require' name='ssbd'/><br>  Â  <feature policy='require' name='xsaves'/><br>  Â  <feature policy='require' name='cmp_legacy'/><br>  Â  <feature policy='require' name='ibrs'/><br>  Â  <feature policy='require' name='amd-ssbd'/><br>  Â  <feature policy='require' name='virt-ssbd'/><br>  Â  <feature policy='require' name='rdctl-no'/><br>  Â  <feature policy='require' name='skip-l1dfl-vmentry'/><br>  Â  <feature policy='require' name='mds-no'/><br>  Â  <feature policy='require' name='pschange-mc-no'/><br>  Â  <feature policy='require' name='topoext'/><br>  Â  <numa><br>  Â  Â  <cell id='0' cpus='0-15' memory='16777216' unit='KiB'/><br>  Â  Â  <cell id='1' cpus='16-31' memory='16777216' unit='KiB'/><br>  Â  </numa><br>  </cpu><br></div><div><br></div><div>One thing I have noticed is with enabling numa nova use cpu_mode custom while without numa node, nova use host-model. </div><div><br></div><div>Also I have enabled cpu soft pining it works also fine.</div><div><br></div><div>[compute]<br>cpu_shared_set = 4-122<br></div><div><br></div><div>I have kept 8 cores and 32GB RAM for OS and network. Will it be sufficient ?</div><div><br></div></div>Ammad<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 30, 2021 at 5:13 PM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2021-06-30 at 10:11 +0500, Ammad Syed wrote:<br>
>  Â  - Is there any isolation done at the Kernel level of the compute OS?<br>
> <br>
> No, There is no changes made in kernel.<br>
> <br>
>  Â  - What does your flavor look like right now? Is the behavior different<br>
>  Â  if you remove the numa constraint?<br>
> <br>
> My flavor has currently below specs set.<br>
> > dec2e31d-e1e8-4ff2-90d5-955be7e9efd3 | RC-16G  Â  Â  Â  Â | 16384 |  Â  5 |<br>
>  Â  Â  Â 0 |  Â  Â 8 | True  Â  Â  |  Â  0 |  Â  Â  Â  Â 1.0 | hw:cpu_cores='2',<br>
> hw:cpu_sockets='4'  Â  Â  Â  Â  Â  Â  |<br>
<br>
if these are the only extra you have added you have not enabled cpu pinning in the falvor<br>
> <br>
> But I have set cpu pinning in compute node.<br>
> [compute]<br>
> cpu_shared_set = 2-7,10-15,18-23,26-31<br>
> <br>
you do not enable cpu pinning in the compute node.<br>
you can configure cores to be used for cpu pinning using<br>
cpu_dedicated_set but vms will not use those cores unless you request them<br>
the cpu_shared_set is used for unpinned vms. it defines the range of cpus over which the vms can float<br>
<br>
more coments below<br>
> <br>
> If I remove hw:cpu_* from flavor and remove above config from nova.conf of<br>
> compute. Instance deployment works fine.<br>
> <br>
> You seem to have 4 NUMA as well, but only two physical sockets<br>
> (8CPUx2threads - 16 vCPUs per socket x 2 = 32)<br>
> <br>
> This is my test compute node have 4 cpu sockets and 4 numa nodes.<br>
> <br>
> root@kvm10-a1-khi01:~# numactl -H<br>
> available: 4 nodes (0-3)<br>
> node 0 cpus: 0 1 2 3 4 5 6 7<br>
> node 0 size: 31675 MB<br>
> node 0 free: 30135 MB<br>
> node 1 cpus: 8 9 10 11 12 13 14 15<br>
> node 1 size: 64510 MB<br>
> node 1 free: 63412 MB<br>
> node 2 cpus: 16 17 18 19 20 21 22 23<br>
> node 2 size: 64510 MB<br>
> node 2 free: 63255 MB<br>
> node 3 cpus: 24 25 26 27 28 29 30 31<br>
> node 3 size: 64485 MB<br>
> node 3 free: 63117 MB<br>
> node distances:<br>
> node  Â 0  Â 1  Â 2  Â 3<br>
>  Â 0:  10  16  16  16<br>
>  Â 1:  16  10  16  16<br>
>  Â 2:  16  16  10  16<br>
>  Â 3:  16  16  16  10<br>
> <br>
> The generated XML seems to be set for a 4 socket topology?<br>
> <br>
> Yes I am testing this on my test compute node first.<br>
> <br>
> On Wed, Jun 30, 2021 at 7:15 AM Laurent Dumont <<a href="mailto:laurentfdumont@gmail.com" target="_blank">laurentfdumont@gmail.com</a>><br>
> wrote:<br>
> <br>
> > <br>
> >  Â  - Is there any isolation done at the Kernel level of the compute OS?<br>
> >  Â  - What does your flavor look like right now? Is the behavior different<br>
> >  Â  if you remove the numa constraint?<br>
> > <br>
> > You seem to have 4 NUMA as well, but only two physical sockets<br>
> > (8CPUx2threads - 16 vCPUs per socket x 2 = 32)<br>
> > <br>
> > The generated XML seems to be set for a 4 socket topology?<br>
> > <br>
> >  <cpu mode='custom' match='exact' check='partial'><br>
> >  Â  Â <model fallback='allow'>Opteron_G5</model><br>
> >  Â  Â <topology sockets='4' cores='2' threads='1'/><br>
> >  Â </cpu><br>
> > <br>
> > On Tue, Jun 29, 2021 at 12:41 PM Ammad Syed <<a href="mailto:syedammad83@gmail.com" target="_blank">syedammad83@gmail.com</a>> wrote:<br>
> > <br>
> > > Hi Stephen,<br>
> > > <br>
> > > I have checked all cpus are online.<br>
> > > <br>
> > > root@kvm10-a1-khi01:/etc/nova# lscpu<br>
> > > Architecture:  Â  Â  Â  Â  Â  Â  Â  Â  Â  x86_64<br>
> > > CPU op-mode(s):  Â  Â  Â  Â  Â  Â  Â  Â  32-bit, 64-bit<br>
> > > Byte Order:  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Little Endian<br>
> > > Address sizes:  Â  Â  Â  Â  Â  Â  Â  Â  Â 48 bits physical, 48 bits virtual<br>
> > > CPU(s):  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  32<br>
> > > On-line CPU(s) list:  Â  Â  Â  Â  Â  Â 0-31<br>
> > > Thread(s) per core:  Â  Â  Â  Â  Â  Â  2<br>
> > > Core(s) per socket:  Â  Â  Â  Â  Â  Â  8<br>
> > > Socket(s):  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â 2<br>
> > > NUMA node(s):  Â  Â  Â  Â  Â  Â  Â  Â  Â  4<br>
> > > Vendor ID:  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â AuthenticAMD<br>
> > > CPU family:  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  21<br>
> > > <br>
> > > I have made below configuration in nova.conf.<br>
> > > <br>
> > > [compute]<br>
> > > <br>
> > > cpu_shared_set = 2-7,10-15,18-23,26-31<br>
> > > <br>
> > > Below is the xml in nova logs that nova is trying to create domain.<br>
> > > <br>
the xml below is for an unpinend guest and has no numa toplogy defiend.<br>
<br>
> > > 2021-06-29 16:30:56.576 2819 ERROR nova.virt.libvirt.guest<br>
> > > [req-c76c6809-1775-43a8-bfb1-70f6726cad9d 2af528fdf3244e15b4f3f8fcfc0889c5<br>
> > > 890eb2b7d1b8488aa88de7c34d08817a - default default] Error launching a<br>
> > > defined domain with XML: <domain type='kvm'><br>
> > >  Â <name>instance-0000026d</name><br>
> > >  Â <uuid>06ff4fd5-b21f-4f64-9dde-55e86dd15da6</uuid><br>
> > >  Â <metadata><br>
> > >  Â  Â <nova:instance xmlns:nova="<br>
> > > <a href="http://openstack.org/xmlns/libvirt/nova/1.1" rel="noreferrer" target="_blank">http://openstack.org/xmlns/libvirt/nova/1.1</a>"><br>
> > >  Â  Â  Â <nova:package version="23.0.0"/><br>
> > >  Â  Â  Â <nova:name>cpu</nova:name><br>
> > >  Â  Â  Â <nova:creationTime>2021-06-29 16:30:50</nova:creationTime><br>
> > >  Â  Â  Â <nova:flavor name="RC-16G"><br>
> > >  Â  Â  Â  Â <nova:memory>16384</nova:memory><br>
> > >  Â  Â  Â  Â <nova:disk>5</nova:disk><br>
> > >  Â  Â  Â  Â <nova:swap>0</nova:swap><br>
> > >  Â  Â  Â  Â <nova:ephemeral>0</nova:ephemeral><br>
> > >  Â  Â  Â  Â <nova:vcpus>8</nova:vcpus><br>
> > >  Â  Â  Â </nova:flavor><br>
> > >  Â  Â  Â <nova:owner><br>
> > >  Â  Â  Â  Â <nova:user<br>
> > > uuid="2af528fdf3244e15b4f3f8fcfc0889c5">admin</nova:user><br>
> > >  Â  Â  Â  Â <nova:project<br>
> > > uuid="890eb2b7d1b8488aa88de7c34d08817a">admin</nova:project><br>
> > >  Â  Â  Â </nova:owner><br>
> > >  Â  Â  Â <nova:root type="image"<br>
> > > uuid="1024317b-0db6-418c-bc39-de9b61d8ce59"/><br>
> > >  Â  Â  Â <nova:ports><br>
> > >  Â  Â  Â  Â <nova:port uuid="dccf68a2-ec48-4985-94ce-b3487cfc99f3"><br>
> > >  Â  Â  Â  Â  Â <nova:ip type="fixed" address="192.168.100.106" ipVersion="4"/><br>
> > >  Â  Â  Â  Â </nova:port><br>
> > >  Â  Â  Â </nova:ports><br>
> > >  Â  Â </nova:instance><br>
> > >  Â </metadata><br>
> > >  Â <memory unit='KiB'>16777216</memory><br>
> > >  Â <currentMemory unit='KiB'>16777216</currentMemory><br>
> > >  Â <vcpu placement='static' cpuset='2-7,10-15,18-23,26-31'>8</vcpu><br>
> > > <br>
here you can se we have copyied the cpu_share_set value into the set of cpus<br>
which this vm is allowed to float over. this will do soft pinning using cgroups but the<br>
guest cpu will still float over that range<br>
> > >  Â <cputune><br>
> > >  Â  Â <shares>8192</shares><br>
> > >  Â </cputune><br>
> > >  Â <sysinfo type='smbios'><br>
> > >  Â  Â <system><br>
> > >  Â  Â  Â <entry name='manufacturer'>OpenStack Foundation</entry><br>
> > >  Â  Â  Â <entry name='product'>OpenStack Nova</entry><br>
> > >  Â  Â  Â <entry name='version'>23.0.0</entry><br>
> > >  Â  Â  Â <entry name='serial'>06ff4fd5-b21f-4f64-9dde-55e86dd15da6</entry><br>
> > >  Â  Â  Â <entry name='uuid'>06ff4fd5-b21f-4f64-9dde-55e86dd15da6</entry><br>
> > >  Â  Â  Â <entry name='family'>Virtual Machine</entry><br>
> > >  Â  Â </system><br>
> > >  Â </sysinfo><br>
> > >  Â <os><br>
> > >  Â  Â <type arch='x86_64' machine='pc-i440fx-4.2'>hvm</type><br>
> > >  Â  Â <boot dev='hd'/><br>
> > >  Â  Â <smbios mode='sysinfo'/><br>
> > >  Â </os><br>
> > >  Â <features><br>
> > >  Â  Â <acpi/><br>
> > >  Â  Â <apic/><br>
> > >  Â </features><br>
> > >  Â <cpu mode='custom' match='exact' check='partial'><br>
> > >  Â  Â <model fallback='allow'>Opteron_G5</model><br>
> > >  Â  Â <topology sockets='4' cores='2' threads='1'/><br>
> > >  Â </cpu><br>
> > >  Â <clock offset='utc'><br>
> > >  Â  Â <timer name='pit' tickpolicy='delay'/><br>
> > >  Â  Â <timer name='rtc' tickpolicy='catchup'/><br>
> > >  Â  Â <timer name='hpet' present='no'/><br>
> > >  Â </clock><br>
> > >  Â <on_poweroff>destroy</on_poweroff><br>
> > >  Â <on_reboot>restart</on_reboot><br>
> > >  Â <on_crash>destroy</on_crash><br>
> > >  Â <devices><br>
> > >  Â  Â <emulator>/usr/bin/qemu-system-x86_64</emulator><br>
> > >  Â  Â <disk type='file' device='disk'><br>
> > >  Â  Â  Â <driver name='qemu' type='qcow2' cache='none'/><br>
> > >  Â  Â  Â <source<br>
> > > file='/var/lib/nova/instances/06ff4fd5-b21f-4f64-9dde-55e86dd15da6/disk'/><br>
> > >  Â  Â  Â <target dev='sda' bus='scsi'/><br>
> > >  Â  Â  Â <address type='drive' controller='0' bus='0' target='0' unit='0'/><br>
> > >  Â  Â </disk><br>
> > >  Â  Â <controller type='scsi' index='0' model='virtio-scsi'><br>
> > >  Â  Â  Â <address type='pci' domain='0x0000' bus='0x00' slot='0x04'<br>
> > > function='0x0'/><br>
> > >  Â  Â </controller><br>
> > >  Â  Â <controller type='usb' index='0' model='piix3-uhci'><br>
> > >  Â  Â  Â <address type='pci' domain='0x0000' bus='0x00' slot='0x01'<br>
> > > function='0x2'/><br>
> > >  Â  Â </controller><br>
> > >  Â  Â <controller type='pci' index='0' model='pci-root'/><br>
> > >  Â  Â <interface type='bridge'><br>
> > >  Â  Â  Â <mac address='fa:16:3e:f5:46:7d'/><br>
> > >  Â  Â  Â <source bridge='br-int'/><br>
> > >  Â  Â  Â <virtualport type='openvswitch'><br>
> > >  Â  Â  Â  Â <parameters interfaceid='dccf68a2-ec48-4985-94ce-b3487cfc99f3'/><br>
> > >  Â  Â  Â </virtualport><br>
> > >  Â  Â  Â <target dev='tapdccf68a2-ec'/><br>
> > >  Â  Â  Â <model type='virtio'/><br>
> > >  Â  Â  Â <driver name='vhost' queues='8'/><br>
> > >  Â  Â  Â <mtu size='1442'/><br>
> > >  Â  Â  Â <address type='pci' domain='0x0000' bus='0x00' slot='0x03'<br>
> > > function='0x0'/><br>
> > >  Â  Â </interface><br>
> > >  Â  Â <serial type='pty'><br>
> > >  Â  Â  Â <log<br>
> > > file='/var/lib/nova/instances/06ff4fd5-b21f-4f64-9dde-55e86dd15da6/console.log'<br>
> > > append='off'/><br>
> > >  Â  Â  Â <target type='isa-serial' port='0'><br>
> > >  Â  Â  Â  Â <model name='isa-serial'/><br>
> > >  Â  Â  Â </target><br>
> > >  Â  Â </serial><br>
> > >  Â  Â <console type='pty'><br>
> > >  Â  Â  Â <log<br>
> > > file='/var/lib/nova/instances/06ff4fd5-b21f-4f64-9dde-55e86dd15da6/console.log'<br>
> > > append='off'/><br>
> > >  Â  Â  Â <target type='serial' port='0'/><br>
> > >  Â  Â </console><br>
> > >  Â  Â <input type='tablet' bus='usb'><br>
> > >  Â  Â  Â <address type='usb' bus='0' port='1'/><br>
> > >  Â  Â </input><br>
> > >  Â  Â <input type='mouse' bus='ps2'/><br>
> > >  Â  Â <input type='keyboard' bus='ps2'/><br>
> > >  Â  Â <graphics type='spice' autoport='yes' listen='0.0.0.0'><br>
> > >  Â  Â  Â <listen type='address' address='0.0.0.0'/><br>
> > >  Â  Â </graphics><br>
> > >  Â  Â <video><br>
> > >  Â  Â  Â <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'<br>
> > > primary='yes'/><br>
> > >  Â  Â  Â <address type='pci' domain='0x0000' bus='0x00' slot='0x02'<br>
> > > function='0x0'/><br>
> > >  Â  Â </video><br>
> > >  Â  Â <memballoon model='virtio'><br>
> > >  Â  Â  Â <stats period='10'/><br>
> > >  Â  Â  Â <address type='pci' domain='0x0000' bus='0x00' slot='0x05'<br>
> > > function='0x0'/><br>
> > >  Â  Â </memballoon><br>
> > >  Â  Â <rng model='virtio'><br>
> > >  Â  Â  Â <backend model='random'>/dev/urandom</backend><br>
> > >  Â  Â  Â <address type='pci' domain='0x0000' bus='0x00' slot='0x06'<br>
> > > function='0x0'/><br>
> > >  Â  Â </rng><br>
> > >  Â </devices><br>
> > > </domain><br>
> > > : libvirt.libvirtError: Unable to write to<br>
> > > '/sys/fs/cgroup/cpuset/machine.slice/machine-qemu\x2d1\x2dinstance\x2d0000026d.scope/emulator/cpuset.cpus':<br>
> > > Permission denied<br>
this error indicates a issue wiht the set of cgroups that libvirt can use.<br>
its either a limisation of your kernel or you have alstered the default set of cgroups in your libvirt config.<br>
<br>
this is contoled by the following in /etc/libvirt/qemu.conf<br>
<br>
  Â # What cgroup controllers to make use of with QEMU guests<br>
  Â #<br>
  Â #  - 'cpu' - use for scheduler tunables<br>
  Â #  - 'devices' - use for device whitelisting<br>
  Â #  - 'memory' - use for memory tunables<br>
  Â #  - 'blkio' - use for block devices I/O tunables<br>
  Â #  - 'cpuset' - use for CPUs and memory nodes<br>
  Â #  - 'cpuacct' - use for CPUs statistics.<br>
  Â #<br>
  Â # NB, even if configured here, they won't be used unless<br>
  Â # the administrator has mounted cgroups, e.g.:<br>
  Â #<br>
  Â #  mkdir /dev/cgroup<br>
  Â #  mount -t cgroup -o devices,cpu,memory,blkio,cpuset none /dev/cgroup<br>
  Â #<br>
  Â # They can be mounted anywhere, and different controllers<br>
  Â # can be mounted in different locations. libvirt will detect<br>
  Â # where they are located.<br>
  Â #<br>
  Â #cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuset", "cpuacct" ]<br>
<br>
the libvirt default which are commented out should be correct. with out cpuset you cant use<br>
any form of cpu pinning. so you should confirm that cpuset is included in the cgroup mount point<br>
i.e. mount -t cgroup -o devices,cpu,memory,blkio,cpuset none /dev/cgroup<br>
<br>
<br>
<br>
> > > <br>
> > > Ammad<br>
> > > <br>
> > > On Tue, Jun 29, 2021 at 8:29 PM Stephen Finucane <<a href="mailto:stephenfin@redhat.com" target="_blank">stephenfin@redhat.com</a>><br>
> > > wrote:<br>
> > > <br>
> > > > On Tue, 2021-06-29 at 17:44 +0500, Ammad Syed wrote:<br>
> > > > > Thanks,, the information is really helpful. I am have set below<br>
> > > > properties to<br>
> > > > > flavor according to my numa policies.<br>
> > > > > <br>
> > > > >  Â  Â --property hw:numa_nodes=FLAVOR-NODES \<br>
> > > > >  Â  Â --property hw:numa_cpus.N=FLAVOR-CORES \<br>
> > > > >  Â  Â --property hw:numa_mem.N=FLAVOR-MEMORY<br>
you should only ever use  hw:numa_cpus.N and hw:numa_mem.N iif you have an unblanced numa toplogy in the guest and 2+ numa nodes.<br>
where in is the numa node index starting form 0. if you are using them and you do not have a deep understaing of how that alters the vm xml generation<br>
and asignment to the host and you have not messured the performace the its almost alwasy a mistake to specify hw:numa_cpus or hw:numa_mem.<br>
<br>
<br>
> > > > > <br>
> > > > > I am having below error in compute logs. Any advise.<br>
> > > > > <br>
> > > > >  libvirt.libvirtError: Unable to write to<br>
> > > > > '/sys/fs/cgroup/cpuset/machine.slice/machine-<br>
> > > > > qemu\x2d48\x2dinstance\x2d0000026b.scope/emulator/cpuset.cpus':<br>
> > > > Permission<br>
> > > > > denied<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > Traceback (most<br>
> > > > > recent call last):<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py", line 155,<br>
> > > > in launch<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > return<br>
> > > > > self._domain.createWithFlags(flags)<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 193, in doit<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > result =<br>
> > > > > proxy_call(self._autowrap, f, *args, **kwargs)<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 151, in<br>
> > > > proxy_call<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â  Â rv =<br>
> > > > > execute(f, *args, **kwargs)<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 132, in<br>
> > > > execute<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > six.reraise(c,<br>
> > > > > e, tb)<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/six.py", line 703, in reraise<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > raise value<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/eventlet/tpool.py", line 86, in tworker<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â  Â rv =<br>
> > > > > meth(*args, **kwargs)<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â File<br>
> > > > > "/usr/lib/python3/dist-packages/libvirt.py", line 1265, in<br>
> > > > createWithFlags<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest  Â  Â if<br>
> > > > ret == -1:<br>
> > > > > raise libvirtError ('virDomainCreateWithFlags() failed', dom=self)<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > > libvirt.libvirtError: Unable to write to<br>
> > > > > '/sys/fs/cgroup/cpuset/machine.slice/machine-<br>
> > > > > qemu\x2d48\x2dinstance\x2d0000026b.scope/emulator/cpuset.cpus':<br>
> > > > Permission<br>
> > > > > denied<br>
> > > > > 2021-06-29 12:33:10.144 1310945 ERROR nova.virt.libvirt.guest<br>
> > > > > 2021-06-29 12:33:10.146 1310945 ERROR nova.virt.libvirt.driver<br>
> > > > [req-4f6fc6aa-<br>
> > > > > 04d6-4dc0-921f-2913b40a76a9 2af528fdf3244e15b4f3f8fcfc0889c5<br>
> > > > > 890eb2b7d1b8488aa88de7c34d08817a - default default] [instance:<br>
> > > > ed87bf68-b631-<br>
> > > > > 4a00-9eb5-22d32ec37402] Failed to start libvirt guest:<br>
> > > > libvirt.libvirtError:<br>
> > > > > Unable to write to '/sys/fs/cgroup/cpuset/machine.slice/machine-<br>
> > > > > qemu\x2d48\x2dinstance\x2d0000026b.scope/emulator/cpuset.cpus':<br>
> > > > Permission<br>
> > > > > denied<br>
> > > > > 2021-06-29 12:33:10.150 1310945 INFO os_vif<br>
> > > > [req-4f6fc6aa-04d6-4dc0-921f-<br>
> > > > > 2913b40a76a9 2af528fdf3244e15b4f3f8fcfc0889c5<br>
> > > > 890eb2b7d1b8488aa88de7c34d08817a -<br>
> > > > > default default] Successfully unplugged vif<br>
> > > > > VIFOpenVSwitch(active=False,address=fa:16:3e:ba:3d:c8,bridge_name='br-<br>
> > > > > int',has_traffic_filtering=True,id=a991cd33-2610-4823-a471-<br>
> > > > > 62171037e1b5,network=Network(a0d85af2-a991-4102-8453-<br>
> > > > > <br>
> > > > ba68c5e10b65),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_de<br>
> > > > > lete=False,vif_name='tapa991cd33-26')<br>
> > > > > 2021-06-29 12:33:10.151 1310945 INFO nova.virt.libvirt.driver<br>
> > > > [req-4f6fc6aa-<br>
> > > > > 04d6-4dc0-921f-2913b40a76a9 2af528fdf3244e15b4f3f8fcfc0889c5<br>
> > > > > 890eb2b7d1b8488aa88de7c34d08817a - default default] [instance:<br>
> > > > ed87bf68-b631-<br>
> > > > > 4a00-9eb5-22d32ec37402] Deleting instance files<br>
> > > > > /var/lib/nova/instances/ed87bf68-b631-4a00-9eb5-22d32ec37402_del<br>
> > > > > 2021-06-29 12:33:10.152 1310945 INFO nova.virt.libvirt.driver<br>
> > > > [req-4f6fc6aa-<br>
> > > > > 04d6-4dc0-921f-2913b40a76a9 2af528fdf3244e15b4f3f8fcfc0889c5<br>
> > > > > 890eb2b7d1b8488aa88de7c34d08817a - default default] [instance:<br>
> > > > ed87bf68-b631-<br>
> > > > > 4a00-9eb5-22d32ec37402] Deletion of<br>
> > > > /var/lib/nova/instances/ed87bf68-b631-4a00-<br>
> > > > > 9eb5-22d32ec37402_del complete<br>
> > > > > 2021-06-29 12:33:10.258 1310945 ERROR nova.compute.manager<br>
> > > > [req-4f6fc6aa-04d6-<br>
> > > > > 4dc0-921f-2913b40a76a9 2af528fdf3244e15b4f3f8fcfc0889c5<br>
> > > > > 890eb2b7d1b8488aa88de7c34d08817a - default default] [instance:<br>
> > > > ed87bf68-b631-<br>
> > > > > 4a00-9eb5-22d32ec37402] Instance failed to spawn:<br>
> > > > libvirt.libvirtError: Unable<br>
> > > > > to write to '/sys/fs/cgroup/cpuset/machine.slice/machine-<br>
> > > > > qemu\x2d48\x2dinstance\x2d0000026b.scope/emulator/cpuset.cpus':<br>
> > > > Permission<br>
> > > > > denied<br>
> > > > > <br>
> > > > > Any advise how to fix this permission issue ?<br>
> > > > > <br>
> > > > > I have manually created the directory machine-qemu in<br>
> > > > > /sys/fs/cgroup/cpuset/machine.slice/ but still having the same error.<br>
> > > > > <br>
> > > > > I have also tried to set [compute] cpu_shared_set AND [compute]<br>
> > > > > cpu_dedicated_set  they are also giving the same error.<br>
> > > > <br>
> > > > There are quite a few bugs about this [1][2]. It seems most of them are<br>
> > > > caused<br>
> > > > by CPUs being offlined. Have you offline CPUs? Are the CPUs listed in<br>
> > > > the mask<br>
> > > > all available?<br>
> > > > <br>
> > > > Stephen<br>
> > > > <br>
> > > > [1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1609785" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1609785</a><br>
> > > > [2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1842716" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1842716</a><br>
> > > > <br>
> > > > > Using ubuntu20.04 and qemu-kvm 4.2.<br>
> > > > > <br>
> > > > > Ammad<br>
> > > > > <br>
> > > > > On Fri, Jun 25, 2021 at 10:54 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>><br>
> > > > wrote:<br>
> > > > > > On Fri, 2021-06-25 at 10:02 +0500, Ammad Syed wrote:<br>
> > > > > > > Hi,<br>
> > > > > > > <br>
> > > > > > > I am using openstack wallaby on ubuntu 20.04 and kvm. I am working<br>
> > > > to make<br>
> > > > > > > optimized flavor properties that should provide optimal<br>
> > > > performance. I was<br>
> > > > > > > reviewing the document below.<br>
> > > > > > > <br>
> > > > > > > <a href="https://docs.openstack.org/nova/wallaby/admin/cpu-topologies.html" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/wallaby/admin/cpu-topologies.html</a><br>
> > > > > > > <br>
> > > > > > > I have two socket AMD compute node. The workload running on nodes<br>
> > > > are mixed<br>
> > > > > > > workload.<br>
> > > > > > > <br>
> > > > > > > My question is should I use default nova CPU topology and NUMA<br>
> > > > node that<br>
> > > > > > > nova deploys instance by default OR should I use hw:cpu_sockets='2'<br>
> > > > > > > and hw:numa_nodes='2'.<br>
> > > > > > the latter hw:cpu_sockets='2' and hw:numa_nodes='2' should give you<br>
> > > > better<br>
> > > > > > performce<br>
> > > > > > however you should also set hw:mem_page_size=small or<br>
> > > > hw:mem_page_size=any<br>
> > > > > > when you enable virtual numa policies we afinities the guest memory<br>
> > > > to host<br>
> > > > > > numa nodes.<br>
> > > > > > This can lead to Out of memory evnet on the the host numa nodes<br>
> > > > which can<br>
> > > > > > result in vms<br>
> > > > > > being killed by the host kernel memeory reaper if you do not enable<br>
> > > > numa aware<br>
> > > > > > memeory<br>
> > > > > > trackign iin nova which is done by setting hw:mem_page_size. setting<br>
> > > > > > hw:mem_page_size has<br>
> > > > > > the side effect of of disabling memory over commit so you have to<br>
> > > > bare that in<br>
> > > > > > mind.<br>
> > > > > > if you are using numa toplogy you should almost always also use<br>
> > > > hugepages<br>
> > > > > > which are enabled<br>
> > > > > > using  hw:mem_page_size=large this however requires you to configure<br>
> > > > > > hupgepages in the host<br>
> > > > > > at boot.<br>
> > > > > > > <br>
> > > > > > > Which one from above provide best instance performance ? or any<br>
> > > > other<br>
> > > > > > > tuning should I do ?<br>
> > > > > > <br>
> > > > > > in the libvirt driver the default cpu toplogy we will genergated<br>
> > > > > > is 1 thread per core, 1 core per socket and 1 socket per flavor.vcpu.<br>
> > > > > > (technially this is an undocumeted implemation detail that you<br>
> > > > should not rely<br>
> > > > > > on, we have the hw:cpu_* element if you care about the toplogy)<br>
> > > > > > <br>
> > > > > > this was more effincet in the early days of qemu/openstack but has<br>
> > > > may issue<br>
> > > > > > when software is chagne per sokcet or oepreating systems have<br>
> > > > > > a limit on socket supported such as windows.<br>
> > > > > > <br>
> > > > > > generally i advies that you set hw:cpu_sockets to the typical number<br>
> > > > of<br>
> > > > > > sockets on the underlying host.<br>
> > > > > > simialrly if the flavor will only be run on host with<br>
> > > > SMT/hypertreading<br>
> > > > > > enabled on you shoudl set hw:cpu_threads=2<br>
> > > > > > <br>
> > > > > > the flavor.vcpus must be devisable by the product of hw:cpu_sockets,<br>
> > > > > > hw:cpu_cores and hw:cpu_threads if they are set.<br>
> > > > > > <br>
> > > > > > so if you have  hw:cpu_threads=2 it must be devisable by 2<br>
> > > > > > if you have  hw:cpu_threads=2 and hw:cpu_sockets=2 flavor.vcpus must<br>
> > > > be a<br>
> > > > > > multiple of 4<br>
> > > > > > > <br>
> > > > > > > The note in the URL (CPU topology sesion) suggests that I should<br>
> > > > stay with<br>
> > > > > > > default options that nova provides.<br>
> > > > > > in generaly no you should aling it to the host toplogy if you have<br>
> > > > similar<br>
> > > > > > toplogy across your data center.<br>
> > > > > > the default should always just work but its not nessisarly optimal<br>
> > > > and window<br>
> > > > > > sguest might not boot if you have too many sockets.<br>
> > > > > > windows 10 for exmple only supprot 2 socket so you could only have 2<br>
> > > > > > flavor.vcpus if you used the default toplogy.<br>
> > > > > > <br>
> > > > > > > <br>
> > > > > > > Currently it also works with libvirt/QEMU driver but we don’t<br>
> > > > recommend it<br>
> > > > > > > in production use cases. This is because vCPUs are actually<br>
> > > > running in one<br>
> > > > > > > thread on host in qemu TCG (Tiny Code Generator), which is the<br>
> > > > backend for<br>
> > > > > > > libvirt/QEMU driver. Work to enable full multi-threading support<br>
> > > > for TCG<br>
> > > > > > > (a.k.a. MTTCG) is on going in QEMU community. Please see this<br>
> > > > MTTCG project<br>
> > > > > > > <<a href="http://wiki.qemu.org/Features/tcg-multithread" rel="noreferrer" target="_blank">http://wiki.qemu.org/Features/tcg-multithread</a>> page for detail.<br>
> > > > > > we do not gnerally recommende using qemu without kvm in produciton.<br>
> > > > > > the mttcg backend is useful in cases where you want to emulate other<br>
> > > > plathform<br>
> > > > > > but that usecsae<br>
> > > > > > is not currently supported in nova.<br>
> > > > > > for your deployment you should use libvirt with kvm and you should<br>
> > > > also<br>
> > > > > > consider if you want to support<br>
> > > > > > nested virtualisation or not.<br>
> > > > > > > <br>
> > > > > > > <br>
> > > > > > > Ammad<br>
> > > > > > <br>
> > > > > > <br>
> > > > > <br>
> > > > > <br>
> > > > <br>
> > > > <br>
> > > > <br>
> > > <br>
> > > --<br>
> > > Regards,<br>
> > > <br>
> > > <br>
> > > Syed Ammad Ali<br>
> > > <br>
> > <br>
> <br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Regards,<div><br></div><div><br></div><div>Syed Ammad Ali</div></div></div>