Bug 1931812 - VMs in a pool are created with different memory values than those provided in the update-pool request
Summary: VMs in a pool are created with different memory values than those provided in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RestAPI
Version: 4.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.5.0
: 4.5.0
Assignee: Arik
QA Contact: Tamir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-23 10:15 UTC by nicolas
Modified: 2022-04-20 06:33 UTC (History)
5 users (show)

Fixed In Version: ovirt-engine-4.5.0
Clone Of:
Environment:
Last Closed: 2022-04-20 06:33:59 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.5?


Attachments (Terms of Use)
This is the first machine created, which honors the template parameters. (14.26 KB, image/png)
2021-08-04 12:43 UTC, nicolas
no flags Details
This is the second machine created, which doesn't honor the template parameters. (14.69 KB, image/png)
2021-08-04 12:43 UTC, nicolas
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 116403 0 master ABANDONED api: VmPool created with different memory values than defined in template 2021-12-01 16:18:34 UTC
oVirt gerrit 117885 0 master MERGED api: VmPool created with different memory values than defined in template 2022-01-02 14:28:05 UTC
oVirt gerrit 118191 0 master ABANDONED api: VmPool created with different memory values than defined in template 2022-01-17 11:13:41 UTC
oVirt gerrit 118233 0 master MERGED api: VmPool created with different memory values than defined in template 2022-01-17 12:34:01 UTC

Description nicolas 2021-02-23 10:15:48 UTC
Description of problem:

We're using oVirt 4.3.8 along with ovirt-engine-sdk-python (4.4.1) to handle our pools.

When creating a VmPool based on template and then changing template memory values, then extending the pool, the VMs created with original template memory values, not honoring the values in the updated template.

We're handling a big number of VMs based on pools (> 1500), and we think this should be fixed, as pools are created with incorrect memory values.

When creating the VmPool from the GUI, it's created correctly, so I assume this is a Python-API issue.

As a hint, it might be related to BZ 1897532.

Version-Release number of selected component (if applicable):

4.4.1

How reproducible:

Always

Steps to Reproduce:

1- Create a VmPool using this snippet:

    newpool = types.VmPool(name='test',
                           cluster=cl,
                           template=t,
                           max_user_vms=1,
                           size=1,
                           type=types.VmPoolType.MANUAL)
    vmpool_serv.add(newpool)


cl is a types.Cluster instance.
t is a types.Template instance of a template with some memory parameters changed(without saving the template).



2- Extend the VM-pool, e.g: using this snippet

  vmp_serv = sys_serv.vm_pools_service()
  pool = vmp_serv.get(search='name=test')
  pool.size = 200                         # New size
  vmpsv = vmp_serv.pool_service(id=pool.id)
  vmpsv.update(pool=pool)



Actual results:

A VM pool with memory parameters based on original template has been created.


Expected results:

A VM pool with memory parameters based on 't' should be created.

Comment 1 nicolas 2021-02-23 14:10:07 UTC
UPDATE: On the .add() call, we're always creating a pool with size=1, which seems to honor the default memory values of the template. Later, based on some circumstances, we resize the pool, adding new machines. We do this calling:

  vmp_serv = sys_serv.vm_pools_service()
  pool = vmp_serv.get(search='name=test')
  pool.size = 200                         # New size
  vmpsv = vmp_serv.pool_service(id=pool.id)
  vmpsv.update(pool=pool)

It's the newly created vms the ones that have the problem. The first one is ok. The added ones because of the pool resize are not.

Comment 3 RHEL Program Management 2021-03-01 08:55:22 UTC
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

Comment 5 Saif Abusaleh 2021-07-21 14:00:16 UTC
Hi,

I failed to reproduce this issue:

- I created template with specific Memory Size, Maximum memory, Physical Memory Guaranteed

with the python sdk:

- I created vm pool with one vm 

- I updated the vm-pool to contain 10 VM's


In all of the steps memory specifications mentioned above preserved and didn't change

I tested with ovirt-engine 4.4.7 and python-sdk 4.3

Can you please update me if maybe some steps is missing to reproduce the issue, or if the issue got fixed in previous versions


Thanks,
Saif

Comment 6 Arik 2021-07-26 13:04:56 UTC
Based on comment 5, it seems to be fixed already in oVirt 4.4.7.
Feel free to reopen if it still happens for you with a recent version of oVirt.

Comment 7 nicolas 2021-08-04 12:43:17 UTC
Created attachment 1810851 [details]
This is the first machine created, which honors the template parameters.

Comment 8 nicolas 2021-08-04 12:43:58 UTC
Created attachment 1810853 [details]
This is the second machine created, which doesn't honor the template parameters.

Comment 9 nicolas 2021-08-04 12:50:37 UTC
Hi Saif,

I could now test the same example with ovirt-engine-sdk-python version 4.4.14, I couldn't try with a version beyond 4.3.8 of oVirt since this is the version we have in production right now.

I attached two screenshots. The first one corresponds to a machine I created using the Python API, which honors the template parameters. The second one is a machine I got after extending the pool's size. As you can see, the physical memory guaranteed doesn't match the first screenshot. Also, I noticed the CPUs won't match either: In the first machine it's 4, in the extended machine's it's 1.

Could you please check if the same happens in your case? if you confirm everything it's ok on your part I guess it will be a oVirt issue rather than a Python SDK issue.

Comment 10 Saif Abusaleh 2021-08-09 11:05:22 UTC
Hi Nicolas,

it doesn't reproduce in newer ovirt engine version (4.4.7+)

I tried the same scenario: to create pool with custom memory values and then extend it, but everything worked fine for me and the values preserved.

I can confirm everything ok in newer engine version, however I don't know on what exact version it was fixed


Thanks,
Saif

Comment 11 Arik 2021-08-09 13:18:45 UTC
(In reply to nicolas from comment #0)
> Steps to Reproduce:
> 
> Create a VmPool using this snippet:
> 
>     newpool = types.VmPool(name='test',
>                            cluster=cl,
>                            template=t,
>                            max_user_vms=1,
>                            size=1,
>                            type=types.VmPoolType.MANUAL)
>     vmpool_serv.add(newpool)
> 
> 
> cl is a types.Cluster instance.
> t is a types.Template instance of a template with some memory parameters
> defined.

Reading this part again, does it mean that you got an instance of the template, t, and modified its memory parameters?

> 
> Actual results:
> 
> A VM pool with different memory parameters than 't' has is created. 
> 
> Expected results:
> 
> A VM pool with the same memory values than the 't's should be created.

Can you please provide more concrete details -
1. What were the memory parameters of the original template in the webadmin
2. What were the memory parameters of 't' that is mentioned above
3. What were the VMs in the pool set up with in terms of memory parameters

Comment 12 nicolas 2021-08-23 11:55:04 UTC
Hi Arik,

Indeed. I have an instance of the template and the memory parameters (and also the CPU configuration) differs from the template's parameters. No overwriting of these parameters is being done whatsoever at pool creation time.

Answering to your questions:

1) Memory Size: 4096MB, Maximum memory: 8192MB, Physical Memory Guaranteed: 512MB, Total Virtual CPUs: 4
2) Same to answer 1.
3) Memory Size: 4096MB, Maximum memory: 8192MB, Physical Memory Guaranteed: 4096MB, Total Virtual CPUs: 1

Comment 13 Arik 2021-08-24 13:27:13 UTC
Thanks for the follow up.
I think it's more clear now and we can reproduce it also without the SDK:
1. Create a template with memory = 1G
2. Create a pool out of that template from the webadmin with #vms = 1 and memory = 2G
3. Increase the pool size from the API with:
<vm_pool>
  <size>2</size>
</vm_pool>

The created VM would be set with memory=1G
I suspect that's because of [1]

[1] https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.4.8.4/backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendVmPoolResource.java#L123-L138

Comment 14 Arik 2021-08-24 13:29:49 UTC
Setting severity to high because of our assumptions that VMs in a pool should be the same (when editing a pool from the webadmin for instance, we pick an arbitrary VM from the pool to determine its memory, CPU, etc)

Comment 15 Ori Liel 2021-11-23 13:06:48 UTC
(In reply to Arik from comment #13)
> Thanks for the follow up.
> I think it's more clear now and we can reproduce it also without the SDK:
> 1. Create a template with memory = 1G
> 2. Create a pool out of that template from the webadmin with #vms = 1 and
> memory = 2G
> 3. Increase the pool size from the API with:
> <vm_pool>
>   <size>2</size>
> </vm_pool>
> 
> The created VM would be set with memory=1G

So the *problem* is that the value is taken from the template (rather than from input to the vm-pool creation) - correct?
The bug describes values being different than the template as the problem - that's the opposite. 
Looks like the bug description needs to change

> I suspect that's because of [1]
> 
> [1]
> https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.4.8.4/backend/
> manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/
> resource/BackendVmPoolResource.java#L123-L138

Comment 16 Arik 2021-11-23 13:24:19 UTC
(In reply to Ori Liel from comment #15)
> So the *problem* is that the value is taken from the template (rather than
> from input to the vm-pool creation) - correct?
> The bug describes values being different than the template as the problem -
> that's the opposite. 
> Looks like the bug description needs to change

Right, changed

Comment 18 Tamir 2022-03-22 15:49:46 UTC
Verified on RHV 4.5.0-4.
Thanks for the steps Arik.

Env:
    - Engine instance with RHV 4.5.0-4 (ovirt-engine-4.5.0-0.237.el8ev) and RHEL 8.6 installed.
    - 3 hosts with RHV 4.5.0-4 and RHEL 8.6 and with vdsm-4.50.0.10-1.el8ev.

Steps:

In Admin Portal:
1. Create a 4.7 data center and a 4.7 cluster.
2. Install the hosts and create a new NFS storage domain.
3. Create an RHEL 8.6 VM with memory size: 1024 MB, maximum memory: 4096 MB, and physical memory guaranteed: 1024 MB.
4. Create a template from the VM.
5. Create a VM pool from the template with size: 1, memory size: 2048 MB, maximum memory: 8192 MB, and physical memory guaranteed: 2048 MB.
6. Send a GET request to the URL "https://{{base_url}}/ovirt-engine/api/vmpools" to find the VM pool object ID.  
7. Send a PUT request to the URL "https://{{base_url}}/ovirt-engine/api/vmpools/{ID}" with the body:
<vm_pool>
    <size>3</size>
</vm_pool>
8. Enter each created VM page in the Admin Portal and check that the created VM is set with memory size: 2048 MB, maximum memory: 8192 MB, and physical memory guaranteed: 2048 MB.


Results (As Expected):
1. The 4.7 data center and the 4.7 cluster were created.
2. The host was installed and the NFS storage domain was created.
3. The VM was created.
4. The template was created.
5. The VM pool and 1 VM were created.
6. The VM pool ID was found.
7. The VM pool was updated to 3 VMs.
8. The VMs were created with memory size: 2048 MB, maximum memory: 8192 MB, and physical memory guaranteed: 2048 MB.

Notes:

Steps 6-7 are equivalent to the following Python SDK commands:
        pool_service: VmPoolsService = lib.system_service().vm_pools_service()
        update_pool: VmPool = pool_service.list(search='name=test')[0]
        pool_service.pool_service(update_pool.id).update(pool=VmPool(size=3))

Comment 19 Sandro Bonazzola 2022-04-20 06:33:59 UTC
This bugzilla is included in oVirt 4.5.0 release, published on April 20th 2022.

Since the problem described in this bug report should be resolved in oVirt 4.5.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


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