Before you begin
Confirm account, tenant and active role in the account menu. Inspection requires view permission; changing records requires the specific management permission. A hidden or disabled action can reflect authorized scope; do not switch tenants to evade a denial. Work only with records in the workspace you are allowed to administer.
Procedure
- In Cloud workers use Connections to configure and verify the cloud account and authorized regions.
- In Profiles define vCPU, Memory and Disk.
- In Workers choose Provision worker, review tenant, connection, region and profile, then confirm once.
- Check Provisioning history for the outcome. In Workers use Refresh to update the provider observation.
- Open More actions in the row or the DOVA_DATA_GRID context menu for authorized actions. The row shortcut opens View details; Columns lets you display the optional Runtime column.
Behavior and limits
There are four tabs: Workers, Provisioning history, Connections and Profiles. Google Cloud, AWS and Azure are connection types; each operation depends on actual provider capabilities and your permissions.
Status shows the VM state observed in the cloud: Running, Stopped or Paused. In GCP, Paused corresponds to SUSPENDED. It can also show transitions such as Starting or Stopping. Unknown or Unavailable means there is no verifiable observation; Last known identifies an earlier state that could not be refreshed. These states do not establish a recent heartbeat or available capacity.
The optional Runtime column shows the worker process and job admission: Online, Offline, Draining or Disabled. Enable it from Columns. It is independent of VM state: Running does not guarantee that the worker is Online. Pause scheduling stops new assignments and lets active work finish; Resume scheduling enables assignments again. These actions do not suspend or resume the provider VM.
The row menu and controls beside Worker name offer actions according to observed state and authorization. Start VM starts a Stopped VM and Resume VM resumes a Paused VM when supported by the provider. A default, busy or public worker can block Stop VM. A public worker shares capacity; it never makes its consumer Session or data public.
Reset VM forcibly restarts a Running GCP VM and requires confirmation. Before submitting it to the provider, the server checks again for active jobs, runs and reservations across every tenant authorized to use that worker. A default or public worker can be reset when this complete check confirms it is idle; its references and sharing policy are retained. The action appears only for compatible providers and states.
While a Reset has no confirmed outcome, Dova blocks new assignments and another Reset. The main status still describes the VM; Reset pending or Check reset reports the operation separately. Use Refresh to check its result without submitting it again. Only a completed native operation and a valid observation can resolve the block; a Running VM alone does not prove Reset completion. A confirmed Reset does not guarantee process readiness: Runtime waits for the next heartbeat.
Inspect Tenant, Public, Status, Slots and Last seen. Configured and available slots can differ because of physical admission. A price estimate is neither an invoice guarantee nor confirmation of available capacity.
GCP worker networking
New GCP workers are provisioned with private IP addresses only; no public IP selector is offered. Configure Cloud NAT in the subnet region so the worker can reach Dova over HTTPS and download packages and dependencies from Debian, PyPI and GitHub. Private Google Access supports access to Google APIs, but does not replace Cloud NAT for those external destinations. Also check DNS and the outbound rules required by authorized connectors.
For maintenance, use IAP SSH with OS Login when the required IAM roles and firewall rules are configured. The worker pulls jobs and sends heartbeats through outbound connections; it does not need an inbound application port to receive them.
The public_shared policy shares capacity among authorized tenants; it is independent of whether the VM has a public IP address. Preserve isolation for each job and the scope of its credentials and data.
Verify the result
After saving or confirming, reopen the detail and check the state reported by the server. Distinguish an accepted request from a completed operation and retain only minimal evidence without sensitive information. When an operation is pending, wait for its final state in the corresponding view before starting another action on the same object.
Laboratory example
Use the synthetic tenant documentation-lab and, where relevant, worker worker-demo-a. Note the previous state, perform one authorized action and compare the resulting state. These names illustrate the procedure; they do not identify production records or authorize creating cloud resources. For a review without changes, inspect the detail and cancel any open form.
If something fails
If a conflict appears, use Refresh and review current values before starting another action. If Reset pending or Check reset appears, use Refresh to inspect the operation; do not repeat Reset to resolve it. If the provider confirms a failure, inspect its safe message and the refreshed state before deciding on another action. If the session expired, sign in and complete MFA when required. For a permission error, check the role and membership. Do not alter storage, revisions or controls to force an outcome.
Related reading
Provider-synchronized VM controls
In the row menu, Pause VM suspends a Running GCP VM and produces Paused (SUSPENDED). Resume VM resumes a Paused VM; Start VM starts a Stopped VM and Stop VM stops it. Reset VM restarts a Running VM while retaining its registration. Dova verifies current state and ownership before sending an action and checks the native result; an accepted request is not a completed operation.
Pause VM differs from Pause scheduling: the former suspends the VM; the latter stops job admission and lets active work finish. After Start, Resume or Reset, Runtime needs an authenticated heartbeat to confirm the process is Online. Incompatible actions are disabled during an operation or while jobs and dependencies prevent it.
GCP provides these native controls according to state. Azure offers Start, Stop and Deprovision; Pause and Reset are not presented as equivalent operations. AWS can appear as a connection type, but its VM lifecycle is unavailable in this edition.
Remove a VM and recover assignments
Open Remove VM and unlink, review resource identity and impact on Sessions, executions and pools, then confirm the intended deletion. For a supported owned VM, manually dismantling every reference or first powering it off is not a prerequisite for this operation. Removing capacity can interrupt active executions; schedule the operation to suit your needs.
After confirming provider absence, Dova retires the active worker, clears Runtime references and shows Unassigned for Session bindings that used it. Definitions, published versions, configuration and audit history are preserved. If the VM is deleted directly in the provider, reconciliation applies the same treatment after verifying absence. A provider-read error is not evidence that the VM was deleted.
Before running again, select compatible authorized capacity and review the environment pool. Unassigned does not silently choose another worker. You can provision a new VM and assign it explicitly. Permissions, resource ownership, the protected base server and pending operations remain checked; removal does not bypass these protections.
Environment context
Before using this module, confirm Tenant, Domain and Environment in the user menu. The initial environment is Development. Module, Domain and environment capabilities apply together; Production is read only without explicit authorization. Switching the selector does not move artifacts or publish or execute their data. See environments and recovery and environment promotion.
Environment worker pool
In Configuration → Dova Integration Runtime, Environment worker pool identifies the current environment. Allowed workers assigns existing workers; Default worker must belong to that selection. Pool policy starts as Dedicated. Select Shared only when you explicitly want to share capacity and every participating pool also declares Shared. A matching name does not share a physical worker.
Save environment pool changes only the selected environment’s policy and neither starts a job nor changes the tenant’s global default. The review uses a configuration fingerprint; if another user changes it, Refresh pool lets you reload and review before saving. Controls require configuration and environment Runtime administration. Built-in is not offered as an execution worker.
Without an explicit pool, Production does not borrow Development capacity and new jobs do not run through an implicit default. Legacy execution can retain an earlier worker only when the server verifies the exact published chain, configuration and permitted membership. Test and Stage consume the plan’s Development bucket; Production uses the Production bucket. Pool membership does not replace capacity, online status, profile compatibility, quotas or concurrency.
Before stopping or retiring capacity
Pause VM and Stop VM retain active-work, default-worker and shared-capacity checks; review references and impact before using them. Pause scheduling stops new assignments and lets current work finish. To retire the VM permanently, use Remove VM and unlink and review its confirmation: after verifying cloud absence, Dova clears assignments and shows Unassigned without deleting definitions or published versions. Assign compatible capacity explicitly before running again.
Actions require the module permission and the relevant environment’s Runtime capability, or an explicitly granted global permission. A shared VM requires authorization across all its environments.
Resources and permissions per environment
Tenant and Environment selected in the user menu scope Cloud workers, their cloud connections, provisioning profiles, operations and dependency backups. A Domain declared on a resource must also match. Overview, resource history and operational Audit events respect this scope. Users, roles, tenants and billing retain their own authority: they are not independent copies per environment.
Managing a VM requires the module permission plus etl.environments.<environment>.runtime.manage, or the global Runtime permission when explicitly granted. If multiple environments share the VM, you need authorization in every affected environment. Switching the selector neither moves a VM nor expands permissions.
Compact controls follow cloud state
Beside Worker name, the Pause, Start/Resume, Stop and Reset icons show VM actions. Read each icon’s tooltip. Start is available for a Stopped VM and Resume for a Paused VM when the provider and your permissions allow it. The worker process being Offline does not by itself prevent starting a powered-off VM.
Dova checks current cloud state and authorized actions. A stale observation, pending operation, active work or permission restriction can disable a control. After Start, Resume or Reset, wait for the provider result and the worker heartbeat; VM Running and Runtime Online are separate checks. If the result is uncertain, use Refresh before repeating the action.
Observe provider changes
GCP provides Start, Stop, Pause/Suspend, Resume, Reset and VM removal according to state. Azure provides Start, Stop/Deallocate and removal; Pause/Resume/Reset are not presented as equivalent operations. AWS VM lifecycle is not enabled in this edition. Visible capabilities depend on the provider and effective authorization.
Provider synchronization is periodic. Changes made directly in the cloud appear after a new valid observation; this is not an instant notification across the fleet. Check observation time and use Refresh to query state. An accepted operation does not prove completion, and a Running VM still needs a heartbeat for Runtime Online.