[ovirt-users] Feature: Maximum memory size | BUG
Hallo, after engine update to 4.1.2 from 4.0.6 we have following bug
*Your Future Description: *
Maximum memory value is stored in |VmBase.maxMemorySizeMb| property. It
is validated against range [/memory of VM/, /*MaxMemorySizeInMB/], where
/*MaxMemorySizeInMB/ is one of |VM32BitMaxMemorySizeInMB|,
|VM64BitMaxMemorySizeInMB| and |VMPpc64BitMaxMemorySizeInMB|
configuration options depending on selected operating system of the VM.
Default value in webadmin UI is 4x size of memory.
During migration of engine 4.0 -> 4.1 all VM-like entities will get max
memory = 4x memory.
If a VM (or template) is imported (from export domain, snapshot,
external system) and doesn't have max memory set yet, the maximum value
of max memory is set (|*MaxMemorySizeInMB| config options).
*Our engine settings:*
[root@ovirt]# engine-config -g VM64BitMaxMemorySizeInMB
VM64BitMaxMemorySizeInMB: 8388608 version: 4.1
VM64BitMaxMemorySizeInMB: 8388608 version: 3.6
VM64BitMaxMemorySizeInMB: 8388608 version: 4.0
[root@ovirt# engine-config -g VM32BitMaxMemorySizeInMB
VM32BitMaxMemorySizeInMB: 20480 version: general
*Template:
*engine=# select vm_guid,vm_name,mem_size_mb,max_memory_size_mb from
vm_static where vm_name LIKE 'Blank';
vm_guid | vm_name | mem_size_mb |
max_memory_size_mb
--------------------------------------+---------+-------------+--------------------
00000000-0000-0000-0000-000000000000 | Blank | 8192
| 32768
(1 row)
*Created VM*
- expected is mem_size_mb * VM64BitMaxMemorySizeInMB
- we get mem_size_mb * 4 (default)
*Engine: *engine=# select vm_guid,vm_name,mem_size_mb,max_memory_size_mb
from vm_static where vm_name LIKE 'vm-hotplug%';
vm_guid | vm_name | mem_size_mb |
max_memory_size_mb
--------------------------------------+-------------+-------------+--------------------
254a0c61-3c0a-41e7-a2ec-5f77cabbe533 | vm-hotplug | 1024
| 4096
c0794a03-58ba-4e68-8f43-e0320032830c | vm-hotplug2 | 3072
| 12288
(2 rows)
*Question:*
It is possible to change this (default * 4) behavior in DB??
Kind Regards,
Ladislav Humenik, System administrator