Concurrency limits at the platform level
The most basic level of concurrency configuration is at the platform level:
—
{code:java}
abiquo.virtualfactory.openSession
abiquo.virtualfactory.device.openSession
abiquo.virtualfactory.backup.openSession
{code}
This limits the number of concurrent operations for the same connection (hypervisor IP or endpoint). So openSession= 2 means the platform can perform 2 concurrent operations on the same vCenter (for VMX_04 or CLUSTER plugins) or AWS region. So this means, you can have 2 connections to vCenter1 + 2 connections to vCenter2 + 2 connections to any of the public cloud regions.
VM concurrency
Abiquo only controls these concurrency constraints for VMs so the only operations affected are:Abiquo 4.5 introduces new configuration properties to provide greater control over 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 allow concurrent operations that affect different virtual datacenters, e.g. vCloud_VDC_1 and vCloud_VDC_2, but not the same VDC. 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 concurrency operations
The platform controls concurrency for VMs, so this affects the following operations.
* 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
...
Control concurrency at the
...
In Abiquo 4.5+ you can limit concurrency for a virtual datacenter (instead of for a connection):
VirtualDatacenterId (or vpc provider identifier) can be found in this entities:
* VirtualMachineIdentifier (+ VirtualMachineIdentifierWithAddresses + VirtualMachineDefinition)
* Vpc
* Network
* PublicIp
* FirewallPolicy
* LoadBalancer
* VPN
* NatIp (ABICLOUDPREMIUM-11391)
Its also required to provide a way to configure a different value based on the plugin type. (eg: 2 concurrent operations for all the vcenter instances but 1 for vcloud).
...
platform level
The most basic level of concurrency configuration is the existing control at the platform level. This limits the number of concurrent operations for the same connection (hypervisor IP or endpoint), device, or backup manager.
{code:java}
abiquo.virtualfactory.openSession
abiquo.virtualfactory.device.openSession
abiquo.virtualfactory.backup.openSession
{code}
For example, to allow 2 connections to vCenter1 + 2 connections to vCenter2 + 2 connections to each of the public cloud regions, set openSession to 2.
{code:java}
abiquo.virtualfactory.openSession=2
{code}
For example, the platform can perform 2 concurrent operations on the same vCenter (for VMX_04 or CLUSTER plugins) or AWS region.
Control concurrency by plugin type, device, or backup manager
To limit concurrency for specific plugin types, devices, or backup managers
If not specified by type, then the defaults are the platform level properties.
{code:java}
abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession
abiquo.virtualfactory.{backupManagerLowerCase}.backup.openSession.byvdc=false
abiquo.virtualfactory.{deviceLowerCase}.device.openSession
{code}
If true then the limit of concurrency (openSession) apply for each distinct virtualdatacenter.Eg:
Control concurrency at the virtual datacenter level
In Abiquo 4.5+ you can also limit concurrency for virtual datacenters. This will not apply to public cloud providers that do not support VDCs.
To prevent concurrent operations at the virtual datacenter level, use the "byvdc" property. This property can apply to VDCs, devices, and backup managers.
The default value allows concurrent operations to the same VDC.
{code:java}
abiquo.virtualfactory.openSession.byvdc=truefalse
abiquo.virtualfactory.device.openSession.byvdc=false
abiquo.virtualfactory.backup.openSession=1No .byvdc=false
{code}
For example, to prevent concurrency in the same virtual datacenter. All , which means all the operations to the same vdc VDC will be executed one after another, set the following properties.
In For the same PCR endpoint (ConnectionDataconnection data), it will be possible to execute multiple concurrent operations but only if affects they affect different virtualdatacentrsvirtual datacenters.
Fast state changes
—
{code:java}
abiquo.virtualfactory.openSession.faststatechangesbyvdc=true
abiquo.virtualfactory.openSession=1
{code}If true, VirtualMachine state changes (powerOn/powerOff/shutdown/reset/pause/resume) escape
You can also control concurrency for device and backup managers at the virtual datacenter level.
Note that when using ''openSession.byvdc',' the maximum number of concurrent connections to the same ConnectionData (provider endpoint or hypervisor IP) is not limited.
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, those operations are always executed when requested without waiting for any ''available worker in the pool''.Eg:set the fast state changes property to true, as shown here.
{code:java}
abiquo.virtualfactory.openSession.faststatechanges=true
abiquo.virtualfactory.openSession=1Only {code}
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 etc at reconfigure at a time, but any state changes can occurs occur concurrently.
By plugin type
—
{code:java}
abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession ## also for ''device'' and ''backup''
abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession.byvdc ## also for ''device'' and ''backup''
abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession.faststatechanges ## only compute plugin
{code}
Only apply to specify plugin types, if not specified by type then the default is ''=true
abiquo.virtualfactory.openSession=1
\{byvdc,faststatechanges}''.code}
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
** compute plugin also implements Vpc. eg: PCR vcloud
** compute plugin + networking device. eg: vcenter + nsx device* when usgin ''opensessions.byvdc'' the max number of concurrent connections to the same ConnectionData (provider endpoint or hypervisor ip) is not limited.device 
* when using ''faststatechanges'' the max number of concurrent operations coulb be <= opensessions x 2 for deploy operations (configure + powerOn) or unlimited if performing other state changes in vms.
* 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.* also removed many DEBUG DeadLeter from virtualfactory.log caused by Ok$Ok messages confirming operations in AMQP channels.
Use Cases
—
* no concurrency in a virtualdatacenter (by type)
{code:java}
Given
abiquo.properties:
* abiquo.virtualfactory.vcd.openSession=1
* abiquo.virtualfactory.vcd.openSession.byvdc=true
a vcloud public cloud region
2 virtualdatacenters (2 vapps in vcloud)
When
deploy a vapp with +1 vm in each vdc
Then
only one concurrent operation for each virtualdatacenter
concurrent operations can affect different virtualdatacenters
{code}
...