Page History

...

• We are going to re-use existing Async Job management logic with a couple of new additions for createSnapshot scenario. Other async jobs won't get affected.
• createSnapshot API now going to be synchronized on Host object. The host object would be determined even before the command is scheduled for execution - using cloud.host table information (host_id field for snapshots created for vms in Running state, and last_host_id for vms in Stopped state)
• Configuration parameters changes: 2 new global config parameters are added: concurrent.snapshots.threshold.perhost and createsnapshot.job.cancel.threshold.minutes (controls job expiration time).
• DB changes: new field count queue_size is added to cloud.sync_queue table (determines how many jobs are being processed at the moment), the default value for the field is 0. Can't be greater than 1 for any job other than createSnapshot. For createSnapshot the value can't get higher than the parameter concurrent.snapshots.threshold.perhost allows. New filed job_timeout is added to async_job table - determines the timeout for the async job. If NULL, the timeout is defaulted to the global config value (60 mins) that is respected by any async job. This parameter would be set only for createSnapshot jobs at the moment - to the value defined in createsnapshot.job.cancel.threshold.minutes.
• Code flow: Once the createSnapshot operation is requested either by the user via API, or by cloudStack snapshot scheduler, the code:

1) Determines the host information by a) retrieving the vm information from the volume. b) checking host_id for the vm. If not null, this would be the target host. If null, check last_host_id. If not null, the last_host_id is the targeted host. If both fields are null, then we don't do any synchronization - this is a very rare use case, and in 99% in most of the cases cloudStack won't experience it.

...