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.
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.
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?
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.
*** Bug 1349382 has been marked as a duplicate of this bug. ***
(In reply to Juan Hernández from comment #3) I don't see y not, I will add Tomas
only when created - the pool can not be updated by new devices be design. I think we should make it for 4.0.z
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?
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.
Could/should the fix for this be back ported to 3.6?
(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
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>