[ovirt-users] Feature: Maximum memory size | BUG
Jakub Niedermertl
jniederm at redhat.com
Wed Jul 26 17:01:53 UTC 2017
yes, max memory size is customizabe even for Blank template
On Wed, Jul 26, 2017 at 4:32 PM, Ladislav Humenik <ladislav.humenik at 1und1.de
> wrote:
> Hello, thank you for fast response.
>
> The point of changing the max_mem_size is little tricky, as we have
> environments with together ~13k VMs running on top of ovirt, no kidding :)
> and currently doing upgrades from 3.6 > 4.1. So we can easy set those
> values to the needed ones for every VM, thats not a big deal.
>
> However, I was just hoping it is editable without changing/modifying our
> current API calls, for any newly created VM (as this is the reason for
> asking for help), somewhere in engine-config or in DB.
>
> I'll just opened an RFE https://bugzilla.redhat.com/
> show_bug.cgi?id=1475382
>
> Best regards,
> Ladislav Humenik
>
>
> On 26.07.2017 15:58, Michal Skrivanek wrote:
>
>
> On 26 Jul 2017, at 16:50, Jakub Niedermertl <jniederm at redhat.com> wrote:
>
> Hello Ladislav,
>
> the function computing size of default maximum memory size is currently
> not configurable from DB.
>
> If you want it to be so please feel free to file an RFE [1].
>
> [1]: https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-engine
>
> Best regards,
> Jakub
>
> On Wed, Jul 26, 2017 at 1:59 PM, Ladislav Humenik <
> ladislav.humenik at 1und1.de> wrote:
>
>> 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 at ovirt]# engine-config -g VM64BitMaxMemorySizeInMB
>> VM64BitMaxMemorySizeInMB: 8388608 version: 4.1
>> VM64BitMaxMemorySizeInMB: 8388608 version: 3.6
>> VM64BitMaxMemorySizeInMB: 8388608 version: 4.0
>> [root at 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??
>>
>
> if the issue is with GUI then setting the max memory in the template would
> be inherited to all VMs from that template, you can even change that in
> “Blank” I think, Jakube?
> That’s for the default case, you can change that any way you like for the
> concrete VM you’re creating.
> if the issue is with API you can simply provide any number for the max mem
> in all the requests
>
> the VM[64|32]BitMaxMemorySizeInMB values are for the total maximum the
> particular qemu we ship supports, it’s not anything you should need to
> change.
>
> Thanks,
> michal
>
>
>> Kind Regards,
>> Ladislav Humenik, System administrator
>>
>>
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
> --
> Ladislav Humenik
>
> System administrator / VI
> IT Operations Hosting Infrastructure
>
> 1&1 Internet SE | Ernst-Frey-Str. 5 | 76135 Karlsruhe | Germany
> Phone: +49 721 91374-8361 <+49%20721%20913748361>
> E-Mail: ladislav.humenik at 1und1.de | Web: www.1und1.de
>
> Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
>
> Vorstand: Robert Hoffmann, Hans-Henning Kettler, Uwe Lamnek, Matthias Steinberg
> Aufsichtsratsvorsitzender: René Obermann
>
>
> Member of United Internet
>
> Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
>
> This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170726/eb3b6e8f/attachment.html>
More information about the Users
mailing list