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.
- VM state changes (powerOn, powerOff, etc)
- Configure/Deconfigure/Reconfigure VM
- Register/Unregister/Update VM with Firewall Policy / Load Balancer / Nat Rule
- Perform Backup / Schedule Backup / Restore From Backup of a VM
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 if you have two vCenters and some public cloud regions, 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 by the values set 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
When using ''openSession.byvdc'', the platform does not limit the maximum number of concurrent connections to the provider endpoint or hypervisor IP (i.e. same set of connection data), device, or backup manager.
In contrast, if openSession.byvdc is false, the platform will only allow two concurrent operations for each provider endpoint or hypervisor IP, device, or backup manager.
Allow fast VM state changes
The VM state changes are:
- powerOn
- powerOff
- shutdown
- reset
- pause
- resume
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. 