Skip to content

API Reference#

VM Lifecycle Management API Overview

Key Points

  • Complete REST API for virtual machine lifecycle management and automation
  • Programmatically create, configure, manage, and delete VMs using HTTP endpoints
  • Four-stage API workflow: Creation → Power Management → Configuration → Advanced Operations
  • Comprehensive API documentation optimized for developers and automation tools

Stage: API Overview (Entry Point) Input: Developer requirements, automation needs Output: Guided workflow to specific API documentation Navigation Path: - Start here → Choose specific operation → Follow detailed guides - Complete lifecycle: Creation → Power → Configuration → Advanced

This Document Helps With

  • "VM API overview and getting started"
  • "REST API workflow for VM management"
  • "API endpoint reference and navigation"
  • "Developer onboarding for VergeOS APIs"
  • "Infrastructure as code planning"
  • "Automation workflow design"
  • "API integration guidance"
  • "VM management automation strategy"

API Workflow Stages

1. VM Creation API

Create virtual machines programmatically with drives, devices, and network interfaces using REST API calls. → See: VM-Creation-API.md

2. VM Power Management API

Start, stop, reboot, and monitor VM power states through API endpoints. → See: VM-Power-Management.md

3. VM Configuration API

Modify CPU, RAM, storage drives, and network settings via API calls. → See: VM-Configuration.md

4. Advanced VM Operations API

Clone VMs, create snapshots, delete virtual machines, and troubleshoot issues using API methods. → See: VM-Advanced-Operations.md

Key API Concepts

  • VM Key vs Machine Key: API distinction for VM settings vs hardware operations
  • REST API Authentication: Bearer token authentication required for all API calls
  • Resource Groups: UUID-based API parameters for device passthrough (GPUs, PCI devices)
  • Storage Tiers: API-configurable performance levels (1-5) for drive placement
  • HTTP Methods: GET, POST, PUT, DELETE operations for complete VM lifecycle management

Primary API Endpoints

API Operation HTTP Method REST Endpoint Purpose
Create VM POST /api/v4/vms Create new virtual machine
VM Actions POST /api/v4/vm_actions Power operations, clone, snapshot
Update VM PUT /api/v4/vms/{id} Modify VM configuration
Add Storage POST /api/v4/machine_drives Attach drives to VM
Add Network POST /api/v4/machine_nics Configure network interfaces
Add Devices POST /api/v4/machine_devices Attach GPU/PCI devices
Delete VM DELETE /api/v4/vms/{id} Remove virtual machine
VM Status GET /api/v4/vms/{id} Query VM information
Power State GET /api/v4/machine_status/{id} Check runtime status

API Quick Reference by Stage

Stage Primary Operations Key Endpoints Documentation
Creation Create VM, Add drives, Add NICs, Add devices POST /api/v4/vms, POST /api/v4/machine_* VM-Creation-API.md
Power Start, Stop, Reboot, Monitor POST /api/v4/vm_actions, GET /api/v4/machine_status VM-Power-Management.md
Config Update CPU/RAM, Manage drives, Manage NICs PUT /api/v4/vms, POST/PUT/DELETE /api/v4/machine_* VM-Configuration.md
Advanced Clone, Snapshot, Delete, Troubleshoot POST /api/v4/vm_actions, DELETE /api/v4/vms VM-Advanced-Operations.md

Common API Error Scenarios

  • Authentication Issues: Invalid API key, expired tokens, insufficient permissions
  • Resource Constraints: Insufficient storage, memory limits, CPU quotas exceeded
  • Configuration Errors: Invalid parameters, missing required fields, malformed JSON
  • State Conflicts: VM already running, operation in progress, resource locked
  • Network Issues: API timeout, connection refused, service unavailable
  • Validation Errors: Invalid VM names, unsupported configurations, constraint violations

API Getting Started Guide

  1. Create VMs: VM-Creation-API.md - REST API calls to create virtual machines
  2. Power Control: VM-Power-Management.md - API endpoints to start, stop, and manage VMs
  3. Configure VMs: VM-Configuration.md - API methods to modify VM settings and hardware
  4. Advanced Operations: VM-Advanced-Operations.md - API calls for cloning, backup, and troubleshooting

Common API Use Cases

  • Automated VM Provisioning: Create VMs programmatically for cloud automation
  • Infrastructure as Code: Manage virtual machine infrastructure through API calls
  • DevOps Integration: Integrate VM management into CI/CD pipelines using REST APIs
  • Monitoring and Alerting: Query VM status and power states via API endpoints
  • Backup and Recovery: Automate VM snapshots and cloning through API operations
  • Resource Management: Programmatically manage VM CPU, memory, and storage allocation

API Authentication

All VM lifecycle API endpoints require authentication:

curl -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     https://your-vergeos.example.com/api/v4/vms

Start with the VM Creation API documentation to begin automating your virtual machine management workflows.

VM Advanced Operations API

Key Points

  • Clone VMs with complete configuration and drive copying
  • Create and restore VM snapshots for backup and recovery
  • Safely delete VMs with automatic resource cleanup
  • Comprehensive error handling and troubleshooting guidance

This guide covers advanced virtual machine operations in VergeOS, including cloning, snapshot management, deletion, and troubleshooting. These operations provide powerful capabilities for VM lifecycle management and disaster recovery.

Stage: VM Advanced Operations (4 of 4) Input: VM key (42), operation type, parameters Output: Cloned VMs, snapshots, cleanup confirmation Previous: VM configured → VM-Configuration.md Common Operations: - Clone for templates → New VM creation cycle - Snapshot for backup → Recovery workflows - Delete for cleanup → End of lifecycle

This Document Helps With

  • "How to clone VMs via API"
  • "Creating VM snapshots and backups"
  • "Restoring VMs from snapshots"
  • "Safely deleting VMs and cleanup"
  • "VM troubleshooting and diagnostics"
  • "Template creation workflows"
  • "Disaster recovery operations"
  • "Bulk VM management"
  • "Resource cleanup automation"

Quick Reference

Primary Endpoints

  • VM Actions: POST /api/v4/vm_actions
  • VM Deletion: DELETE /api/v4/vms/{vm_key}
  • VM Listing: GET /api/v4/vms

Key Actions

  • clone: Create complete VM copy
  • snapshot: Create VM snapshot
  • restore: Restore from snapshot

Authentication

-H "Authorization: Bearer YOUR_API_KEY"
-H "Content-Type: application/json"

Prerequisites

VM must exist → See VM-Creation-API.md

API Quick Reference

Operation Method Endpoint Key Type Purpose
Clone VM POST /api/v4/vm_actions VM key Create complete copy
Create Snapshot POST /api/v4/vm_actions VM key Point-in-time backup
Restore Snapshot POST /api/v4/vm_actions VM key Recovery operation
List Snapshots GET /api/v4/vms Filter query Find snapshots
Delete VM DELETE /api/v4/vms/{id} VM key Complete removal
VM Status GET /api/v4/vms/{id} VM key Configuration check
Operation Status GET /api/v4/machine_status/{id} Machine key Runtime monitoring

Troubleshooting Index

  • 409 Conflict: Clone name exists, VM already running, operation in progress
  • 507 Insufficient Storage: Not enough space for clone, snapshot storage full
  • 403 Forbidden: API key permissions, VM access denied, cluster restrictions
  • 404 Not Found: VM not found, snapshot not found, invalid VM key
  • 408 Request Timeout: Clone operation timeout, snapshot creation timeout
  • 422 Unprocessable Entity: Invalid clone parameters, snapshot restore conflict
  • 500 Internal Server Error: Storage system issues, hypervisor problems, cluster failures

VM Cloning

POST /api/v4/vm_actions

Description: Creates a complete copy of a VM including all drives and configuration.

Basic Clone

{
  "params": {
    "name": "test clone",
    "quiesce": "true"
  },
  "action": "clone",
  "vm": "42"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "params": {
      "name": "test clone",
      "quiesce": "true"
    },
    "action": "clone",
    "vm": "42"
  }'

Response Example:

{
  "response": {
    "vmkey": "43",
    "machinekey": "55",
    "machinestatuskey": "55",
    "clusterkey": "1"
  }
}

Advanced Clone Options

{
  "params": {
    "name": "production-clone",
    "description": "Production server clone for testing",
    "preserve_macs": "true",
    "preserve_device_uuids": "true",
    "quiesce": "true",
    "cluster": "2"
  },
  "action": "clone",
  "vm": "42"
}

Clone Parameters

Parameter Type Required Description
name string Yes Name for the cloned VM
description string No Description for the clone
quiesce string No Quiesce VM before cloning ("true"/"false") for data consistency
preserve_macs string No Preserve MAC addresses ("true"/"false")
preserve_device_uuids string No Preserve device UUIDs ("true"/"false")
cluster string No Target cluster ID

Clone Options

  • Quiesce: Use "quiesce": "true" to ensure data consistency by pausing the VM briefly
  • Preserve MACs: Use "preserve_macs": "true" to keep the same MAC addresses (may cause network conflicts)
  • Preserve Device UUIDs: Use "preserve_device_uuids": "true" to maintain device identifiers
  • Cross-Cluster: Specify different cluster ID to clone to another cluster

Clone Workflow Example

# Step 1: Create clone
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "params": {
      "name": "backup-clone-$(date +%Y%m%d)",
      "description": "Automated backup clone",
      "quiesce": "true"
    },
    "action": "clone",
    "vm": "42"
  }'

# Step 2: Verify clone creation (using returned vmkey)
curl "https://your-vergeos.example.com/api/v4/vms/43?fields=name,description,created" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Step 3: Check clone power state
curl "https://your-vergeos.example.com/api/v4/machine_status/55?fields=powerstate,status" \
  -H "Authorization: Bearer YOUR_API_KEY"

VM Snapshots

Creating Snapshots

{
  "vm": "42",
  "action": "snapshot",
  "params": {
    "name": "pre-update-snapshot",
    "description": "Before system update"
  }
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vm": "42",
    "action": "snapshot",
    "params": {
      "name": "pre-update-snapshot",
      "description": "Before system update - $(date)"
    }
  }'

Restoring from Snapshots

{
  "vm": "42",
  "action": "restore",
  "params": {
    "snapshot_id": "snapshot-67890"
  }
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vm": "42",
    "action": "restore",
    "params": {
      "snapshot_id": "snapshot-67890"
    }
  }'

Listing VM Snapshots

GET /api/v4/vms

Use filters to find snapshots:

curl "https://your-vergeos.example.com/api/v4/vms?filter=is_snapshot%20eq%20true%20and%20name%20contains%20'web-server'" \
  -H "Authorization: Bearer YOUR_API_KEY"

Find All Snapshots for a VM:

curl "https://your-vergeos.example.com/api/v4/vms?filter=is_snapshot%20eq%20true%20and%20parent_vm%20eq%2042" \
  -H "Authorization: Bearer YOUR_API_KEY"

Snapshot Management Workflow

# Step 1: Create snapshot before maintenance
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vm": "42",
    "action": "snapshot",
    "params": {
      "name": "maintenance-snapshot-$(date +%Y%m%d-%H%M)",
      "description": "Pre-maintenance snapshot"
    }
  }'

# Step 2: List snapshots to find snapshot ID
curl "https://your-vergeos.example.com/api/v4/vms?filter=is_snapshot%20eq%20true%20and%20parent_vm%20eq%2042&fields=name,description,created" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Step 3: Restore if needed (after maintenance issues)
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vm": "42",
    "action": "restore",
    "params": {
      "snapshot_id": "found-snapshot-id"
    }
  }'

VM Deletion and Cleanup

Complete VM Deletion

DELETE /api/v4/vms/{vm_key}

Description: Deletes a VM and automatically removes all associated resources including drives, NICs, devices, and configurations.

curl -X DELETE "https://your-vergeos.example.com/api/v4/vms/42" \
  -H "Authorization: Bearer YOUR_API_KEY"

Response: 200 OK on successful deletion.

Automatic Cleanup

When you delete a VM using DELETE /api/v4/vms/{vm_key}, VergeOS automatically removes:

  • All drives attached to the VM
  • All network interfaces (NICs)
  • All devices (GPU, PCI passthrough, USB, TPM, etc.)
  • VM configuration and metadata
  • Cloud-init files and configurations
  • VM notes and documentation
  • Associated machine resources

Pre-Deletion Considerations

Before deleting a VM, consider:

  1. Data Backup: Ensure important data is backed up
  2. Snapshots: VM snapshots may be deleted with the VM
  3. Dependencies: Check if other systems depend on this VM
  4. Network Configuration: Note any special network configurations
  5. Licensing: Consider software licensing implications

Safe Deletion Process

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "kill",
    "vm": "42"
  }'
Step 2: Verify Power State
curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=powerstate" \
  -H "Authorization: Bearer YOUR_API_KEY"
Step 3: Create Final Backup (Optional)
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "params": {
      "name": "final-backup-before-deletion",
      "description": "Final backup before VM deletion"
    },
    "action": "clone",
    "vm": "42"
  }'
Step 4: Delete VM and All Resources
curl -X DELETE "https://your-vergeos.example.com/api/v4/vms/42" \
  -H "Authorization: Bearer YOUR_API_KEY"

VM Key Usage

Use the VM key (e.g., 42) from the VM creation response or VM listing, not the machine key. The deletion process automatically handles all associated machine resources.

No Manual Cleanup Required

Unlike some virtualization platforms, VergeOS handles complete resource cleanup automatically. You do not need to manually:

  • Delete individual drives
  • Remove network interfaces
  • Detach devices
  • Clean up configuration files
  • Remove machine status entries

The single DELETE /api/v4/vms/{vm_key} operation handles all cleanup automatically.

Finding Orphaned Resources

# Find drives without associated machines
curl "https://your-vergeos.example.com/api/v4/machine_drives?filter=machine%20eq%20null" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Find NICs without associated machines
curl "https://your-vergeos.example.com/api/v4/machine_nics?filter=machine%20eq%20null" \
  -H "Authorization: Bearer YOUR_API_KEY"

Error Handling and Troubleshooting

Common Error Scenarios

VM Creation Failures

Error: 400 Bad Request - Invalid machine type

{
  "error": "Invalid machine_type 'invalid-type'. Valid options: pc, q35, pc-i440fx-*, pc-q35-*"
}

Solution: Use valid machine types from the supported list.

Power State Conflicts

Error: 409 Conflict - VM already running

{
  "error": "Cannot power on VM: already in running state"
}

Solution: Check current power state before issuing power commands.

Resource Constraints

Error: 507 Insufficient Storage

{
  "error": "Insufficient storage space in tier 3 for requested disk size"
}

Solution: Choose different storage tier or reduce disk size.

Clone Failures

Error: 409 Conflict - Clone name already exists

{
  "error": "VM with name 'test clone' already exists"
}

Solution: Use unique names for cloned VMs.

Monitoring VM Operations

Checking Operation Status

Many VM operations are asynchronous. Monitor progress using:

# Check VM status
curl "https://your-vergeos.example.com/api/v4/vms/42?fields=machine%23status" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Check machine status for runtime information
curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=status,powerstate" \
  -H "Authorization: Bearer YOUR_API_KEY"
Operation Timeouts

Set appropriate timeouts for long-running operations:

  • VM Creation: 5-10 minutes
  • Clone Operations: 10-30 minutes (depending on size)
  • Snapshot Creation: 2-5 minutes
  • Snapshot Restore: 5-15 minutes
  • Power State Changes: 30-60 seconds
  • VM Deletion: 2-5 minutes

Retry Logic

Implement retry logic for transient failures:

import time
import requests

def wait_for_operation_completion(vm_id, max_retries=20):
    """Wait for VM operation to complete"""
    for attempt in range(max_retries):
        response = requests.get(
            f"https://your-vergeos.example.com/api/v4/vms/{vm_id}",
            params={"fields": "machine#status#status as operation_status"},
            headers={"Authorization": "Bearer YOUR_API_KEY"}
        )

        status = response.json().get("operation_status", "")
        if status not in ["cloning", "snapshotting", "restoring"]:
            return True

        time.sleep(10)  # Wait 10 seconds between checks

    return False

# Example usage
if wait_for_operation_completion("42"):
    print("Operation completed successfully")
else:
    print("Operation timed out")

Debugging VM Issues

Check VM Configuration
# Get complete VM configuration
curl "https://your-vergeos.example.com/api/v4/vms/42?fields=most" \
  -H "Authorization: Bearer YOUR_API_KEY"
Check Machine Status
# Get runtime status and errors
curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=most" \
  -H "Authorization: Bearer YOUR_API_KEY"
Check System Resources
# Check cluster resources
curl "https://your-vergeos.example.com/api/v4/clusters/1?fields=resources" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Check storage tiers
curl "https://your-vergeos.example.com/api/v4/storage_tiers" \
  -H "Authorization: Bearer YOUR_API_KEY"

Best Practices

  1. Always test operations in development environments first
  2. Create snapshots before major changes
  3. Monitor resource usage during operations
  4. Implement proper error handling in automation scripts
  5. Use descriptive names for clones and snapshots
  6. Clean up unused resources regularly
  7. Document operational procedures for your team

Related Operations

Need Help?

For additional support with VM advanced operations: - Check the VergeOS documentation portal - Contact VergeOS support with specific error messages - Review system logs for detailed error information - Consult the VergeOS community forums

VM Configuration API

Key Points

  • Modify VM settings like CPU, RAM, console, and video through REST API
  • Manage drives with resizing, adding, and removal capabilities
  • Update network interfaces and their configurations
  • Add documentation notes to VMs for operational tracking

This guide covers modifying virtual machine configurations in VergeOS after creation, including CPU/RAM updates, drive management, network interface changes, and adding operational notes.

Stage: VM Configuration (3 of 4) Input: VM key (42) + Machine key (54), configuration changes Output: Updated VM settings, modified hardware Previous: VM powered on → VM-Power-Management.md Common Next Steps: - Advanced operations → VM-Advanced-Operations.md - Power cycle for changes → VM-Power-Management.md

This Document Helps With

  • "How to change VM CPU and RAM"
  • "Adding storage drives to existing VMs"
  • "Resizing VM drives and storage"
  • "Managing VM network interfaces"
  • "Adding notes and documentation to VMs"
  • "Hotplug operations and live changes"
  • "VM performance tuning"
  • "Storage expansion workflows"
  • "Network reconfiguration"

Quick Reference

Primary Endpoints

  • VM Settings: PUT /api/v4/vms/{id}
  • VM Notes: POST /api/v4/note_actions
  • Drive Management: POST/PUT/DELETE /api/v4/machine_drives
  • NIC Management: POST/PUT/DELETE /api/v4/machine_nics

Key Concepts

  • VM key: Use for VM settings (CPU, RAM, console)
  • Machine key: Use for hardware (drives, NICs, devices)
  • Hotplug: Some changes require VM restart

Authentication

-H "Authorization: Bearer YOUR_API_KEY"
-H "Content-Type: application/json"

Prerequisites

VM must be created first → See VM-Creation-API.md

API Quick Reference

Operation Method Endpoint Key Type Purpose
Update VM PUT /api/v4/vms/{id} VM key CPU, RAM, console settings
Add Note POST /api/v4/note_actions VM key Documentation
Add Drive POST /api/v4/machine_drives Machine key Storage expansion
Resize Drive PUT /api/v4/machine_drives/{id} Drive key Increase disk size
Remove Drive DELETE /api/v4/machine_drives/{id} Drive key Storage removal
Add NIC POST /api/v4/machine_nics Machine key Network interface
Update NIC PUT /api/v4/machine_nics/{id} NIC key Network changes
Remove NIC DELETE /api/v4/machine_nics/{id} NIC key Interface removal

Troubleshooting Index

  • 400 Bad Request: Invalid RAM size, invalid CPU count, malformed JSON
  • 409 Conflict: VM must be stopped, hotplug not supported, resource in use
  • 507 Insufficient Storage: Tier full, disk size too large, quota exceeded
  • 403 Forbidden: API key permissions, VM access denied, cluster restrictions
  • 422 Unprocessable Entity: Drive cannot be shrunk, invalid interface type
  • 404 Not Found: VM not found, drive not found, NIC not found, invalid vnet

CPU and RAM Updates

PUT /api/v4/vms/{id}

Description: Updates VM configuration. Uses the VM key (not machine key) for VM-level settings.

Request Body Example:

{
  "ram": 16384,
  "cpu_cores": 3,
  "console": "spice",
  "video": "qxl",
  "show_advanced": "true",
  "nested_virtualization": "true",
  "disable_hypervisor": "true"
}

Complete API Call:

curl -X PUT "https://your-vergeos.example.com/api/v4/vms/42" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ram": 16384,
    "cpu_cores": 3,
    "console": "spice",
    "video": "qxl",
    "show_advanced": "true",
    "nested_virtualization": "true",
    "disable_hypervisor": "true"
  }'

Common Configuration Parameters

Parameter Type Description Restart Required
ram integer RAM in MB Usually yes
cpu_cores integer Number of CPU cores Usually yes
console string Console type (spice, vnc, none) On next start
video string Video adapter (qxl, virtio, std, cirrus) On next start
nested_virtualization string Enable nested virtualization ("true"/"false") Yes
disable_hypervisor string Disable hypervisor ("true"/"false") Yes
guest_agent string Enable guest agent ("true"/"false") On next start
uefi string Enable UEFI boot ("true"/"false") Yes
secure_boot string Enable secure boot ("true"/"false") Yes

VM Key vs Machine Key

  • VM settings (CPU, RAM, console, video): Use VM key (e.g., 42) with /api/v4/vms/{vm_key}
  • Hardware changes (drives, NICs, devices): Use machine key (e.g., 54) with /api/v4/machine_* endpoints

Configuration Changes

  • CPU and RAM changes usually require VM restart
  • Console and video changes take effect on next VM start
  • Nested virtualization and hypervisor settings require VM restart
  • Always check allow_hotplug setting for hot-add capabilities

Adding Notes to VMs

POST /api/v4/note_actions

Description: Adds or updates notes for a VM in the VergeOS UI for documentation purposes.

Request Body:

{
  "owner": "vms/42",
  "action": "update",
  "params": {
    "text": "This is a test VM"
  }
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/note_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "owner": "vms/42",
    "action": "update",
    "params": {
      "text": "Production web server - Updated 2025-08-24"
    }
  }'

Parameters:

Name Type Required Description
owner string Yes Resource identifier (format: "vms/{vm_key}")
action string Yes Action to perform ("update")
params.text string Yes Note text content

VM Notes

Notes are visible in the VergeOS UI and help with VM documentation, maintenance schedules, or configuration details. Use the VM key (not machine key) in the owner field.

Drive Management

Adding New Drives

Use the machine drives endpoint to add storage after VM creation:

POST /api/v4/machine_drives
{
  "machine": "54",
  "name": "Data Drive",
  "interface": "virtio-scsi",
  "media": "disk",
  "disksize": 536870912000,
  "preferred_tier": "2"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/machine_drives" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "name": "Data Drive",
    "interface": "virtio-scsi",
    "media": "disk",
    "disksize": 536870912000,
    "preferred_tier": "2"
  }'

Resizing Drives

PUT /api/v4/machine_drives/{drive_id}

Description: Increases the size of an existing drive. Note that drives can only be expanded, not shrunk.

{
  "disksize": 1073741824000
}

Complete API Call:

curl -X PUT "https://your-vergeos.example.com/api/v4/machine_drives/55" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "disksize": 1073741824000
  }'

Drive Resizing

  • Drives can only be expanded, never shrunk
  • The guest OS may need to be configured to recognize the new size
  • Some file systems require manual expansion after drive resize

Removing Drives

Before deletion, drives must be hot-unplugged if the VM is running:

Step 1: Hot-Unplug Drive (if VM is running)
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vm": "42",
    "action": "hotplugdrive",
    "params": {
      "device": "drive-id-here",
      "unplug": true
    }
  }'
Step 2: Delete the Drive
DELETE /api/v4/machine_drives/{drive_id}
curl -X DELETE "https://your-vergeos.example.com/api/v4/machine_drives/55" \
  -H "Authorization: Bearer YOUR_API_KEY"

Drive Management Examples

Adding a CDROM/ISO
{
  "machine": "54",
  "media": "cdrom",
  "interface": "ahci",
  "media_source": "7"
}
Adding an Import Drive
{
  "machine": "54",
  "name": "Ubuntu Server",
  "description": "Ubuntu 22.04 LTS",
  "interface": "virtio-scsi",
  "media": "import",
  "media_source": 123,
  "preferred_tier": "3"
}

Network Interface Management

Adding NICs

POST /api/v4/machine_nics
{
  "machine": "54",
  "name": "Secondary Network",
  "interface": "virtio",
  "vnet": "8",
  "enabled": true
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/machine_nics" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "name": "Secondary Network",
    "interface": "virtio",
    "vnet": "8",
    "enabled": true
  }'

Updating NIC Configuration

PUT /api/v4/machine_nics/{nic_id}
{
  "vnet": "10",
  "enabled": true
}

Complete API Call:

curl -X PUT "https://your-vergeos.example.com/api/v4/machine_nics/78" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "vnet": "10",
    "enabled": true
  }'

Removing NICs

DELETE /api/v4/machine_nics/{nic_id}
curl -X DELETE "https://your-vergeos.example.com/api/v4/machine_nics/78" \
  -H "Authorization: Bearer YOUR_API_KEY"

NIC Configuration Parameters

Parameter Type Required Description
machine string Yes Machine ID
vnet string Yes Virtual network ID
name string No NIC name
interface string No NIC interface type (virtio, e1000, rtl8139)
enabled boolean No NIC enabled state

Virtual Network Keys

The vnet parameter uses the network's key/ID. You can find network keys by listing available networks via the networks API endpoint.

Complete Configuration Workflow

Here's an example of updating a VM's complete configuration:

# Step 1: Update VM settings (CPU, RAM, console)
curl -X PUT "https://your-vergeos.example.com/api/v4/vms/42" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "ram": 32768,
    "cpu_cores": 8,
    "console": "spice",
    "video": "virtio"
  }'

# Step 2: Add operational note
curl -X POST "https://your-vergeos.example.com/api/v4/note_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "owner": "vms/42",
    "action": "update",
    "params": {
      "text": "Upgraded to 32GB RAM and 8 cores for increased workload - 2025-08-24"
    }
  }'

# Step 3: Add additional storage
curl -X POST "https://your-vergeos.example.com/api/v4/machine_drives" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "name": "Application Data",
    "interface": "virtio-scsi",
    "media": "disk",
    "disksize": 1073741824000,
    "preferred_tier": "2"
  }'

# Step 4: Add secondary network interface
curl -X POST "https://your-vergeos.example.com/api/v4/machine_nics" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "name": "Management Network",
    "interface": "virtio",
    "vnet": "5",
    "enabled": true
  }'

Configuration Best Practices

Before Making Changes

  1. Check VM Status: Ensure VM is in appropriate state for changes
  2. Backup Important Data: Create snapshots before major changes
  3. Review Dependencies: Consider impact on running applications
  4. Plan Downtime: Some changes require VM restart

After Making Changes

  1. Verify Configuration: Check that changes were applied correctly
  2. Test Functionality: Ensure VM operates as expected
  3. Update Documentation: Add notes about configuration changes
  4. Monitor Performance: Watch for any performance impacts

Hotplug Considerations

# Check if VM supports hotplug
curl "https://your-vergeos.example.com/api/v4/vms/42?fields=allow_hotplug" \
  -H "Authorization: Bearer YOUR_API_KEY"

Hotplug Support

  • Modern guest operating systems generally support CPU and RAM hotplug
  • Drive hotplug depends on the guest OS and drive interface
  • Network interface hotplug is widely supported
  • Always test hotplug capabilities in your environment

Error Handling

Common Configuration Errors

Error: 400 Bad Request - Invalid RAM size

{
  "error": "RAM size must be at least 512 MB and at most 1048576 MB"
}

Error: 409 Conflict - VM must be stopped

{
  "error": "Cannot modify CPU cores while VM is running without hotplug support"
}

Solution: Stop the VM or check hotplug capabilities before making changes.

Error: 507 Insufficient Storage

{
  "error": "Insufficient storage space in tier 2 for requested disk size"
}

Solution: Choose different storage tier or reduce disk size.

Related Operations

Need Help?

For additional support with VM configuration: - Check the VergeOS documentation portal - Contact VergeOS support with specific error messages - Review system logs for detailed error information - Consult the VergeOS community forums

VM Power Management API

Key Points

  • Control VM power states through REST API endpoints
  • Support for graceful and forced power operations
  • Monitor VM power state and runtime status
  • Understand VM key vs Machine key for different status checks

This guide covers managing virtual machine power states in VergeOS, including starting, stopping, rebooting, and monitoring VMs. The VergeOS API provides comprehensive power management capabilities with both graceful and forced operations.

Stage: VM Power Management (2 of 4) Input: VM key (42) from creation, power operation type Output: Power state changes, runtime status Previous: VM created → VM-Creation-API.md Common Next Steps: - Configure VM settings → VM-Configuration.md - Advanced operations → VM-Advanced-Operations.md

This Document Helps With

  • "How to start/stop VMs via API"
  • "Checking VM power status"
  • "Graceful vs forced VM shutdown"
  • "VM reboot and reset operations"
  • "Monitoring VM power state"
  • "Power management automation"
  • "VM startup troubleshooting"
  • "Scheduled power operations"
  • "Resource optimization through power control"

Quick Reference

Primary Endpoints

  • Power Actions: POST /api/v4/vm_actions
  • VM Status: GET /api/v4/vms/{id}
  • Power State: GET /api/v4/machine_status/{machine_id}

Key Actions

  • poweron: Start VM
  • poweroff: Graceful shutdown (ACPI)
  • kill: Force power off
  • reset: Reboot VM

Authentication

-H "Authorization: Bearer YOUR_API_KEY"
-H "Content-Type: application/json"

Prerequisites

VM must be created first → See VM-Creation-API.md

API Quick Reference

Operation Method Endpoint Key Type Purpose
Power On POST /api/v4/vm_actions VM key Start virtual machine
Power Off POST /api/v4/vm_actions VM key Graceful shutdown (ACPI)
Force Off POST /api/v4/vm_actions VM key Immediate termination
Reboot POST /api/v4/vm_actions VM key Restart VM
VM Info GET /api/v4/vms/{id} VM key Configuration data
Power State GET /api/v4/machine_status/{id} Machine key Runtime status

Troubleshooting Index

  • 409 Conflict: VM already running, VM not running, power state mismatch
  • 507 Insufficient Resources: Not enough cluster resources, memory/CPU unavailable
  • 403 Forbidden: API key permissions, cluster access denied, VM access restricted
  • 404 Not Found: Invalid VM key, VM deleted, machine key not found
  • 408 Request Timeout: Power operation timeout, VM unresponsive, cluster communication failure
  • 500 Internal Server Error: Hypervisor issues, node problems, storage failures

Starting VMs

POST /api/v4/vm_actions

Description: Powers on a virtual machine and waits for it to reach running state.

Power On Request:

{
  "action": "poweron",
  "params": {},
  "vm": "42"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "poweron",
    "params": {},
    "vm": "42"
  }'

Response: 201 Created when action is initiated.

Best Practices

  • Always verify VM configuration before powering on
  • Ensure all required drives and network interfaces are attached
  • Check cluster resource availability
  • Verify VM is not already running to avoid conflicts

Stopping VMs

Graceful Power Off (ACPI)

Description: Sends an ACPI shutdown signal to the guest operating system, allowing it to shut down cleanly.

{
  "action": "poweroff",
  "vm": "42"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "poweroff",
    "vm": "42"
  }'

Force Power Off (Kill)

Description: Immediately terminates the VM without allowing the guest OS to shut down cleanly. Use only when graceful shutdown fails.

{
  "action": "kill",
  "vm": "42"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "kill",
    "vm": "42"
  }'

Force Power Off

Using kill action may cause data loss or corruption. Always try graceful poweroff first and only use kill when necessary.

Rebooting VMs

Graceful Reboot (ACPI)

Description: Sends an ACPI reset signal to the guest operating system for a clean restart.

{
  "action": "reset",
  "params": {
    "graceful": true
  },
  "vm": "42"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "reset",
    "params": {
      "graceful": true
    },
    "vm": "42"
  }'

Hard Reset (Power Cycle)

Description: Immediately restarts the VM without allowing the guest OS to shut down cleanly.

{
  "action": "reset",
  "vm": "42"
}

Complete API Call:

curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "reset",
    "vm": "42"
  }'

VM Status and Information

GET /api/v4/vms/{id}

Description: Retrieves VM configuration and metadata using various field filters.

Get Complete VM Information:

curl "https://your-vergeos.example.com/api/v4/vms/42?fields=most" \
  -H "Authorization: Bearer YOUR_API_KEY"

Response Example:

{
  "$key": 42,
  "name": "test",
  "machine": 54,
  "description": "test vm",
  "enabled": true,
  "created": 1755991665,
  "modified": 1755993248,
  "is_snapshot": false,
  "machine_type": "pc-q35-9.0",
  "allow_hotplug": true,
  "guest_agent": true,
  "cpu_cores": 3,
  "cpu_type": "host",
  "ram": 16384,
  "console": "spice",
  "video": "qxl",
  "sound": "none",
  "os_family": "linux",
  "rtc_base": "utc",
  "boot_order": "cd",
  "console_pass_enabled": false,
  "usb_tablet": true,
  "uefi": true,
  "secure_boot": false,
  "serial_port": false,
  "boot_delay": 5,
  "uuid": "821e96ec-2479-7cc4-7c14-c623557bdd2b",
  "need_restart": false,
  "console_status": 42,
  "cloudinit_datasource": "none",
  "imported": false,
  "created_from": "custom",
  "migration_method": "auto",
  "note": "This is a test VM",
  "power_cycle_timeout": 0,
  "allow_export": true,
  "creator": "admin",
  "nested_virtualization": true,
  "disable_hypervisor": true,
  "usb_legacy": false
}

VM Power State and Runtime Status

GET /api/v4/machine_status/{machine_id}

Description: Retrieves the actual runtime status and power state of a VM using the machine key.

Check VM Power State:

curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=most" \
  -H "Authorization: Bearer YOUR_API_KEY"

Stopped VM Response Example

{
  "$key": 54,
  "machine": 54,
  "running": false,
  "migratable": true,
  "node": null,
  "migrated_node": null,
  "migration_destination": null,
  "started": 1755993338,
  "local_time": 0,
  "status": "stopped",
  "status_info": "",
  "state": "offline",
  "powerstate": false,
  "last_update": 1755993358,
  "running_cores": 3,
  "running_ram": 16384,
  "agent_version": "",
  "agent_features": [],
  "agent_guest_info": []
}

Running VM Response Example

{
  "$key": 44,
  "machine": 44,
  "running": true,
  "migratable": true,
  "node": 3,
  "migrated_node": null,
  "migration_destination": null,
  "started": 1755460982,
  "local_time": 0,
  "status": "running",
  "status_info": "",
  "state": "online",
  "powerstate": true,
  "last_update": 1755993927,
  "running_cores": 6,
  "running_ram": 12288,
  "agent_version": "",
  "agent_features": [],
  "agent_guest_info": []
}

VM vs Machine Status

  • VM Information (/api/v4/vms/{vm_key}): Configuration, settings, and metadata
  • Power State (/api/v4/machine_status/{machine_key}): Runtime status, power state, and resource usage
  • Always use the machine key (not VM key) to check actual power state and runtime status

Status Fields

  • powerstate: Boolean indicating if VM is powered on
  • running: Boolean indicating if VM is currently running
  • status: Text status ("running", "stopped", etc.)
  • state: Overall state ("online", "offline")
  • node: Which physical node the VM is running on (null if stopped)

Power State Monitoring

Checking Power State Only

For quick power state checks, you can request specific fields:

# Check just the power state
curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=powerstate,running,status" \
  -H "Authorization: Bearer YOUR_API_KEY"

Response:

{
  "powerstate": true,
  "running": true,
  "status": "running"
}

Monitoring Power State Changes

import time
import requests

def wait_for_power_state(machine_id, desired_state, max_retries=10):
    """Wait for VM to reach desired power state"""
    for attempt in range(max_retries):
        response = requests.get(
            f"https://your-vergeos.example.com/api/v4/machine_status/{machine_id}",
            params={"fields": "powerstate,running,status"},
            headers={"Authorization": "Bearer YOUR_API_KEY"}
        )

        data = response.json()
        if data.get("powerstate") == desired_state:
            return True

        time.sleep(5)  # Wait 5 seconds between checks

    return False

# Example usage
if wait_for_power_state("54", True):
    print("VM is now running")
else:
    print("VM failed to start within timeout")

Common Power Management Workflows

Safe VM Shutdown Workflow

# Step 1: Attempt graceful shutdown
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "poweroff", "vm": "42"}'

# Step 2: Wait and check status (repeat as needed)
sleep 30
curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=powerstate,status" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Step 3: Force shutdown if graceful failed (after reasonable timeout)
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"action": "kill", "vm": "42"}'

VM Restart Workflow

# Step 1: Graceful reboot
curl -X POST "https://your-vergeos.example.com/api/v4/vm_actions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "reset",
    "params": {"graceful": true},
    "vm": "42"
  }'

# Step 2: Monitor restart progress
curl "https://your-vergeos.example.com/api/v4/machine_status/54?fields=powerstate,status,node" \
  -H "Authorization: Bearer YOUR_API_KEY"

Error Handling

Common Power Management Errors

Error: 409 Conflict - VM already running

{
  "error": "Cannot power on VM: already in running state"
}
Solution: Check current power state before issuing power commands.

Error: 409 Conflict - VM not running

{
  "error": "Cannot power off VM: not in running state"
}
Solution: Verify VM is actually running before attempting shutdown.

Error: 507 Insufficient Resources

{
  "error": "Insufficient cluster resources to start VM"
}
Solution: Check cluster resource availability or reduce VM resource requirements.

Operation Timeouts

Set appropriate timeouts for power operations:

  • Power On: 30-60 seconds
  • Graceful Shutdown: 60-120 seconds
  • Force Shutdown: 10-30 seconds
  • Reboot: 60-120 seconds

Related Operations

Need Help?

For additional support with VM power management: - Check the VergeOS documentation portal - Contact VergeOS support with specific error messages - Review system logs for detailed error information - Consult the VergeOS community forums

VM Creation API

Key Points

  • Create VMs with essential configuration parameters using REST API
  • Support for recipe-based VM creation with complex configurations
  • Add drives, devices, and network interfaces after VM creation
  • Understand VM key vs Machine key distinctions for different operations

This guide covers creating virtual machines in VergeOS, from basic VM creation through adding drives, devices, and network interfaces. The VergeOS API provides comprehensive endpoints for VM creation and hardware configuration.

Stage: VM Creation (1 of 4) Input: API credentials, cluster info, VM specifications Output: VM key (42) + Machine key (54) Next: Use keys for power management Common Next Steps: - Power on VM → VM-Power-Management.md - Configure settings → VM-Configuration.md - Advanced operations → VM-Advanced-Operations.md

This Document Helps With

  • "How to create a VM via API"
  • "Adding drives during VM setup"
  • "Attaching GPU/PCI devices to VMs"
  • "VM creation with cloud-init"
  • "Understanding VM vs machine keys"
  • "Setting up network interfaces for new VMs"
  • "Recipe-based VM provisioning"
  • "Bulk VM creation automation"
  • "Infrastructure as code VM deployment"

Quick Reference

Primary Endpoints

  • Create VM: POST /api/v4/vms
  • Add Drive: POST /api/v4/machine_drives
  • Add Device: POST /api/v4/machine_devices
  • Add NIC: POST /api/v4/machine_nics

Key Parameters

  • name: VM identifier (required)
  • cluster: Target cluster ID
  • machine: Machine ID from VM creation (for hardware additions)
  • resource_group: UUID for device passthrough

Authentication

-H "Authorization: Bearer YOUR_API_KEY"
-H "Content-Type: application/json"

Next Steps

After VM creation → Power Management (VM-Power-Management.md)

API Quick Reference

Operation Method Endpoint Key Type Purpose
Create VM POST /api/v4/vms Returns both Initial creation
Add Drive POST /api/v4/machine_drives Machine key Hardware
Add Device POST /api/v4/machine_devices Machine key GPU/PCI passthrough
Add NIC POST /api/v4/machine_nics Machine key Network interface
Power On POST /api/v4/vm_actions VM key Control
Check Status GET /api/v4/machine_status/{id} Machine key Monitor

Troubleshooting Index

  • 409 Conflict: VM name exists, already running, permission denied
  • 400 Bad Request: Invalid parameters, missing required fields, invalid JSON
  • 507 Insufficient Storage: Tier full, reduce size, choose different tier
  • 403 Forbidden: API key permissions, cluster access denied
  • 404 Not Found: Invalid cluster ID, missing media source, invalid resource group
  • 422 Unprocessable Entity: Invalid drive interface, unsupported media type

Prerequisites

  • Valid VergeOS API credentials with VM management permissions
  • Understanding of VergeOS concepts: clusters, vnets, media sources, and resource groups
  • Basic knowledge of REST API principles and JSON formatting

Authentication

All VM creation operations require authentication using either:

  • API Key: Include in the Authorization header as Bearer YOUR_API_KEY
  • Basic Authentication: Username and password for interactive sessions
  • Session Token: For web-based integrations
# Using API Key
curl -H "Authorization: Bearer YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     https://your-vergeos.example.com/api/v4/vms

Basic VM Creation

POST /api/v4/vms

Description: Creates a new virtual machine with the specified configuration.

Request Parameters:

Name Type Required Description
name string Yes Unique VM name
description string No VM description
cluster string No Target cluster ID (numeric string)
ram integer No RAM in MB (default: 1024)
cpu_cores integer No Number of CPU cores (default: 1)
guest_agent string No Enable guest agent ("true"/"false")
console_pass_hash string No Console password hash (empty string if not used)
video string No Video adapter type (virtio, std, cirrus, etc.)
rtc_base string No RTC base setting (utc, localtime)
uefi string No Enable UEFI boot ("true"/"false")

Request Body Example:

{
  "name": "web-server-01",
  "description": "Production web server",
  "cluster": "1",
  "ram": 8192,
  "cpu_cores": 4,
  "guest_agent": "true",
  "console_pass_hash": "",
  "video": "virtio",
  "rtc_base": "utc",
  "uefi": "true"
}

Response Example:

{
  "location": "/v4/vms/42",
  "dbpath": "vms/42",
  "$row": 42,
  "$key": "42",
  "response": {
    "machine": "54"
  }
}

Response Fields:

Field Type Description
location string API endpoint for the created VM
dbpath string Database path for the VM record
$row integer Database row number
$key string VM ID (used for subsequent API calls)
response.machine string Machine ID (used for drives, NICs, devices)

Error Responses: - 400 Bad Request: Invalid configuration parameters - 409 Conflict: VM name already exists - 403 Forbidden: Insufficient permissions

VM Key vs Machine Key

  • VM key (e.g., "42"): Use for VM settings like CPU, RAM, console
  • Machine key (e.g., "54"): Use for hardware like drives, NICs, devices
  • You get both keys in the VM creation response

Recipe-Based VM Creation

VergeOS supports complex VM creation using recipes that include drives, network interfaces, and devices.

Complete VM with Recipe Configuration

{
  "name": "enterprise-vm",
  "description": "Enterprise application server",
  "cluster": "1",
  "cpu_cores": 8,
  "ram": 16384,
  "guest_agent": "true",
  "video": "virtio",
  "rtc_base": "utc",
  "uefi": "true",
  "secure_boot": "true",
  "console_pass_hash": "",
  "cloudinit_datasource": "nocloud",
  "cloudinit_files": [
    {
      "name": "user-data",
      "contents": "#cloud-config\nusers:\n  - name: admin\n    sudo: ALL=(ALL) NOPASSWD:ALL\n    ssh_authorized_keys:\n      - ssh-rsa AAAAB3NzaC1yc2E..."
    },
    {
      "name": "meta-data",
      "contents": "instance-id: enterprise-vm-001\nlocal-hostname: enterprise-vm"
    }
  ]
}

Adding Drives

Drives must be created separately after VM creation using the machine drives endpoint.

POST /api/v4/machine_drives

Request Parameters:

Name Type Required Description
machine string Yes Machine ID from VM creation
name string No Drive name
media string No Media type (disk, cdrom, import, clone, efidisk)
interface string No Drive interface (virtio-scsi, ide, ahci, etc.)
disksize integer No Disk size in bytes (for new disks)
preferred_tier string No Storage tier (1-5)
media_source string No Source media ID (for import/clone/cdrom)
show_pt string No Override Preferred Tier ("true"/"false") - overrides media source's default tier

Creating a Boot Drive

{
  "machine": "54",
  "name": "OS Drive",
  "media": "disk",
  "interface": "virtio-scsi",
  "disksize": 2199023255552,
  "preferred_tier": "1"
}

Response Example:

{
  "location": "/v4/machine_drives/54",
  "dbpath": "machine_drives/54",
  "$row": 54,
  "$key": "54"
}

Attaching CDROM/ISO

{
  "machine": "54",
  "media": "cdrom",
  "interface": "ahci",
  "media_source": "7"
}

Response Example:

{
  "location": "/v4/machine_drives/55",
  "dbpath": "machine_drives/55",
  "$row": 55,
  "$key": "55"
}

Importing from Media Source

{
  "machine": "54",
  "name": "Ubuntu Server",
  "description": "Ubuntu 22.04 LTS",
  "interface": "virtio-scsi",
  "media": "import",
  "media_source": 123,
  "preferred_tier": "3"
}

Adding Devices (GPU, PCI Passthrough, etc.)

POST /api/v4/machine_devices

Description: Attaches hardware devices like GPUs, PCI devices, USB devices, or TPM to a virtual machine.

Request Parameters:

Name Type Required Description
machine string Yes Machine ID
resource_group string Yes Resource group UUID for the device
settings_args object No Device-specific settings (empty object for basic passthrough)

PCI Passthrough GPU

{
  "machine": "54",
  "resource_group": "1f67f07e-f653-db95-c475-01b8a2ea0ff1",
  "settings_args": {}
}

Response Example:

{
  "location": "/v4/machine_devices/2",
  "dbpath": "machine_devices/2",
  "$row": 2,
  "$key": "2",
  "response": {
    "uuid": "934e250b-a13c-bd8f-104d-a31995b06eba"
  }
}

Finding Resource Groups

The resource_group parameter identifies the specific hardware device to attach. Use these endpoints to find available resource group UUIDs:

  • GET /api/v4/resource_groups - General hardware devices (GPUs, PCI devices, USB, etc.)
  • GET /api/v4/node_nvidia_vgpu_devices - NVIDIA vGPU devices specifically

Finding Available Devices

# General hardware devices
curl "https://your-vergeos.example.com/api/v4/resource_groups" \
  -H "Authorization: Bearer YOUR_API_KEY"

# NVIDIA vGPU devices
curl "https://your-vergeos.example.com/api/v4/node_nvidia_vgpu_devices" \
  -H "Authorization: Bearer YOUR_API_KEY"

Adding Network Interfaces

POST /api/v4/machine_nics

Request Parameters:

Name Type Required Description
machine string Yes Machine ID
vnet string Yes Virtual network ID (key of the target network)
name string No NIC name
interface string No NIC interface type (virtio, e1000, etc.)
enabled boolean No NIC enabled state

Example:

{
  "machine": "54",
  "vnet": "3"
}

Response Example:

{
  "location": "/v4/machine_nics/78",
  "dbpath": "machine_nics/78",
  "$row": 78,
  "$key": "78"
}

Virtual Network Keys

The vnet parameter uses the network's key/ID. For example, vnet "3" might be your external network. You can find network keys by listing available networks via the networks API endpoint.

Complete VM Creation Example

Here's a complete workflow for creating a VM with drives, devices, and network interfaces:

# Step 1: Create the VM
curl -X POST "https://your-vergeos.example.com/api/v4/vms" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "production-server",
    "description": "Production application server",
    "cluster": "1",
    "ram": 16384,
    "cpu_cores": 8,
    "guest_agent": "true",
    "video": "virtio",
    "uefi": "true"
  }'

# Response: VM key = 42, Machine key = 54

# Step 2: Add boot drive
curl -X POST "https://your-vergeos.example.com/api/v4/machine_drives" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "name": "Boot Drive",
    "media": "disk",
    "interface": "virtio-scsi",
    "disksize": 107374182400,
    "preferred_tier": "1"
  }'

# Step 3: Add network interface
curl -X POST "https://your-vergeos.example.com/api/v4/machine_nics" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "vnet": "3"
  }'

# Step 4: Add GPU (optional)
curl -X POST "https://your-vergeos.example.com/api/v4/machine_devices" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "machine": "54",
    "resource_group": "1f67f07e-f653-db95-c475-01b8a2ea0ff1",
    "settings_args": {}
  }'

Related Operations

Need Help?

For additional support with VM creation: - Check the VergeOS documentation portal - Contact VergeOS support with specific error messages - Review system logs for detailed error information - Consult the VergeOS community forums

API Guide

Overview

The VergeOS API allows developers to interact with the VergeOS system programmatically. It provides access to system operations such as creating virtual machines, managing resources, and interacting with billing and catalog repositories. The API uses standard REST-like conventions and supports multiple authentication methods. This guide provides an overview of the VergeOS API, endpoint documentation, example requests, and error handling.

This document outlines the usage of the API. Detailed information for the API can be found within the VergeOS UI as a Swagger documentation page, which is dynamically generated and shows a complete listing of available API tables and operations.

Swagger Interface

To access the Swagger documentation in the VergeOS UI:

  1. Login to the VergeOS system with valid credentials.
  2. From the Main Dashboard, click System in the left menu.
  3. In the System Dashboard, find the API Documentation link at the bottom left and click it.
  4. The Swagger documentation page will open. This page provides detailed examples for each API operation, including the ability to test the API directly.

Swagger Documentation Example

  1. Select an individual table and choose one of the available GET/POST/DELETE/PUT options to view and test API actions.

  2. Specify the parameters and click the Execute Button to run the API command. This will return the response, which includes the response body, header, and a curl example.

API Basics

HTTP Methods

The VergeOS API uses standard HTTP methods like GET, POST, PUT, and DELETE for resource manipulation.

GET Parameters

  • fields: Specify which fields to return in the result set.
  • filter: Filter the result set based on certain criteria.
  • sort: Sort the results by a specified field.
  • limit: Limit the number of returned results.

Authentication

All API requests must be made over HTTPS and require authentication using basic access authentication or a session token.

Additional Notes

  • Rate Limits: The API supports a maximum of 1000 requests per hour per API key.
  • Data Formats: All responses are returned in JSON format.
  • Pagination: Endpoints that return large sets of data support pagination using offset and limit query parameters.

Authentication

VergeOS supports two methods of authentication:

  1. Basic HTTP Authentication
    The API is available only through SSL.

  2. Token-based Authentication
    Developers must request a token from the API by posting to the /sys/tokens endpoint. The token is then passed in subsequent API requests in the x-yottabyte-token header.

Example Authentication Request

To obtain a token:

curl --header "X-JSON-Non-Compact: 1" --basic --data-ascii '{"login": "USERNAME", "password": "PASSWORD"}' --insecure --request "POST" --header 'Content-Type: application/json' 'https://your-verge-instance.com/api/sys/tokens'

Example response:

{
   "location":"\\/sys\\/tokens\\/3a334563456378845634563b7b82d2efcadce9",
   "dbpath":"tokens\\/3a334563456378845634563b7b82d2efcadce9",
   "$row":1,
   "$key":"3a334563456378845634563b7b82d2efcadce9"
}

Use the token from the "$key" field in all subsequent requests:

x-yottabyte-token: 3a334563456378845634563b7b82d2efcadce9

To log out, send a DELETE request to the /sys/tokens/{token} endpoint.

Example Logout Request

DELETE /sys/tokens/3a334563456378845634563b7b82d2efcadce9

Example Virtual Machines

The VMs section of the VergeOS API allows users to manage virtual machines programmatically. It includes endpoints to list, create, modify, and delete VMs.

Retrieve a List of Virtual Machines

Endpoint:
GET /v4/vms?fields=most

Description:
Retrieves a list of all VMs in the system with details such as CPU cores, RAM, machine type, and configuration details.

Example Request:

curl -X 'GET' \
  'https://your-verge-instance.com/api/v4/vms?fields=most' \
  -H 'accept: application/json' \
  -H 'x-yottabyte-token: <your-token>'

Example Response:

[
  {
    "$key": 1,
    "name": "CentOS 7 (Latest) 1.0-7",
    "machine": 7,
    "cpu_cores": 2,
    "cpu_type": "Cascadelake-Server",
    "ram": 2048,
    "os_family": "linux",
    "is_snapshot": true,
    "boot_order": "cd",
    "rtc_base": "utc",
    "console": "vnc",
    "uefi": false,
    "secure_boot": false,
    "serial_port": true,
    "uuid": "d3914756-4ec5-9dfe-5c45-b28af2fd3d73",
    "created": 1724435418,
    "modified": 1724435418
  }
]

Overview of the Data Returned:

  • $key: The unique identifier for the VM.
  • name: The name of the virtual machine.
  • machine: Machine ID associated with the VM.
  • cpu_cores: Number of CPU cores allocated to the VM.
  • ram: Amount of RAM allocated (in MB).
  • os_family: Operating system type.
  • uuid: Universally unique identifier (UUID) for the VM.
  • created: The creation timestamp.
  • modified: The last modified timestamp.

Create a New Virtual Machine

Endpoint:
POST /v4/vms

Description:
Creates a new virtual machine with specific configuration details, such as CPU cores, RAM, machine type, boot order, etc.

Example Request:

curl -X 'POST' \
  'https://your-verge-instance.com/api/v4/vms' \
  -H 'accept: application/json' \
  -H 'x-yottabyte-token: <your-token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "rest",
    "description": "test",
    "machine_type": "pc-q35-9.0",
    "allow_hotplug": true,
    "cpu_cores": 1,
    "cpu_type": "Broadwell",
    "ram": 1024,
    "os_family": "linux",
    "boot_order": "cd",
    "uefi": false,
    "note": "test vm"
  }'

Example Response:

{
  "location": "/v4/vms/36",
  "dbpath": "vms/36",
  "$row": 36,
  "$key": "36"
}

Overview of the Data Returned:

  • location: The location of the newly created VM resource.
  • dbpath: Database path of the new VM.
  • $row: Row ID of the VM.
  • $key: Unique key for the VM.

Example Virtual Networks (Vnets)

The Vnets section of the VergeOS API allows users to manage virtual networks (Vnets) programmatically. It includes endpoints to retrieve, create, and manage network resources, including internal and external networks, and allows advanced options like rate limiting.

Retrieve Vnet Details

Endpoint:
GET /v4/vnets?fields=most

Description:
Retrieves a list of all Vnets in the system with details such as network type, MTU, DHCP settings, and DNS configuration.

Example Request:

curl -X 'GET' \
  'https://your-verge-instance.com/api/v4/vnets?fields=most' \
  -H 'accept: application/json' \
  -H 'x-yottabyte-token: <your-token>'

Example Response:

[
  {
    "$key": 6,
    "name": "Internal Test 1",
    "advanced_options": {
      "dnsmasq": [
        "--dhcp-boot=netboot.xyz.kpxe,,192.168.10.20",
        "--dhcp-match=set:efi-x86,option:client-arch,6",
        "--dhcp-boot=tag:efi-x86,netboot.xyz.efi,,192.168.10.20",
        "--dhcp-match=set:efi-x86_64,option:client-arch,7",
        "--dhcp-boot=tag:efi-x86_64,netboot.xyz.efi,,192.168.10.20",
        "--dhcp-match=set:efi-x86_64,option:client-arch,9",
        "--dhcp-boot=tag:efi-x86_64,netboot.xyz.efi,,192.168.10.20"
      ]
    },
    "type": "internal",
    "layer2_type": "vxlan",
    "network": "192.168.100.0/24",
    "mtu": 9000,
    "dhcp_enabled": true,
    "dhcp_start": "192.168.100.100",
    "dhcp_stop": "192.168.100.200",
    "rate_limit": 0,
    "rate_limit_type": "mbytes/second",
    "gateway": ""
  }
]

Overview of the Data Returned:

  • $key: The unique identifier for the Vnet.
  • name: Name of the virtual network.
  • advanced_options: Advanced options to be passed to services running inside the network, in this example netboot flags for dnsmasq
  • type: Network type (e.g., "internal").
  • layer2_type: The type of Layer 2 networking, such as VXLAN.
  • network: Network CIDR block.
  • mtu: Maximum Transmission Unit (MTU) size.
  • dhcp_enabled: Indicates whether DHCP is enabled for this network.
  • dhcp_start: Starting IP address for the DHCP pool.
  • dhcp_stop: Ending IP address for the DHCP pool.
  • rate_limit: Rate limit for the network (in mbytes/second).
  • gateway: The default gateway for the network.

Create an Internal Network with Rate Limiting

Endpoint:
POST /v4/vnets

Description:
Creates a new internal virtual network with rate limiting and DHCP settings.

Example Request:

curl -X 'POST' \
  'https://your-verge-instance.com/api/v4/vnets' \
  -H 'accept: application/json' \
  -H 'x-yottabyte-token: <your-token>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name":"int1",
    "description":"workloads",
    "type":"internal",
    "mtu":"9000",
    "network":"192.168.80.0/24",
    "gateway":"192.168.80.1",
    "dnslist":"1.1.1.1",
    "dhcp_enabled": true,
    "rate_limit": 100,
    "rate_limit_burst": 500,
    "dhcp_start":"192.168.80.100",
    "dhcp_stop":"192.168.80.200"
  }'

Example Response:

{
  "location": "/v4/vnets/8",
  "dbpath": "vnets/8",
  "$row": 8,
  "$key": "8"
}

Overview of the Data Returned: - location: The location of the newly created Vnet resource. - dbpath: Database path of the new Vnet. - \(row**: Row ID of the Vnet. - **\)key: Unique key for the Vnet.


Resources

Below is an example URL used to query a list of machines.

Example: https://user1:xxxxxx@server1.verge.io/api/v4/machines?fields=all

https:// user : password @ server /api /v4/machines ? filter=&fields=all&sort=&limit=
User name User Password Server host name or IP Resource location (URI) These options are described below

GET Options

Fields
  • Specify which fields to return in the result set (may also be a view if there is one defined for the table schema).
  • all returns every field.
  • most returns most fields except for argument fields and rows.
  • summary returns fields marked as 'summary' in their schema.
  • Example: fields=name,email,enabled,groups[all] as all_groups,collapse(groups[name]) as first_groups_name

Field functions: - collapse - datetime - upper - lower - count - diskspace - display - hex - sha1 - sum - avg - min - max

Filter
  • Filter result sets by specified criteria.
  • Similar to OData.
  • Example: filter=enabled eq true and size gt 1048576.
  • Example: filter=cputype eq 'qemu' or cputype eq 'kvm'.
Operator Description
eq Equal
ne Not equal
gt Greater than
ge Greater than or equal
lt Less than
le Less than or equal
bw Begins with
ew Ends with
and Logical and
or Logical or
cs Contains string (case sensitive)
ct Contains text (case insensitive)
rx Regex match
Sort
  • Sort results by the specified field.
  • Example: sort=+name.
  • Example: sort=-id.
Limit
  • limit (integer) limits the result set to a specified number of entries. A value of 0 means unlimited.
  • Example: limit=1.

Generic HTTP Response Codes

  • 400 - Bad Request: The request was invalid.
  • 401 - Failed Login / Login Required: Authentication failed or is required.
  • 403 - Permission Denied: You lack the required permissions.
  • 404 - Resource Not Found: The requested row or API does not exist.
  • 405 - Not Permitted: The operation is not allowed.
  • 409 - Row Exists: The resource already exists.
  • 422 - Failed Validation / Invalid Parameter: Validation failed.
  • 500 - Internal Server Error: An unhandled error occurred.
POST-Specific
  • 201 - Created: A new row/resource was successfully created.
Websocket-Specific (Used for VNC/SPICE)
  • 101 - Switching Protocols: The protocol was successfully switched.
PUT/GET/DELETE
  • 200 - Success: The operation completed successfully.

Schema Table Definitions

Field Types
  • bool
  • text
  • string
  • num
  • uint8
  • uint16
  • uint32
  • uint64
  • int8
  • int16
  • int32
  • int64
  • enabled
  • created
  • created_ms
  • created_us
  • modified
  • modified_ms
  • modified_us
  • filename
  • filesize
  • fileused
  • fileallocated
  • filemodified
  • json
  • row
  • rows
Schema Owner / Parent Field
  • Owner Field: If the owner field is null, normal permissions apply. If the owner field has a value, permissions are replaced by a permission check to the owner.
  • Parent Field: The permission check is applied to the row itself, and if permissions fail, permissions are also checked on the parent row.

Full Table Schema

To retrieve a table’s schema, append $table to the URI:

/api/v4/machines/$table (replace "machines" with the table name).

You will be prompted for your credentials; this requires VergeOS admin credentials. The output will be in JSON format. Firefox displays this in a readable format by default, but other browsers may require exporting the JSON to an external program for better readability.


Example Errors

Example Error (HTTP Code 422)
{
  "err": "Validation error on field: 'dhcp_start' - 'fails validation test'"
}

VergeOS uses standard HTTP status codes to indicate the result of an API request.

  • 400 Bad Request: The request is invalid or cannot be processed.
  • 401 Unauthorized: The API key is missing or invalid.
  • 403 Forbidden: The API key lacks the required permissions.
  • 404 Not Found: The resource does not exist.
  • 500 Internal Server Error: A server error occurred.

Document Information

  • Last Updated: 2024-11-14
  • vergeOS Version: 4.12.6

API Tables Description

The following is a brief description of each of the API tables. To find out more details, add /#swagger to the end of your VergeUI's URL (or navigate to System->API Documentation). Swagger provides detailed information about each table and allows you to test each method with a Get/Post/Put/Delete action. For more instructions on how to integrate with the API, refer to the API Documentation page.

API Tables

auth_source_states

Provides a list of auth source states.

auth_sources

Authorization sources table for managing authorization sources like OpenID or AzureAD.

billing

Used to get billing information for the current environment. This is stored as billing data with a from->to date.

billing_actions

Used to send billing actions. The main action is "generate," which creates a new bill.

  • Fields:
  • action : See action list below.

  • Actions:

  • generate : Generate bill

  • Example:

URL: '/v4/billing_actions'
POST(JSON): {"action": "generate"}

catalog_logs

Logs specific to Catalogs.

catalog_repositories

Catalog repositories and sublists for catalogs, logs, permissions, etc.

catalog_repository_actions

Used to send Catalog Repository Actions.

  • Fields:
  • repository : Row ID for the repository you want to refresh.
  • action : Default action is refresh. See action list below.

  • Actions:

  • refresh : Refresh the Catalog Repository.

  • Example:

URL: '/v4/catalog_repository_actions'
POST(JSON): {"repository": 1, "action": "refresh"}

catalog_repository_logs

View and post Catalog Repository Logs.

catalog_repository_status

Used to store and update the Catalog Repository statuses. These determine the state and status of a Catalog Repository.

catalogs

Catalogs table allowing you to update/post/delete Catalogs.

certificates

SSL Certificates for your site.

clone_iso

Stores information and status of the Verge.io Clone ISO program.

clone_iso_actions

Actions for the Clone ISO feature.

  • Fields:
  • action : Default is "update." See action list below.

  • Actions:

  • update : Update the ISO image.
  • delete : Delete the ISO image.
  • cancel : Cancel the current build.

  • Example:

URL: '/v4/clone_iso_actions'
POST(JSON): {"action": "update"}

cloud_restore

Stores information when a Cloud Restore is performed.

cloud_snapshot_actions

Actions for the Cloud Snapshot feature.

cloud_snapshot_tenant_actions

Actions for the Cloud Snapshot feature for a Tenant.

cloud_snapshot_tenants

Cloud Snapshots for a Tenant.

cloud_snapshot_vm_actions

Actions for a VM and Cloud Snapshots.

cloud_snapshot_vms

Used to store information when a Cloud Snapshot is downloaded to a VM.

cloud_snapshots

The Cloud Snapshots table includes information about the Cloud Snapshot, as well as a list of VMs, Tenants, and Sync Queues. This can be used to see what VMs are included in a Cloud Snapshot.

cloudinit_files

Operations for the Cloudinit Files feature.

cluster_actions

Cluster Actions is used to send actions for Clusters.

  • Fields:
  • cluster : Cluster row ID (required).
  • action : See action list below.
  • params : Parameters supplied in JSON form (optional).

  • Actions:

  • shutdown : Shutdown the Cluster.
  • cancel_shutdown : Cancel current shutdown request.

  • Example:

URL: '/v4/cluster_actions'
POST(JSON): {"cluster": 1, "action": "shutdown", "params": "{}"}

cluster_stats_history_long

The cluster_stats_history_long table holds Cluster stats history for extended periods.

cluster_stats_history_short

The cluster_stats_history_short table holds Cluster stats for a short period, storing the most recent statistics for quick access.

cluster_status

Handles the status of all the clusters.

cluster_tier_stats

Handles statistics for the vSAN tiers of a cluster.

cluster_tier_stats_history_long

Holds historical statistics for Cluster Tiers over extended periods.

cluster_tier_stats_history_short

Holds historical statistics for Cluster Tiers over short periods, storing the most recent statistics for quick access.

cluster_tier_status

Used for Cluster Tier statuses.

cluster_tiers

Holds a list of Tiers for the cluster.

clusters

The main table for data on the Clusters.

file_actions

The file_actions table sends file actions.

  • Fields:
  • file : File ID from files table (required).
  • action : See action list below.
  • params : Parameters supplied in JSON form (optional).

  • Actions:

  • overwrite : Overwrite the file.
  • add_link : Add a file link.
  • delete_link : Delete a file link.
  • delete_references : Delete file references.

  • Example:

URL: '/v4/file_actions'
POST(JSON): {"file": 1, "action": "add_link", "params": "{}"}

files

Information related to stored files.

Handles public links for files.

group_logs

Logs related to groups.

groups

Group management table.

help_actions

Handles help-related actions.

Search table for help documentation.

licenses

Handles VergeOS licenses.

logs

Handles system logs.

machine_console

Handles machine console interactions.

machine_console_active

Tracks active machine console sessions.

machine_console_active_chat

Tracks chat interactions in active machine consoles.

machine_device_gpu_stats_history_long

Holds historical GPU stats for extended periods.

machine_device_gpu_stats_history_short

Holds historical GPU stats for short periods.

machine_device_settings_nvidia_vgpu

Handles settings for Nvidia vGPU devices.

machine_device_settings_tpm

Handles settings for TPM devices.

machine_device_stats

Tracks device statistics.

machine_device_status

Tracks device status.

machine_devices

Table for machine device information.

machine_drive_phys

Physical drive data for machines.

machine_drive_stats

Drive statistics for machines.

machine_drive_stats_history_long

Holds historical drive statistics for extended periods.

machine_drive_stats_history_short

Holds historical drive statistics for short periods.

machine_drive_status

Tracks drive status for machines.

machine_drives

Table for machine drives.

machine_logs

Tracks machine logs.

machine_nic_stats

NIC statistics for machines.

machine_nic_stats_history_long

Historical NIC statistics over long periods.

machine_nic_stats_history_short

Historical NIC statistics over short periods.

machine_nic_status

NIC status for machines.

machine_nics

Table for NICs in machines.

machine_snapshots

Tracks snapshots for machines.

machine_stats

General statistics for machines.

machine_stats_history_long

Historical statistics for machines over long periods.

machine_stats_history_short

Historical statistics for machines over short periods.

machine_status

Tracks status for machines.

machines

Main table for machine data.


Document Information

  • Last Updated: 2024-08-29
  • vergeOS Version: 4.12.6