Bug 1294462 - Possible to create and run vm, that has NUMA nodes total memory less than vm memory parameter
Summary: Possible to create and run vm, that has NUMA nodes total memory less than vm ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core
Version: 3.6.2.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: meital avital
URL:
Whiteboard: sla
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-28 10:15 UTC by Artyom
Modified: 2016-01-24 09:24 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-01-24 09:24:57 UTC
oVirt Team: SLA
Embargoed:
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description Artyom 2015-12-28 10:15:59 UTC
Description of problem:
Possible to create and run vm, that has NUMA nodes total memory less than vm memory parameter

Version-Release number of selected component (if applicable):
rhevm-3.6.2-0.1.el6.noarch

How reproducible:
Always

Steps to Reproduce:
1. Add new vm with 1Gb of memory and 2 cpu's
2. Pin it to host with NUMA support
3. Add via REST to vm two NUMA nodes one with 300Mb and second with 200Mb of memory
4. Start vm

Actual results:
Succeed to start vm, that has NUMA nodes total memory less than vm memory parameter

Expected results:
Engine must restrict start of vm, with correct error message

Additional info:
add two numa nodes to vm via REST
first numa node
<vm_numa>
<index>0</index>
<memory>300</memory>
<cpu>
 <cores>
<core index="0" />
 </cores>
</cpu>
 </vm_numa_node>

second numa node
<vm_numa_node>
<index>0</index>
<memory>200</memory>
<cpu>
 <cores>
<core index="1" />
 </cores>
</cpu>
 </vm_numa_node>


guest os also show really strange values for memory and numa architecture:
# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.2 (Maipo)
# uname -r
3.10.0-327.el7.x86_64
# free
              total        used        free      shared  buff/cache   available
Mem:         486308       82700      228780        4456      174828      359216
Swap:       4722684           0     4722684
# numactl -H (no return at all)

vm dumpxml(I can see that vm memory less, than it defined under engine)
# virsh -r dumpxml test_numa
<domain type='kvm' id='3'>
  <name>test_numa</name>
  <uuid>c7ecd2dc-dbd3-4419-956f-1249651c0f2b</uuid>
  <metadata xmlns:ovirt="http://ovirt.org/vm/tune/1.0">
    <ovirt:qos/>
  </metadata>
  <maxMemory slots='16' unit='KiB'>4294967296</maxMemory>
  <memory unit='KiB'>512000</memory>
  <currentMemory unit='KiB'>512000</currentMemory>
  <vcpu placement='static' current='4'>16</vcpu>
  <cputune>
    <shares>1020</shares>
  </cputune>
  <numatune>
    <memory mode='strict' nodeset='0,2'/>
  </numatune>
  <resource>
    <partition>/machine</partition>
  </resource>
  <sysinfo type='smbios'>
    <system>
      <entry name='manufacturer'>Red Hat</entry>
      <entry name='product'>RHEV Hypervisor</entry>
      <entry name='version'>7.2-9.el7_2.1</entry>
      <entry name='serial'>44dc37aa-e915-4cc5-b7b6-014b1792bac2</entry>
      <entry name='uuid'>c7ecd2dc-dbd3-4419-956f-1249651c0f2b</entry>
    </system>
  </sysinfo>
  <os>
    <type arch='x86_64' machine='pc-i440fx-rhel7.2.0'>hvm</type>
    <smbios mode='sysinfo'/>
  </os>
  <features>
    <acpi/>
  </features>
  <cpu mode='custom' match='exact'>
    <model fallback='allow'>Opteron_G1</model>
    <topology sockets='16' cores='1' threads='1'/>
    <numa>
      <cell id='0' cpus='0' memory='307200' unit='KiB'/>
      <cell id='1' cpus='1' memory='204800' unit='KiB'/>
    </numa>
  </cpu>
  <clock offset='variable' adjustment='0' basis='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source startupPolicy='optional'/>
      <backingStore/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <serial></serial>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <disk type='file' device='disk' snapshot='no'>
      <driver name='qemu' type='raw' cache='none' error_policy='stop' io='threads'/>
      <source file='/rhev/data-center/fb4bf070-5abb-4c4c-a73c-cd8289127dd0/6f70ac8e-55a6-40a6-af41-ecf756ff7444/images/d19ced30-f8ee-49d3-b563-af2c34e7365c/05386778-6fb4-488b-b907-3bba605098ee'>
        <seclabel model='selinux' labelskip='yes'/>
      </source>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <serial>d19ced30-f8ee-49d3-b563-af2c34e7365c</serial>
      <boot order='1'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
    <controller type='scsi' index='0' model='virtio-scsi'>
      <alias name='scsi0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <controller type='virtio-serial' index='0' ports='16'>
      <alias name='virtio-serial0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </controller>
    <controller type='usb' index='0'>
      <alias name='usb'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'>
      <alias name='pci.0'/>
    </controller>
    <controller type='ide' index='0'>
      <alias name='ide'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='bridge'>
      <mac address='00:1a:4a:16:01:52'/>
      <source bridge='ovirtmgmt'/>
      <target dev='vnet0'/>
      <model type='virtio'/>
      <filterref filter='vdsm-no-mac-spoofing'/>
      <link state='up'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channels/c7ecd2dc-dbd3-4419-956f-1249651c0f2b.com.redhat.rhevm.vdsm'/>
      <target type='virtio' name='com.redhat.rhevm.vdsm' state='disconnected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channels/c7ecd2dc-dbd3-4419-956f-1249651c0f2b.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0' state='disconnected'/>
      <alias name='channel2'/>
      <address type='virtio-serial' controller='0' bus='0' port='3'/>
    </channel>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' port='5900' tlsPort='5901' autoport='yes' listen='10.35.117.28' passwdValidTo='2015-12-28T10:11:23' connected='disconnect'>
      <listen type='network' address='10.35.117.28' network='vdsm-ovirtmgmt'/>
    </graphics>
    <video>
      <model type='qxl' ram='65536' vram='32768' vgamem='16384' heads='1'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='none'>
      <alias name='balloon0'/>
    </memballoon>
  </devices>
  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>system_u:system_r:svirt_t:s0:c774,c881</label>
    <imagelabel>system_u:object_r:svirt_image_t:s0:c774,c881</imagelabel>
  </seclabel>
</domain>

Comment 1 Doron Fediuck 2016-01-24 09:24:57 UTC
This is the correct behavior.
You may still create additional nodes in the future and the VM should succeed to run. The strange values come from auto-assignment of libvirt to the memory.


Note You need to log in before you can comment on or make changes to this bug.