Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1348468

Summary: VM pool in REST is missing all devices but RNG
Product: [oVirt] ovirt-engine Reporter: Barak Korren <bkorren>
Component: RestAPIAssignee: Shahar Havivi <shavivi>
Status: CLOSED CURRENTRELEASE QA Contact: Shira Maximov <mshira>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.6.7CC: bugs, gklein, juan.hernandez, michal.skrivanek, shavivi, tjelinek
Target Milestone: ovirt-4.0.1Flags: rule-engine: ovirt-4.0.z+
rule-engine: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+
Target Release: 4.0.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-12 14:11:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Barak Korren 2016-06-21 08:53:13 UTC 
Description of problem:
When trying to query VM pool configuration from REST API, the configuration for the ballooning device does not show up in the response.

Steps to Reproduce:
1. Setup engine with a VM and a VM pool, both with balooning enabled.
2. Query the VM to show that for VM the querying works:

curl -H 'Content-Type: application/xml' -H 'All-Content: true' \
  -u admin@internal:pass -k \
  https://engine/ovirt-engine/api/vms?search=vm_name \
| grep ballooning

Would return:

<ballooning>true</ballooning>

3. Do the same query but this time for a VM pool:

curl -H 'Content-Type: application/xml' -H 'All-Content: true' \
  -u admin@internal:pass -k \
  https://engine/ovirt-engine/api/vmpools?search=vm_pool_name \
| grep ballooning


Additional info:
Please note that without the 'All-Content: true' header, the ballooning device configuration is not returned for the VM either.
Comment 1 Tomas Jelinek 2016-06-22 07:43:02 UTC 
In BackendVmPoolsResource.doPopulate we set the rng device but nothing else. In BackendVmsResource.doPopulate, on the other hand, we have all this:

        setPayload(model);
        setConsoleDevice(model);
        setVirtioScsiController(model);
        setSoundcard(model);
        setCertificateInfo(model);
        setVmOvfConfiguration(model, entity);
        setRngDevice(model);

Adding at least the devices for the pool should be simple enough to be implemented for 4.0.1. Changing the title accordingly.
Comment 2 Barak Korren 2016-06-22 07:53:52 UTC 
I've an issue when trying to _create_ a VM pool with balloon settings (Via SDK).
I've not yet reported it because I've not found the time yet to write a minimal reproducing script. 
Will a fix to this bug also fix that issue?
Comment 3 Juan Hernández 2016-06-23 14:12:35 UTC 
The SDK issue that you mention is bug 1349382. To make that work the engine needs to report the ballooning information, as suggested by Tomas in comment 1. But it also needs to take it into account when the pool is created, and when it is updated. That may be more complicated than just reporting it.

Shahar, please reevaluate this bug and decide if it is OK for 4.0.1.

Barak, once this is fixed in the engine the SDK will work without any modification. I'm closing that bug as duplicate of this one.
Comment 4 Juan Hernández 2016-06-23 14:14:36 UTC 
*** Bug 1349382 has been marked as a duplicate of this bug. ***
Comment 5 Shahar Havivi 2016-06-23 14:38:02 UTC 
(In reply to Juan Hernández from comment #3)
I don't see y not, I will add Tomas
Comment 6 Tomas Jelinek 2016-06-24 06:17:38 UTC 
only when created - the pool can not be updated by new devices be design. I think we should make it for 4.0.z
Comment 7 Shahar Havivi 2016-06-27 07:30:36 UTC 
Looking at the code I see that the vmpool added only the RGN device as its member (ie its the only device that mapped....)
I don't think that mapping the new devices (as well as the RNG) for the pool is the right way, its not a member of the pool,
instead pool have a vm member and what we usually do is to load the VM with the devices (we take the first VM of the pool, pool must have at least one vm member).
What do you think?
Comment 8 Juan Hernández 2016-06-27 09:47:06 UTC 
Shahar, if I understand correctly you propose to do something like this:

  <vm_pool>
    <name>mypool<name>
    ...
    <vm>
      ...
      <memory_policy>
        <balloning>true|false</ballooning>
      </memory_policy>
      ...
    </vm>
    ...
  </vm_pool>

That looks OK to me.
Comment 10 Barak Korren 2016-06-28 11:32:44 UTC 
Could/should the fix for this be back ported to 3.6?
Comment 11 Michal Skrivanek 2016-07-01 06:31:06 UTC 
(In reply to Barak Korren from comment #10)
> Could/should the fix for this be back ported to 3.6?

not likely. 4.0 is GA now, 3.6 in maintenance
Comment 12 Shira Maximov 2016-08-09 07:57:43 UTC 
verified on : 
Red Hat Virtualization Manager Version: 4.0.2.3-0.1.el7ev

verification steps: 
curl -H 'Content-Type: application/xml' -H 'All-Content: true' \
  -u admin@internal:pass -k \
  https://engine/ovirt-engine/api/vmpools?search=vm_pool_name \


result: 

            <memory_policy>
                <ballooning>true</ballooning>
                <guaranteed>1073741824</guaranteed>
            </memory_policy>