Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1268842

Summary:	Keep OVF_STORE volumes up to date
Product:	[oVirt] ovirt-engine	Reporter:	Christopher Pereira <kripper>
Component:	BLL.Storage	Assignee:	Allon Mureinik <amureini>
Status:	CLOSED NOTABUG	QA Contact:	Aharon Canan <acanan>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.6.0.1	CC:	bugs, kripper
Target Milestone:	ovirt-4.0.0-alpha	Flags:	amureini: ovirt-4.0.0? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	4.0.0
Hardware:	All
OS:	All
Whiteboard:	storage
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-10-14 09:36:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	825671
Bug Blocks:

Description Christopher Pereira 2015-10-05 12:21:40 UTC

The OVF_STORE volumes generated by Engine are very usefull for data-recovery.

A Storage Domain can be replicated in many ways, but the backup is not reliable if the OVF_STORE volumes are not up to date.

For example when creating snapshots, it is very important to update the VM definition in the OVF_STORE, because we need the VM to point to the latest snapshot (the active one). In other case, we may loose data when importing an outdated VM on another Datacenter.

Currently (3.6 RC 1), the OVF_STORE is only updated when setting the StorageDomain in maintenance mode or when detaching it.

Depending on the required resources, it would be ideal to update the OVF_STORE whenever a VM is modified.

Comment 1 Allon Mureinik 2015-10-06 09:34:54 UTC

Updating OVF data synchroniously as part of VM management operations is too heavy, and was purposely removed from it as part of the OVF store feature introduced in 3.5. This decision won't be reverted, but it could be good improvement to add an API to explicitly force the OVF store update - would that be useful for you?

Note The OVF store is updated periodically (determined by the OvfUpdateIntervalInMinutes config value, defaulting to 60 minutes).

Comment 2 Christopher Pereira 2015-10-11 07:27:56 UTC

(In reply to Allon Mureinik from comment #1)
> Updating OVF data synchroniously as part of VM management operations is too
> heavy, and was purposely removed from it as part of the OVF store feature
> introduced in 3.5. This decision won't be reverted, but it could be good
> improvement to add an API to explicitly force the OVF store update - would
> that be useful for you?

Hi Allon.
Yes, having a REST API method for regenerating a OVF_STORE would be great.

> Note The OVF store is updated periodically (determined by the
> OvfUpdateIntervalInMinutes config value, defaulting to 60 minutes).

Could also be usefull as a workaround for 3.6. I guess a engine restart is required to take effect config changes, and another one to revert to the default 60 minutes.
Having the API is definitively preferable.

I wonder why updating the OVF store each 60 minutes is better than updating it only when some VM property changed?

The crtiteria could also be "schedule a OVF update 5 minutes after some property changed" + "don't schedule new updates until next OVF generation". This way, multiple changes in less then 5 minutes will trigger only 1 OVF update.

Again, having explicit control via REST API is still better.

Comment 3 Allon Mureinik 2015-10-11 08:16:37 UTC

(In reply to Christopher Pereira from comment #2)
> (In reply to Allon Mureinik from comment #1)
> > Updating OVF data synchroniously as part of VM management operations is too
> > heavy, and was purposely removed from it as part of the OVF store feature
> > introduced in 3.5. This decision won't be reverted, but it could be good
> > improvement to add an API to explicitly force the OVF store update - would
> > that be useful for you?
> 
> Hi Allon.
> Yes, having a REST API method for regenerating a OVF_STORE would be great.
> 
> > Note The OVF store is updated periodically (determined by the
> > OvfUpdateIntervalInMinutes config value, defaulting to 60 minutes).
> 
> Could also be usefull as a workaround for 3.6. I guess a engine restart is
> required to take effect config changes, and another one to revert to the
> default 60 minutes.
AFAIK, yes. There's an old RFE to allow reloading configuration (bug 825671).
Oved - are there any plans to revive this?

> Having the API is definitively preferable.
> 
> I wonder why updating the OVF store each 60 minutes is better than updating
> it only when some VM property changed?
> 
> The crtiteria could also be "schedule a OVF update 5 minutes after some
> property changed" + "don't schedule new updates until next OVF generation".
> This way, multiple changes in less then 5 minutes will trigger only 1 OVF
> update.
I oversimplified the explanation.
The job wakes up every 60 minutes (configurable, as noted above) and checks if anything was updated since the last update. If there isn't, nothing is done. If there was, the OVF_STORE is rewritten.


> 
> Again, having explicit control via REST API is still better.
Agreed - I opened bug 1270562 to track this.

Comment 4 Allon Mureinik 2015-10-11 08:17:54 UTC

(In reply to Allon Mureinik from comment #3)
> > Again, having explicit control via REST API is still better.
> Agreed - I opened bug 1270562 to track this.
Having said that - do we need this BZ?
- The core behavior won't change
- The new API is tracked in that BZ.

What else is left here?

Comment 5 Oved Ourfali 2015-10-11 08:22:39 UTC

(In reply to Allon Mureinik from comment #3)
> (In reply to Christopher Pereira from comment #2)
> > (In reply to Allon Mureinik from comment #1)
> > > Updating OVF data synchroniously as part of VM management operations is too
> > > heavy, and was purposely removed from it as part of the OVF store feature
> > > introduced in 3.5. This decision won't be reverted, but it could be good
> > > improvement to add an API to explicitly force the OVF store update - would
> > > that be useful for you?
> > 
> > Hi Allon.
> > Yes, having a REST API method for regenerating a OVF_STORE would be great.
> > 
> > > Note The OVF store is updated periodically (determined by the
> > > OvfUpdateIntervalInMinutes config value, defaulting to 60 minutes).
> > 
> > Could also be usefull as a workaround for 3.6. I guess a engine restart is
> > required to take effect config changes, and another one to revert to the
> > default 60 minutes.
> AFAIK, yes. There's an old RFE to allow reloading configuration (bug 825671).
> Oved - are there any plans to revive this?
> 

No. We didn't see strong need for that to justify the needed investment. More details on the bug itself.

Comment 6 Christopher Pereira 2015-10-14 09:36:08 UTC

> I oversimplified the explanation.
> The job wakes up every 60 minutes (configurable, as noted above) and checks
> if anything was updated since the last update. If there isn't, nothing is
> done. If there was, the OVF_STORE is rewritten.

Well, this satisfies the requirement and is also a clean solution, so the REST API is really not so important.
I will reduce the OvfUpdateIntervalInMinutes configuration value on my setup and close this BZ.
Thanks for your valuable feedback.

Since update-checks are performed, maybe consider reducing the default value for OvfUpdateIntervalInMinutes (5 minutes?)