- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Configuring automation capabilities
- Solutions
- Audit
- Settings
- Cloud robots
- Robot units calculus example
- Robot Units consumption of automatic VM pools
- Configuring VPN for cloud robots
- Configuring an ExpressRoute connection
- Live streaming and remote control
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Business Rules
- Storage Buckets
- Indexes
- Orchestrator testing
- Resource Catalog Service
- Integrations
- Troubleshooting
Orchestrator user guide
Robot Units consumption of automatic VM pools
When defining the automatic machine template, make sure you have enough robot units (RUs)on your machines.
If you do not have enough RUs, the following consumption restrictions apply:
-
If your robot units do not match to the maximum number of VMs defined in the pool, we delete all machines in the pool and stop creating new ones until you allocate enough robot units to support the maximum number of machines.
Note: Instead of adding more robot units, we recommend reducing the maximum number of VMs in the pool. - A job running on a machine that does not have enough RUs generates the following alert "No VMs in <Pool_name> due to insufficient robot units."
- As soon as enough robot units become available, they are automatically consumed.
- If you have multiple pools in an overconsumption state, we allocate any available robot units to the last created pool subsets.
Example: You have five pools, each having a maximum of three machines, totaling 15 machines. Your RUs can support two machines, meaning all five pools are now in an overconsumption state, so you cannot use them.
- You add the required RUs to support five more machines. Now, you can use a total of seven machines.
- Two pools become available and they consume RUs for six machines (two pools of three machines each).
- Three pools remain in the overconsumption state, and the available RUs serve one machine. Therefore, the two pools are created last.
Once automatic pools are created, the allocated RUs are consumed based on their monthly distribution. Automatic renewal applies if RUs are available.
When a VM is deleted from a manual pool, or when an automatic pool is deleted, the corresponding RUs are released in the following 24 hours.
-
For the remaining of the current contract month, you can reuse the released RUs in the same tenant.
-
For the following months, remaining RUs can be used across tenants.
For example, you aquired a bundle of 72,000 RUs for one-year contract, which starts on January 1st and ends on December 31st. The following timeline enfolds:
-
January 1st - you create VM1 in tenant T1, which consumes 6000 RUs.
-
January 15th - you delete VM1 from tenant T1.
-
January 16th - the 6000 RUs are released and you can reuse them to create VM2 in the same tenant T1.
-
February 1st - you keep the same VM2 running in tenant T1, and this consumes another 6000 RUs from your bundle, based on the monthly distribution. You are left with 60,000 RUs (72,000 minus 6000 for January and 6000 for February).
-
February 15th - you keep the same VM2 in tenant T1, but you create two more VMs in two different tenants, T2 and T3. This consumes 12,000 RUs from the remaining 60,000: one for the VM in tenant T2, and one for the VM in tenant T3. You are left now with 48,000 RUs.
