Note that the REST API should not enable or disable anything, business logic is the responsibility of the backend, the REST API should just send to the backend whatever the user sent.

This might be reproducible via other APIs as well. Please check if they are not setting balloon to enabled or they are just sending values set by user.

This is what I use from python to test VM creation on ppc:

api.vms.add(params.VM(name=VM_NAME,
                              memory=2*GB,
                              cluster=api.clusters.get("Default"),
                              template=api.templates.get('Blank'),
                              memory_policy=params.MemoryPolicy(ballooning=False),
                              placement_policy=params.VmPlacementPolicy(host=api.hosts.get("asda"),affinity='pinned')))

and using curl (I didn't test it, just got it from our QA):

curl -X POST -H "Accept: application/xml" -H "Content-Type: application/xml" \
    -u admin@internal -k \
    -d "<vm><name>ppc64</name> \
    <cluster><name>ppc64</name></cluster> \
    <template><name>Blank</name></template> \
    <os type='rhel_6_ppc64'><boot
dev='hd'/></os><memory_policy><ballooning>false</ballooning></memory_policy></vm>"
\
    https://[engine]/api/vm

I think it would be better if ballooning was disabled automatically when you create a VM in a cluster that does not support it. Just like what happens with SPICE, migration, etc, ... these things are automatically chosen according to the target architecture.

(In reply to Vitor de Lima from comment #4)
> I think it would be better if ballooning was disabled automatically when you
> create a VM in a cluster that does not support it. Just like what happens
> with SPICE, migration, etc, ... these things are automatically chosen
> according to the target architecture.

Vitor we need to maintain consistency in the system behavior.
When working with a script a user should assume to get the same results
regardless of the specific cluster he is working on.
Since the default behaviour of libvirt and the engine are to add a balloon
device, we keep the default regardless of the cluster. When working with PPC
you should make sure your VM settings comply with PPC needs or get an error
as the above message shows.

To conclude,
PPC should not break system defaults, and the same behaviour remains.
When working with PPC cluster the user should specify ballooning=False
among other properties needed for the VM to run.

Doron, if the default behavior of libvirt is to send ,balloning == 'True', regardless of cluster attribute, what does the cluster flag

<ballooning_enabled>
                    false
</ballooning_enabled>

means? does it do something? or is it data redundancy?
Like you I also believe in consistency, but closing this as NOTABUG for the sake of libvirt consistency, damages the costumer consistency.
literally none of my scripts work, I'm executing every operation manually and believe me,if I'm frustrated, an experienced rhev costumer will rage

Look at this scenario and try it yourself please.

1. Create VM with RESTAPI "<vm><name>foo</name><memory_policy><ballooning>false</ballooning></memory_policy><cluster><name>Default</name></cluster><template><name>Blank</name></template></vm>"
Im ok with setting ballooning to false as it goes by your comment in bug
2. try to edit ANYTHING on the VM

~] $ curl -X PUT -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin@internal:$pwd --cacert ca.crt -d "<vm><name>bar</name></vm>" $engine/api/vms/$vmid
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fault>
    <reason>Operation Failed</reason>
    <detail>[Cannot edit VM. Balloon is not supported on 'ppc64' architecture.]</detail>
</fault>

Do I really have to put "<memory_policy><ballooning>false</ballooning></memory_policy>" into every
edit I want to make with REST? Even that I did not try to enable the balloon?

For me this is really not user friendly solution. Not to mention that it will break all the automation we have.

Also we need to edit all our automation tests to put balloning=False, that also not good solution and also it different behavior via UI(balloning by default False) and via other API(balloning by default True). We have many peoples that thinks, it's better to put balloning by default false for all api or get balloning value from cluster and put the same for vms. So maybe it's worth to fix it?

(In reply to Artyom from comment #8)
> Also we need to edit all our automation tests to put balloning=False, that
> also not good solution and also it different behavior via UI(balloning by
> default False) and via other API(balloning by default True). We have many
> peoples that thinks, it's better to put balloning by default false for all
> api or get balloning value from cluster and put the same for vms. So maybe
> it's worth to fix it?

You're confusing several things, so let's explain it;
Using a balloon has 2 levels-
1. VM level: does the VM have a balloon device
2. Cluster level: so we actively use ballooning in the given cluster.

The fact that (2) is set to true does not imply that all VMs will have a
balloon device. On the other hand, the fact that a VM has a balloon does not
mean we'll be using it. The actual uses vary between users. 
The important thing is that we are obliged to maintain behavior consistency
with libvirt (and had to fix our code for it in the past). This is why every
VM has a balloon device even if not being used in the current cluster. This
consistency must be kept in .z releases. Changing it for 3.6 would probably
be easier since scripts with ballooning=false will still be supported and this
is a safer way to conduct such a change.

understood,this should be well documented.