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.
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).
(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.
(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.
(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?
(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.
> 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?)