Most of them are outdated , but provide historical design context.
They are not user documentation and should not be treated as such.
Documentation is available here.
The OvfAutoUpdater introduces a change to the system-wide behaviour of VM/template OVF updates. Currently every change in the VM configuration entails a synchronous vdsm call to update the OVF in the master domain. With OvfAutoUpdater OVF updates would be performed periodically for multiple OVFs of the same data-center in a single vdsm call. OVF deletions in case of VM/Template removal will be done by the OvfAutoUpdater as well periodically instead of during the execution of VM/Template removal by the user, which will make the operations execution faster.
- Name: Liron Aravot
- Email: email@example.com
VM/template configurations (including disks info) are stored on the master storage domain for backup purposes and in order to provide the ability to run VMs without having a running engine/db. Currently OVF update/removal is done synchronously when performing various operations on VMs/templates - update, save, remove, adding/removing a disk, etc. What's more, currently updating/removing the OVF (vdsm call) is usually done within a transaction.
The idea behind OvfAutoUpdater is to perform batch OVF update operations that aggregate all outstanding updates per data center. These updates will be done in specified time intervals which will reduce XML-RPC calls and will enable the removal of this synchronous vdsm call from all over the code.
The time interval (minutes) between OvfAutoUpdater runs can be configured by the config value
OvfUpdateIntervalInMinutes, defaults to
60. The items count per update (in single vdsm update call) can be configured by the config value
OvfItemsCountPerUpdate, defaults to
Benefit to oVirt
- Reduce vdsm xml-rpc calls.
- Removal of OVF update call from all flows.
- Prevent running OVF update within transactions.
add column - `db_generation BIGINT default 1`
vm_ovf_generations table - newly add table
vm_guid UUID PRIMARY KEY, storage_pool_id UUID REFERENCES storage_pool(id) ON DELETE CASCADE, ovf_generation BIGINT DEFAULT 0
Add to this table records for all the pre-exiting VMs/templates with initial
1 (as their OVF should be already up to date from before)
add row - OvfUpdateIntervalInMinutes config value. add row - OvfItemsCountPerUpdate config value
- New singleton -
OvfDataUpdaterwith an instance initiated during server startup - the constructor schedules a quartz job with interval as configured in the
- When timer time has elapsed, performs the following:
- Get all Storage Pool in status 'UP' (meaning we have a valid master domain and SPM)
- For each storage pool in status 'UP' - Get all VM's/Templates within that storage pool that were changed since last run (
db_generation > ovf_generation) which are not locked and none of their disks are locked.
- Try to run
UpdateVmInSpmfor all those VMs together in a single call (it might be necessary to split the update execution into chunks in order to avoid performing the operation on too many VMs/templates in the same call).
- If successful - for each VM update the
ovf_generationto equal the
db_generationthat was returned in the VM entity when we performed the query to get the VMs for update.
- Load all id's of VMs/templates that were deleted since last OvfAutoUpdater run and issue vdsm command to delete their OVFs.
updateVmInSpmcall in commands with an increment to the
- Increment the
vm_staticshould be performed in the start of the db transaction to prevent possible db deadlocks.
removeVmInSpmcall in commands (removed VMs/templates will be "collected" automatically after removal in the next OvfAutoUpdater run).
OVFs of VMs/Templates that are being/were updated exactly during their processing by OvfAutoUpdater run will have their OVF updated in the storage the next OvfAutoUpdater run, DB updates will occur regularly.