[ovirt-devel] Memory size (1024MB) cannot exceed maximum memory size (0MB).] - when trying to create an instance type
Arik Hadas
ahadas at redhat.com
Mon Dec 25 19:25:34 UTC 2017
On Mon, Dec 25, 2017 at 8:29 PM, Michal Skrivanek <
michal.skrivanek at redhat.com> wrote:
>
>
> > On 25 Dec 2017, at 18:41, Juan Hernández <jhernand at redhat.com> wrote:
> >
> > On 12/25/2017 05:46 PM, Yaniv Kaul wrote:
> >> While trying to add an instance type, I fail with the error:
> >> Operation Failed". Fault detail is "[Cannot add Template. Memory size
> >> (1024MB) cannot exceed maximum memory size (0MB).]
> >> The code is taken from the example in the SDK, so I'm not sure what I'm
> >> doing wrong here.
> >> Code:
> >> instance_types_service.add(
> >> types.InstanceType(
> >> name='myinstancetype',
> >> description='My instance type',
> >> memory=1 * 2**30,
> >> high_availability=types.HighAvailability(
> >> enabled=True,
> >> ),
> >> cpu=types.Cpu(
> >> topology=types.CpuTopology(
> >> cores=2,
> >> sockets=2,
> >> ),
> >> ),
> >> ),
> >> )
> >> engine.log:
> >> 2017-12-25 10:58:19,825-05 INFO
> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13)
> >> [265ff704-d89f-471b-8207-fc0e1b8816fd] Lock Acquired to object
> >> 'EngineLock:{exclusiveLocks='[myinstancetype=TEMPLATE_NAME,
> >> 703e1265-e160-4a76-82e6-06974156b7b9=TEMPLATE]', sharedLocks='[]'}'
> >> 2017-12-25 10:58:19,831-05 WARN
> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13)
> >> [265ff704-d89f-471b-8207-fc0e1b8816fd] Validation of action
> 'AddVmTemplate'
> >> failed for user admin at internal-authz. Reasons:
> >> VAR__ACTION__ADD,VAR__TYPE__VM_TEMPLATE,ACTION_TYPE_
> FAILED_MAX_MEMORY_CANNOT_BE_SMALLER_THAN_MEMORY_SIZE,$maxMemory
> >> 0,$memory 1024
> >> 2017-12-25 10:58:19,832-05 INFO
> >> [org.ovirt.engine.core.bll.AddVmTemplateCommand] (default task-13)
> >> [265ff704-d89f-471b-8207-fc0e1b8816fd] Lock freed to object
> >> 'EngineLock:{exclusiveLocks='[myinstancetype=TEMPLATE_NAME,
> >> 703e1265-e160-4a76-82e6-06974156b7b9=TEMPLATE]', sharedLocks='[]'}'
> >> 2017-12-25 10:58:19,839-05 DEBUG
> >> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
> >> (default task-13) [265ff704-d89f-471b-8207-fc0e1b8816fd] method:
> runAction,
> >> params: [AddVmTemplate,
> >> AddVmTemplateParameters:{commandId='179df9ed-209c-4882-
> a19a-b76a4fe1adb8',
> >> user='null', commandType='Unknown'}], timeElapsed: 33ms
> >> 2017-12-25 10:58:19,846-05 ERROR
> >> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource]
> (default
> >> task-13) [] Operation Failed: [Cannot add Template. Memory size (1024MB)
> >> cannot exceed maximum memory size (0MB).]
> >> TIA,
> >> Y.
> >
> > I think this is related to the new `memory_policy.max` attribute that
> was introduced in 4.1. I think that for virtual machines it has a default
> value so that it isn't necessary to explicitly provide it. It may not have
> a default value fro instance types. Can you try adding this to the request
> to create the instance type?
> >
> > memory_policy=types.MemoryPolicy(
> > max=1 * 2**30
> > )
> >
> > Then try again. If it works I think that we need to fix the engine so
> that it assigns a default value, like it does for virtual machines.
>
> The default for VMs comes from the Blank template. There’s no template for
> instance types, so it always needs to be provided
>
That's true in general, but not for max-memory. Let the blank template be
defined with memory=1024mb and max-memory=4096mb. When a request to add a
VM based on the blank template with memory=8192mb arrives with no
max-memory specified, we cannot take the value of max-memory from the
template since then the operation will fail (as the memory exceeds max
memory)
When adding a VM from rest-api and max-memory is not specified then we set
max-memory = memory * 4 [1, 2].
We can do the same for templates/instance types..
[1]
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendVmsResource.java#L163
[2] and that logic is problematic since the result may exceed the max
memory limitation defined for the OS in os-info and then the operation will
fail..
>
>
> _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20171225/76c1089a/attachment-0001.html>
More information about the Devel
mailing list