Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
5 changes: 5 additions & 0 deletions English/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,11 @@
* [Getting started](vserver/compute-hcm03-1a/getting-started/README.md)
* [UserData](vserver/compute-hcm03-1a/getting-started/userdata.md)
* [Quota Limit](vserver/compute-hcm03-1a/quota-limit.md)
* [Scheduled O&M](vserver/compute-hcm03-1a/operation-and-maintenance/README.md)
* [Activate the O&M service](vserver/compute-hcm03-1a/operation-and-maintenance/activate-the-service.md)
* [Create and manage Scheduled Tasks](vserver/compute-hcm03-1a/operation-and-maintenance/create-and-manage-scheduled-tasks.md)
* [Monitor execution history](vserver/compute-hcm03-1a/operation-and-maintenance/monitor-execution-history.md)
* [Quota and FAQ](vserver/compute-hcm03-1a/operation-and-maintenance/quota-and-faq.md)
* [Instance](vserver/compute-hcm03-1a/instance/README.md)
* [Connect to virtual server](vserver/compute-hcm03-1a/instance/connect-to-virtual-server/README.md)
* [Connecting a Windows Server by Remote Desktop (RDP)](vserver/compute-hcm03-1a/instance/connect-to-virtual-server/2.-remote-desktop-to-windows-server-hcm-03.md)
Expand Down
14 changes: 14 additions & 0 deletions English/overview/product-updates-all/2026.md
Original file line number Diff line number Diff line change
Expand Up @@ -153,6 +153,20 @@ For more details about the updated renewal mechanism and policy, please refer [h
{% endtab %}

{% tab title="New features" %}

**Aug 2026**

**vServer - Scheduled O&M (Beta): schedule automated VM operations**

vServer introduces **Operation and Maintenance (O&M) — Scheduled Task** in Beta, letting you schedule **START**, **STOP** and **REBOOT** operations on your virtual machines at a fixed time instead of performing them manually every day.

* Schedule runs **daily** at the hour and minute you choose, within an effective window (start date — end date).
* Select targets by **VM list** or by **tag** (`tag_key`/`tag_value`) — VMs tagged later are picked up automatically with no need to update the task.
* Full task lifecycle management: create, update, duplicate, cancel, delete, plus **Run now** to execute without waiting for the schedule.
* **Execution history down to each VM**: success/failure status with a specific error message, filterable by status and trigger type.
* One-time **Activate**: the system provisions a dedicated Service Account per user with least-privilege permissions, so scheduled operations run securely under your own identity.
* Available in **HCM-03** and **HAN-01**; default quota of **20 tasks per account**.
* Learn more at [Scheduled O&M](../../vserver/compute-hcm03-1a/operation-and-maintenance/).
**Jul 2026**

**VKS - GreenNode CLI**
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# Scheduled O&M

vServer **Operation and Maintenance (O&M) — Scheduled Task** lets you schedule routine operations on your virtual machines (VMs) automatically, instead of performing them by hand every day. You define it once — which action (Start, Stop or Reboot), on which VMs, at what time — and the system carries it out on schedule and records the result of every run.

{% hint style="info" %}
**Note:** This is a **Beta** release for early-access customers. Features may be adjusted or extended based on your feedback.
{% endhint %}

## Benefits

* **Cost savings:** automatically shut down dev/test VMs outside working hours and start them again the next morning.
* **Less manual work:** no need to remember the time or have someone on duty to start/stop servers every day.
* **Consistent operations:** reboot application VMs on a regular cadence to refresh resources.
* **Full transparency:** every run keeps a detailed history down to each VM — whether it succeeded or failed, and why.

## Common use cases

| Scenario | How to use Scheduled Task |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Dev/test environments used only in office hours | Create two tasks: STOP at 19:00 and START at 07:00 daily for VMs tagged `env=dev` |
| Applications that need periodic restarts | Create a REBOOT task daily during off-peak hours (for example 03:00) |
| Nightly batch jobs on a dedicated VM | START the VM at 22:00 to run the job, STOP it at 05:00 once the job finishes |

## Beta scope

* Supported actions: **START**, **STOP**, **REBOOT**.
* Schedule frequency: **daily**, at the hour and minute you choose.
* Available regions: **HCM-03** and **HAN-01**.

## Concepts and terminology

| Term | Meaning |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Scheduled Task** | A scheduled job: the action, the list of targets (VMs/tags), the schedule and the effective time window. |
| **Action** | The operation performed on a VM: START / STOP / REBOOT. |
| **Target** | The VMs affected by the task. Selected directly by VM or indirectly by tag. |
| **Tag** | A key/value label on a VM (for example `env=dev`). A tag-based task applies to every VM carrying that tag at run time. |
| **Execution** | One run of a task (scheduled or manual), with an aggregate status and per-VM results. |
| **Trigger** | How an execution starts: **SCHEDULED** (at the scheduled time) or **MANUAL** (you clicked "Run now"). |
| **Service Account** | A dedicated service account the system creates for you at activation, used to perform scheduled operations securely. |
| **Quota** | The maximum number of Scheduled Tasks your account can create. |
| **Region** | The infrastructure region where the VMs run (HCM-03, HAN-01). Each task belongs to a single region. |

## How it works

You define tasks in the Portal; the O&M scheduler watches them and triggers them on time; the action is applied to your VMs through vServer; the outcome is written to the execution history for you to review at any time.

<figure><img src="../../../.gitbook/assets/vserver-om-operating-model.png" alt=""><figcaption><p>Scheduled O&#x26;M operating model</p></figcaption></figure>

Three notable design points:

* **Definition is separate from execution:** you can create or edit tasks at any time; the system takes care of running them at the scheduled moment.
* **Actions run on your behalf, under your own identity:** every operation uses a Service Account dedicated to your account with least-privilege permissions — never a shared account.
* **Everything is recorded:** each run produces a history entry with results down to the individual VM.

## Beta limitations

| Area | Current (Beta) | Roadmap |
| ----------------- | ------------------------------------------- | ---------------------------------------------- |
| Schedule frequency| Daily | Hourly / weekly / monthly to be added |
| Actions | START / STOP / REBOOT | Additional operations under evaluation |
| Region scope | One region per task (HCM-03, HAN-01) | More regions per the product roadmap |
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Activate the O&M service

## Prerequisites

* A VNG Cloud account with access to the vServer Portal.
* At least one running VM in region **HCM-03** or **HAN-01**.
* Permission to use the O&M feature (if you use a sub-account through IAM, the corresponding permissions must be granted).

## Activation (one time only)

Before creating your first Scheduled Task you need to activate the service. The process is fully automatic and takes only a few seconds.

<figure><img src="../../../.gitbook/assets/vserver-om-activation-flow.png" alt=""><figcaption><p>O&#x26;M service activation flow</p></figcaption></figure>

1. Go to **Operation & Maintenance (O&M)** in the vServer Portal.
2. Click **Activate**. The system creates a dedicated Service Account for your account and attaches a least-privilege operations policy.
3. Once the status turns **ACTIVE**, you can start creating tasks.

## Activation statuses

| Status | Meaning | What you should do |
| ------------------- | --------------------------------------------------------------------------- | --------------------------------------------- |
| **NOT\_ACTIVATED** | The service has not been activated yet | Click **Activate** |
| **ACTIVE** | The service is ready | Use it normally |
| **SA\_BROKEN** | The Service Account is broken (for example deleted or its permissions changed) | Click **Re-activate** to let the system repair it |

{% hint style="info" %}
**Note:** While the service is not activated, or the Service Account is broken, you can still view your task list and execution history. Only create/update/delete/run operations are temporarily blocked until activation succeeds.
{% endhint %}
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
# Create and manage Scheduled Tasks

## Create a Scheduled Task

1. Go to **O&M** and choose **Create Scheduled Task**.
2. Enter a name and description for the task.
3. Select the region that holds the target VMs (**HCM-03** or **HAN-01**).
4. Choose the action: **START**, **STOP** or **REBOOT**.
5. Set the daily schedule: hour and minute.
6. Set the effective window: start date and end date.
7. Select the targets: a list of specific VMs, or a tag.
8. Confirm. The task becomes **ACTIVE** and waits for its scheduled time.

### Parameters

| Parameter | Required | Description and constraints |
| --------------------------------- | -------- | ------------------------------------------------------------------------------------------- |
| Task name (`name`) | Yes | 5–50 characters; letters, digits and the characters `_` `-` `.` only; no spaces. |
| Description (`description`) | No | A note about the purpose of the task. |
| Region | Yes | HCM-03 or HAN-01. The task only affects VMs in this region. |
| Action (`action`) | Yes | START / STOP / REBOOT. |
| Schedule (`schedule`) | Yes | Daily frequency; choose the hour (0–23) and minute (0–59). |
| Effective from (`effective_from`) | Yes | The moment the task becomes eligible to run. |
| Effective until (`effective_until`)| Yes | After this moment the task no longer runs. |
| Targets (`targets`) | Yes | A list of VMs (instances) or a list of tags (key/value). |

### Choosing targets: by VM or by tag?

| Criterion | By VM (instance) | By tag |
| ---------------------- | ----------------------------------- | ---------------------------------------------------------- |
| How you select | Name each VM explicitly | Specify a tag key/value pair |
| Scope | Fixed to the selected list | Dynamic: every VM carrying the tag at run time |
| VMs added later | You must update the task | Automatically included once the tag is applied |
| Best for | A small, stable set of VMs | Groups that change often (dev/test, autoscaling) |

{% hint style="warning" %}
**Important:** With tag-based tasks, manage your tags carefully — applying the wrong tag means that VM will be stopped or rebooted on the task's schedule.
{% endhint %}

### Example: shut down dev VMs outside working hours

Goal: VMs tagged `env=dev` in HCM-03 stop at 19:00 and start again at 07:00 the next morning, through the end of 2026.

| Parameter | Task 1 — evening shutdown | Task 2 — morning startup |
| --------------- | --------------------------- | --------------------------- |
| Name | `stop-dev-19h` | `start-dev-07h` |
| Region | HCM-03 | HCM-03 |
| Action | STOP | START |
| Schedule | Daily at 19:00 | Daily at 07:00 |
| Effective window| 2026-08-01 → 2026-12-31 | 2026-08-01 → 2026-12-31 |
| Targets | tag `env=dev` | tag `env=dev` |

## How the system runs a task

Once created, the task is **ACTIVE** and continuously monitored. At the scheduled time — or when you click **Run now** — an execution starts.

<figure><img src="../../../.gitbook/assets/vserver-om-task-lifecycle.png" alt=""><figcaption><p>Scheduled Task lifecycle — from creation to each individual run</p></figcaption></figure>

### Built-in safeguards

* **Reconcile before running:** the system re-checks the target list against vServer immediately before each execution. VMs that have been deleted are dropped from the task automatically, so they never produce errors in the history.
* **No duplicate runs:** each scheduled moment executes exactly once, even if the system is busy or restarts.
* **Per-VM isolation:** a failure on one VM does not stop the others; each VM's result is recorded separately.
* **Automatic expiry:** once past the effective end date, the task stops on its own — no need to remove the schedule manually.

### Run now (manual trigger)

Besides the automatic schedule, you can click **Run now** to execute a task immediately — useful for verifying a task you just created, or handling an unplanned situation. Manual runs are recorded in the history with trigger type **MANUAL** and do not affect the next scheduled run.

{% hint style="info" %}
**Note:** There is a cooldown between two consecutive **Run now** actions on the same task to prevent duplicate operations. If you click too quickly, the system tells you how many seconds to wait.
{% endhint %}

## Managing tasks

### Management operations

| Operation | Description | Condition |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
| List / view details | View all your tasks with their configuration, targets and next run time | Always available |
| Update | Change the name, description, action, schedule, effective window and targets; you may also change the region (which then requires selecting new targets) | Task is **ACTIVE** |
| Duplicate | Create a new task from an existing configuration — just change the name and adjust the differences | Service activated; quota available |
| Run now (Trigger) | Execute immediately without waiting for the schedule | Task is **ACTIVE** |
| Cancel | Stop the task's schedule; the task becomes **CANCELED** and its history is preserved | Task is **ACTIVE** |
| Delete | Remove the task from your list and release its quota | Task is no longer ACTIVE — **Cancel** it first |

### Task statuses

| Status | Meaning |
| -------------- | ------------------------------------------------------------------------------------ |
| **ACTIVE** | Running on schedule within its effective window |
| **CANCELED** | Cancelled — no longer runs, but its history remains viewable |
| **EXPIRED** | Past its effective end date — the system sets this automatically and the task stops |

{% hint style="success" %}
**Tip:** Cancel and Delete are different — Cancel keeps the task and its full history for reference, while Delete removes the task entirely and releases the quota. An ACTIVE task must be cancelled before it can be deleted.
{% endhint %}
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
# Monitor execution history

Every time a task runs — whether on schedule or manually — the system creates an execution record. You can browse the executions of each task (paginated, filterable by status and trigger type) and drill down into the result for each individual VM.

## Aggregate status of an execution

<figure><img src="../../../.gitbook/assets/vserver-om-execution-status.png" alt=""><figcaption><p>Execution status model</p></figcaption></figure>

| Status | Meaning |
| -------------------- | ------------------------------------------------------------------------------------ |
| **PENDING** | Recorded and queued for processing |
| **RUNNING** | Currently executing across the target VMs |
| **SUCCESS** | Every VM succeeded |
| **PARTIAL\_FAILED** | Some VMs succeeded and some failed — open the details to see why |
| **FAILED** | Every VM failed |
| **SKIPPED** | The run was deliberately skipped (for example a precondition was not met) — with a note |

## Per-VM details

Within an execution, each VM has its own record: the status (**SUCCESS** / **FAILED** / **SKIPPED**), the timestamp, and a specific error message if it failed (for example the VM no longer exists, or the VM is in a state that does not allow the operation). This lets you pinpoint the cause without guesswork.
Loading
Loading