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 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.
abiquo.virtualfactory.openSession abiquo.virtualfactory.device.openSession abiquo.virtualfactory.backup.openSession
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.
abiquo.virtualfactory.openSession=2
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.
abiquo.virtualfactory.{pluginTypeInLowerCase}.openSession
abiquo.virtualfactory.{backupManagerLowerCase}.backup.openSession
abiquo.virtualfactory.{deviceLowerCase}.device.openSession
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.
abiquo.virtualfactory.openSession.byvdc=false abiquo.virtualfactory.device.openSession.byvdc=false abiquo.virtualfactory.backup.openSession.byvdc=false
For example, 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 following properties.
For the same PCR endpoint (connection data), it will be possible to execute multiple concurrent operations but only if they affect different virtual datacenters.
abiquo.virtualfactory.openSession.byvdc=true abiquo.virtualfactory.openSession=1
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, 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
** compute plugin also implements Vpc. eg: PCR vcloud
** compute plugin + networking device. eg: vcenter + nsx 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.
Use Cases
—
* no concurrency in a virtualdatacenter (by type)
{newcode: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
{newcode}
* no limitation if not specified by type
{newcode:java}
Given
abiquo.properties:
* abiquo.virtualfactory.vcd.openSession=1
* abiquo.virtualfactory.vcd.openSession.byvdc=true
an amazon public cloud region
2 virtualdatacenters
When
deploy a vapp with +1 vm in each vdc
Then
the default is applied (abiquo.virtualfactory.openSession=2 / abiquo.virtualfactory.openSession.byvdc=false)
only 2 concurrent operations independent of the virtualdatacenter
{newcode}
* change the default concurrency context
{newcode:java}
Given
abiquo.properties:
* abiquo.virtualfactory.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
{newcode}
* compute plugin without vpc device
{newcode:java}
Given
abiquo.properties:
* abiquo.virtualfactory.openSession.byvdc=true
a esx datacenter without any networking device (or using a device not implementing Vpc - nowadays all implements Vpc)
2 virtualdatacenters
When
deploy a vapp with +1 vm in each vdc
Then
vms doesnt have the sense of virtualdatacenter (any?=(no)? Vpc plugin capable of setting the vpc/vdcProviderId)
only 2 concurrent operations independent of the virtualdatacenter
this means the same result will apply with the same setup but using the default openSession.byvdc=false
{newcode}
* fast powerOn
{newcode:java}
Given
abiquo.properties:
* abiquo.virtualfactory.vmx_04.openSession=1
* abiquo.virtualfactory.vmx_04.openSession.faststatechanges=true
a esx-vcenter private datacenter (with or without device)
2 virtualdatacenters
When
deploy a vapp with +1 vm in each vdc
Then
only one configure operation concurrently, but all powerOn after the configure of the vm (regardless if performing other powerOns or other vm configure)
{newcode}
* fast powerOn during configure
{newcode:java}
Given
abiquo.properties:
* abiquo.virtualfactory.vmx_04.openSession=1
* abiquo.virtualfactory.vmx_04.openSession.faststatechanges=true
a esx-vcenter private datacenter (with or without device)
When
deploy a vapp with +1 vms
powerOn/powerOff/reset/pause or resume another vm (same vdc or not)
Then
only one configure operation concurrently, but the state change in the other vm is executed immediately
{newcode}