For the complete documentation index, see llms.txt. This page is also available as Markdown.

create

Create a VM Auto Scaling group from a JSON properties object

Usage

ionosctl vm-autoscaling group create [flags]

Aliases

For vm-autoscaling command:

[vmas vm-as vmasc vm-asc vmautoscaling]

For group command:

[g groups]

For create command:

[c]

Description

Create a new VM Auto Scaling group. The group's full configuration is supplied as a JSON 'properties' object (--json-properties, or a path to a file), because it nests three sub-objects that would be unwieldy as individual flags. Run this command with --json-properties-example to print a ready-to-edit template.

The properties object has these parts:

  • datacenter.id (required) - the datacenter the group and all its replicas live in.

  • name - a friendly label for the group.

  • minReplicaCount / maxReplicaCount (0-100) - the floor and ceiling for the number of running replicas. The autoscaler stays within these bounds.

  • policy - when and how to scale:

    • metric: INSTANCE_CPU_UTILIZATION_AVERAGE | INSTANCE_NETWORK_IN_BYTES | INSTANCE_NETWORK_IN_PACKETS | INSTANCE_NETWORK_OUT_BYTES | INSTANCE_NETWORK_OUT_PACKETS

    • range: the metric aggregation window in Nm/Ns/Nh notation, e.g. 2m or 120s; minimum 120s (API default 120s).

    • unit: PER_SECOND | PER_MINUTE | PER_HOUR | TOTAL - how the metric is normalized. For network metrics this is the rate unit; if unit=TOTAL, scaleOutThreshold must be >= 40.

    • scaleOutThreshold: when the metric goes ABOVE this value, scale out. scaleInThreshold: when it drops BELOW this value, scale in. The two thresholds must keep a minimum gap (metric-dependent) so the group does not scale in and out at the same time. scaleInThreshold < scaleOutThreshold.

    • scaleOutAction / scaleInAction: amount = how many replicas (or what percentage, when amountType=PERCENTAGE) to add/remove; amountType = ABSOLUTE | PERCENTAGE; cooldownPeriod = how long to wait before the next action (min 2m, max 24h, default 5m).

    • scaleInAction.terminationPolicy: OLDEST_SERVER_FIRST | NEWEST_SERVER_FIRST | RANDOM - which replica to remove first. scaleInAction.deleteVolumes: if true, a removed replica's volumes are deleted too. Leave true unless you need to keep the data; orphaned volumes count against your contract limits and can eventually block further scale-outs.

  • replicaConfiguration - the template every new replica is cloned from: cores, ram (in MB), cpuFamily (INTEL_SKYLAKE | INTEL_XEON; omit to use the location default), availabilityZone (AUTO | ZONE_1 | ZONE_2), plus nics (LAN wiring, firewall, flow logs) and volumes (boot image, size in GB, SSH keys, user-data).

Note: every scale-out provisions fresh volumes. If deleteVolumes is false they are never reclaimed automatically.

Options

Examples

Last updated