Roy, simply directly tweaking a few parameters in the OVF_STORE (ram, core number, MAC addr for instance) could work or we need also to save them in the engine DB?

1. It is needed to save it into the DB as well, since the OVF is re-written.

2. We also need to handle editing the HA agents config files stored in the shared storage.

(In reply to Doron Fediuck from comment #2)
> 1. It is needed to save it into the DB as well, since the OVF is re-written.
> 
> 2. We also need to handle editing the HA agents config files stored in the
> shared storage.

Currently ovirt-ha-agent already reads the OVF_STORE, the initial/boostrap vm.conf on the shared storage is used as a fallback configuration just if the OVF_STORE is not available.

I'm not sure if we should make a tool like this since we are going to add edit VM. The question what target you are planning to finish the bug fixes for that.

The solution would be bypass to shared configuration rather than to supply an edit configuration tool from the cli.

Something like:

  hosted-engine --vm-start --vm-conf=/path/to/vm.conf

And that will load the VM straight from that conf. User can copy the /var/run/hosted-engine/vm.conf locally and amend it to its needs. Then the VM will be up and the user will use the 'edit vm' flow and that will persist the configuration and make them ready for next run.

The recovery flow is:

1. set global maintenance mode: hosted-engine --set-maintenance --mode=global 
2. poweroff engine VM if somehow up: hosted-engine --vm-poweroff
3. copy /var/run/ovirt-hosted-engine-ha/vm.conf somewhere as a template
4. edit it according to what you need
5. restart engine VM with a custom vm.conf: hosted-engine --vm-start --vm-conf=my_custom_vm.conf
6. from the engine, revert your latest changes to the hosted-engine VM

(In reply to Simone Tiraboschi from comment #6)
> The recovery flow is:
> 
> 1. set global maintenance mode: hosted-engine --set-maintenance
> --mode=global 
> 2. poweroff engine VM if somehow up: hosted-engine --vm-poweroff
> 3. copy /var/run/ovirt-hosted-engine-ha/vm.conf somewhere as a template
> 4. edit it according to what you need
> 5. restart engine VM with a custom vm.conf: hosted-engine --vm-start
> --vm-conf=my_custom_vm.conf
> 6. from the engine, revert your latest changes to the hosted-engine VM

Simone, step#6 is not clear. isn't this whole bug is about the fact that we cannot edit the vm in the engine? Or did you mean - start the HE VM and then get out of maintenance?

In a near future the user will be able to edit the engine VM from the engine; on next boot the engine VM will be loaded with the new configuration.

This RFE was just about providing a recovery mechanism if, for any reason, the engine VM isn't able to start with the new configuration since at that point there is no running engine to edit it again.

With this RFE the user can pass a custom vm.conf to start the engine VM and at that point, having an engine, the user can edit again the engine VM configuration.

To be fully precise in comment 6 I didn't described the two final steps:

7. reboot again the engine VM to load the fresh configuration
8. If everything is fine, exit global maintenance mode

Thanks a lot, Simone.
I documented it here:
https://access.redhat.com/solutions/2209751

Checked on ovirt-hosted-engine-setup-1.3.5.0-1.el7ev.noarch
I see that it works and VM received parameters from my configuration file, but I see that parameters not updated under the engine.
For example:
1) Change VM memory from 4Gb to 8Gb
2) I see that VM has 8GB, but engine shows that HE VM has 4Gb

Does it desired behaviour?

(In reply to Artyom from comment #10)
> Checked on ovirt-hosted-engine-setup-1.3.5.0-1.el7ev.noarch
> I see that it works and VM received parameters from my configuration file,
> but I see that parameters not updated under the engine.
> For example:
> 1) Change VM memory from 4Gb to 8Gb
> 2) I see that VM has 8GB, but engine shows that HE VM has 4Gb
> 
> Does it desired behaviour?

No, it's not: the engine should report it coherently.
But, if you see the correct amount inside the VM, this is just a different issue on engine side (probably just a refresh issue).

I tried to refresh, but I still see only 4Gb instead of 8Gb under the engine. Looks like it does not update DB:
engine=# select mem_size_mb from vm_static where vm_name='HostedEngine';
 mem_size_mb 
-------------
        4096
(1 row)

so I will open another bug.

Verified on ovirt-hosted-engine-setup-1.3.5.0-1.el7ev.noarch

Why do we need the flag?
I have just added an additional vnic to my RHEV-M that is HE VM through the admin portal. However:
# engine-config -g AllowEditingHostedEngine
AllowEditingHostedEngine: false version: general

This is 3.6.5 rhevm appliance upgraded from 3.6.3.

Apologies,
The flag mentioned here is the --vm-conf.
I got it confused with AllowEditingHostedEngine.
Taking my question back.