Bug 1372000 - [Re opening] Support update of the HE OVF ad-hoc
Summary: [Re opening] Support update of the HE OVF ad-hoc
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.HostedEngine
Version: 4.0.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.0.6
: 4.0.6
Assignee: Martin Sivák
QA Contact: sefi litmanovich
URL:
Whiteboard: PM-02
Depends On:
Blocks: 1343991
TreeView+ depends on / blocked
 
Reported: 2016-08-31 16:19 UTC by sefi litmanovich
Modified: 2019-04-28 14:14 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-01-18 07:26:36 UTC
oVirt Team: SLA
Embargoed:
rule-engine: ovirt-4.0.z+
mgoldboi: exception+
mgoldboi: planning_ack+
rgolan: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)
agent and engine log (5.81 MB, application/x-gzip)
2016-08-31 16:19 UTC, sefi litmanovich
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1340626 0 urgent CLOSED Support update of the HE OVF ad-hoc 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1343991 0 high CLOSED [z-stream clone - 3.6.10] Support update of the HE OVF ad-hoc 2021-02-22 00:41:40 UTC
oVirt gerrit 65085 0 master POST core: Update OVF in storage domains for HE VM edit 2016-11-01 08:29:27 UTC
oVirt gerrit 65991 0 ovirt-engine-4.0 POST core: Update OVF in storage domains for HE VM edit 2016-11-07 13:40:54 UTC

Internal Links: 1340626 1343991

Description sefi litmanovich 2016-08-31 16:19:56 UTC
Created attachment 1196457 [details]
agent and engine log

Description of problem:

Issue that I thought was resolved on 4.0.2 is actually still occurring.
This a clone for bz#1340626

Failed to verify with rhevm-4.0.3-0.1.el7ev.noarch

STEPS:
1. Installed ovirt-hosted-engine-setup and rhevm-appliance.
2. Deployed hosted-engine using appliance.
3. Upgraded the engine to latest build - rhevm-4.0.3-0.1.el7ev.noarch.
4. Added storage domain to the env - hosted engine vm appears in the system.
5. Set agent.log to DEBUG mode.
6. Set OvfUpdateIntervalInMinutes=1 and restart engine.
7. See in agent.log that the agent communicates with ovf store and fetches vm's configurations as it should.
8. Set OvfUpdateIntervalInMinutes=60 again in order for the update of the ovf occur not due to interval but due to the vm's update.
9. restart engine again.
10. wait a few moments then in the engine update the HE vm and add more memory (action shouldn't fail and DB should show the new value although in practice the action is blocked for HE, but configuration should change nonetheless).
11. In engine log I see 'ProcessOvfUpdateForStoragePoolCommand' being called immediately after change.
12. wait a few minutes and look for the change in the ovf in agent.log and vm.conf - nothing is changed.
13. Set again OvfUpdateIntervalInMinutes=1 and restart engine - after 1 minutes the ovf is updated as it should have been earlier with the new memory value.

Will attach engine and agent logs.

Comment 1 Martin Sivák 2016-09-07 10:45:28 UTC
The engine code properly triggers the update and generates the database copy of the OVF xml with up-to-date values. However this xml is then not transferred to the storage.

Comment 2 Yaniv Lavi 2016-11-15 10:55:07 UTC
Please provide the docs text.

Comment 3 sefi litmanovich 2016-11-20 14:22:05 UTC
Verified on HE rhevm-4.0.6-0.1.el7ev.noarch.
host:
ovirt-hosted-engine-ha-2.0.4-1.el7ev.noarch
ovirt-hosted-engine-setup-2.0.3-2.el7ev.noarch
vdsm-4.18.16-1.el7ev.x86_64

Verified according to the steps in description, now the after a change in the vm memory you can see in few seconds in agent.log (DEBUG MODE) that the vm's ovf was updated according to the change, and therefore also vm.conf is updated as well.


Note You need to log in before you can comment on or make changes to this bug.