Theoretically that’s doable I guess, but practically it could be fairly easy to show that next_run exists and we are able to return the snapshot xml. But parsing it and constructing the complete VM config from that would duplicate backend functionality too much. If we really want to do that then it should better be exposed via API like requested in bug 1647455

(In reply to Michal Skrivanek from comment #2)
> Theoretically that’s doable I guess, but practically it could be fairly easy
> to show that next_run exists and we are able to return the snapshot xml. But
> parsing it and constructing the complete VM config from that would duplicate
> backend functionality too much. If we really want to do that then it should
> better be exposed via API like requested in bug 1647455

Yes, it is complicated. So imagine how complicated is this for the user. So yes, I believe that some part should be moved to the API as the engine is the one that knows all these relations. But the Bug 1647455 was closed. 
So can these 3 bugs can be discussed together?

    Bug 1647455 - [RFE][REST] Provide information about the VM next run
    Bug 1647473 - [RFE][ANSIBLE] Provide information about the VM next run
    Bug 1647440 - [RFE][UI] Provide information about the VM next run

So it is clear what has to be done in each of the components and the users are those that can benefit from this.

with respect to this particular RFE - is there anything more required than https://github.com/ansible/ansible/commit/7034d8c47abd0f859030ba1bd7683355bd68acc8 ?

(In reply to Michal Skrivanek from comment #5)
> with respect to this particular RFE - is there anything more required than
> https://github.com/ansible/ansible/commit/
> 7034d8c47abd0f859030ba1bd7683355bd68acc8 ?

I would appreciate if we could say that there is the next run so the user knows that they should run the module with next_run parameter. Maybe if we could provide a custom filter that would compare the two results.

Would it be possible Ondro?

Currently there is no way how to ship the filters. There will be very soon when we switch to Ansible collections[1].
So for now user can use their custom filter to have that like this one:

 https://github.com/machacekondra/ovirt-ansible-filters/blob/master/vmdiff.yml#L27
 https://github.com/machacekondra/ovirt-ansible-filters/blob/master/filter_plugins/ovirtfilters.py#L20

[1] https://github.com/ansible-collections/

Moving to 4.4, once ansible-collections gets stabilized, we can discuss backport to 4.3.z

Moving to 4.5 as we will most probably not be able to provide Ansible Collections for oVirt Ansible modules/roles within RHV 4.4 timeline

I have added the Ondras patch to oVirt collection https://github.com/oVirt/ovirt-ansible-collection/.
Taking the issue on me in case there is anything else to update.

Is this correctly targeted to 4.5.0?

TASK [Get VM myvm] ************************************************************************************************************************************
ok: [localhost]

TASK [Get next_run of VM myvm] ************************************************************************************************************************
ok: [localhost]

TASK [Print what will be changed in next run of the VM] ***********************************************************************************************
ok: [localhost] => {
    "msg": {
        "after": {
            "creation_time": "2021-04-06 14:30:33+03:00",
            "memory_policy": {
                "ballooning": true,
                "guaranteed": 1073741824,
                "max": 17179869184
            },
            "os": {
                "boot": {
                    "devices": [
                        "hd",
                        "network"
                    ]
                },
                "type": "other_linux"
            },
            "storage_error_resume_behaviour": "leave_paused"
        },
        "before": {
            "creation_time": "2021-04-06 14:30:33.053000+03:00",
            "memory_policy": {
                "guaranteed": 1073741824,
                "max": 8589934592
            },
            "os": {
                "boot": {
                    "devices": [
                        "hd"
                    ]
                },
                "type": "other_linux"
            },
            "storage_error_resume_behaviour": "auto_resume"
        }
    }
}

TASK [ovirt_auth] *************************************************************************************************************************************
ok: [localhost]

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (RHV Engine and Host Common Packages 4.4.z [ovirt-4.4.5]), and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2021:1185