The platform uses configuration properties to control the number of concurrent operations for a hypervisor or provider, device, or backup manager. 

This feature enables you to change the context of concurrency control from the whole platform to the hypervisor/provider level, or to the VDC level. So you can control concurrent operations on a specified type of hypervisor, public cloud region, or VDC. This enables administrators to restrict only a specific hypervisor type (e.g. vCloud with no concurrency) without affecting other types (e.g. ESXi with maximum concurrency).

At the VDC level, the platform can limit concurrent operations that affect the same virtual datacenter, while allowing ones to different VDCs, e.g. vCloud_VDC_1 and vCloud_VDC_2. Through the VDC context, the platform can control concurrency for the many kinds of entities associated with a VM (its firewalls, load balancers, NAT IPs, and backups.

You can choose to allow concurrent operations that change the state of a VM, e.g. powering it on, while limiting VM configure operations.


List of VM operations where the platform controls concurrency

The platform controls concurrency for VMs, which means the following operations that are managed through the provider/hypervisor, device, or backup manager.

An example of when concurrency limits apply is when you are deploying a virtual appliance with multiple VMs.

Control concurrency at the platform level

The top level of concurrency configuration is the platform. This limits the number of concurrent operations for the same connection (hypervisor IP or endpoint), device, or backup manager.

abiquo.virtualfactory.openSession
abiquo.virtualfactory.device.openSession
abiquo.virtualfactory.backup.openSession

For example, to allow two connections to each public cloud region and hypervisor, set openSession to 2. 

abiquo.virtualfactory.openSession=2

This means that you can perform two concurrent operations on vCenter1, and two on vCenter2, and two on each of the public cloud regions.



Control concurrency by the type of hypervisor or public cloud provider, device, or backup manager

To limit concurrency for specific plugins, devices, or backup managers, set specific properties.

abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession
abiquo.virtualfactory.{backupManagerLowerCase}.backup.openSession
abiquo.virtualfactory.{deviceLowerCase}.device.openSession

If you do not specify a value, then the default is the platform level property.

For example, to allow two connections to AWS.


Control concurrency at the virtual datacenter level

Concurrency control at the VDC level means that the platform will apply the properties for concurrency values (including plugin type, device, and backup manager) to an individual VDC.

This means that you must have either a public cloud region with native support for VDCs (e.g. AWS VPC, Azure Virtual Network, vCloud vApp) or a hypervisor with a network device, (e.g. vCenter + NSX device).  

If you do not specify these properties, the default values are false, which means that concurrent operations are limited by the type of hypervisor/public cloud provider, device, or backup manager. Or at the platform level. 

abiquo.virtualfactory.openSession.byvdc=false
abiquo.virtualfactory.device.openSession.byvdc=false
abiquo.virtualfactory.backup.openSession.byvdc=false


To prevent concurrency in the same virtual datacenter, which means all the operations to the same VDC will be executed one after another, set the byvdc property.
For example, with the the following properties, it will be possible to execute multiple concurrent operations (for the same PCR endpoint (connection data)) but only if they affect different virtual datacenters.

abiquo.virtualfactory.openSession.byvdc=true
abiquo.virtualfactory.openSession=1


Total number of concurrent operations

When using ''openSession.byvdc'', the platform does not limit the maximum number of concurrent connections to the same ConnectionData (provider endpoint or hypervisor IP). 

For example, if you have set openSession=2 for a vCloud1, when openSession.byvdc is set to true, the platform will allow two concurrent operations per VDC in vCloud1, with a total of up to "Number of VDCs x 2".

In contrast, if openSession.byvdc is false, the platform will only allow two concurrent operations for vCloud1.

Allow fast VM state changes

The VM state changes are: 

To always allow VM state changes without considering the ''openSession'' limitation, set the fast state changes property to true, as shown here.

abiquo.virtualfactory.openSession.faststatechanges=true

When you use this fast state changes functionality, the platform will always execute VM state changes when you request them, without waiting for an ''available worker in the pool''.

For example, with the following configuration, the platform will only allow one configure/deconfigure/reconfigure at a time, but state changes can occur concurrently.

abiquo.virtualfactory.openSession.faststatechanges=true
abiquo.virtualfactory.openSession=1


 

Limitations
—
* the properties only apply to the virtualfactory (vm centric ops) so don't expect other operations with entities related to virtualdatacenter are also executed in the same pool (eg: create private network doesn't follow this concurrency limitations)

* byvdc requires a Vpc interface implementation, which can be:
** compute plugin also implements Vpc. eg: PCR vcloud 
** compute plugin + networking device. eg: vcenter + nsx device 

* changing the behavior of the pool when using a provider also capable of device ops (public clouds with lb,fw, net or nat features), previously using 2 pools (opensessions + device.opensessions), now a plugin capable of executin device ops only use the opensessions pool. (question)