# Exoscale Documentation — Instances > Exoscale Compute instances documentation: deploy, scale and operate VMs — including GPU instances — on European-sovereign cloud infrastructure. --- url: https://community.exoscale.com/product/compute/instances/ --- # Instances - [Quick Start - Instances](https://community.exoscale.com/product/compute/instances/quick-start/index.md) - Get started quickly with a guided setup to achieve your first successful use of the service, including the required steps and configuration. - [Overview - Instances](https://community.exoscale.com/product/compute/instances/overview/index.md) - Terminology and key features at a glance, learn the core concepts, capabilities, and options of this service before you dive deeper. - [How-To - Instances](https://community.exoscale.com/product/compute/instances/how-to/index.md) - Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Service Boundaries - Instances](https://community.exoscale.com/product/compute/instances/service-boundaries/index.md) - Service boundaries: quotas, limits, and the guaranteed service levels (SLA) for this product, including key constraints to plan and operate reliably. - [Reference - Instances](https://community.exoscale.com/product/compute/instances/reference/index.md) - Reference documentation for API, CLI, and tools, browse comprehensive details, parameters, commands, and integration notes. --- url: https://community.exoscale.com/product/compute/instances/quick-start/ --- # Quick Start - Instances In this quick start guide, you will create and access your first instance (sometimes referred to as a virtual machine or VM). ## Prerequisites {#before-instance-creation} Before you create an instance, if you plan to use a Linux-based or BSD-based operating system, we strongly encourage you to set up an __SSH Key Pair__ for added security and ease of access. Follow the tutorial on [SSH Key Pair Setup](https://community.exoscale.com/product/compute/instances/how-to/ssh-keypairs/index.md) first before you start this guide. You also need to have [enough credit](https://community.exoscale.com/platform/quick-start/index.md) to start and run your instance. ## First Steps via CLI Install and configure the [Exoscale CLI](https://community.exoscale.com/tools/command-line-interface/index.md), then make sure you have: - an SSH key pair registered in Exoscale; - a Security Group that allows inbound TCP traffic on port 22 from your trusted source IP or network; - the zone, template, and instance type you want to use. Create a Linux instance: ```bash exo compute instance create my-first-instance \ --zone \ --template "Linux Ubuntu 24.04 LTS 64-bit" \ --instance-type standard.medium \ --disk-size 50 \ --ssh-key \ --security-group ``` The command waits for instance creation to finish and displays the instance state, IP address, template, instance type, and storage configuration. Inspect the instance: ```bash exo compute instance show my-first-instance --zone ``` When the instance is running, connect through SSH: ```bash exo compute instance ssh my-first-instance --zone ``` For all supported creation options, see the [`exo compute instance create` reference](https://community.exoscale.com/reference/cli/exo/compute/instance/create/index.md). ## First Steps via Portal Open the [Exoscale Portal](https://portal.exoscale.com/) and complete the following steps to create and access your first Compute instance. ### Create Your Instance {#create-your-instance} In the Exoscale Portal, select __COMPUTE__ from the main navigation on the left. Then select __INSTANCES__. From the instance list view, click on the __ADD__ button to start the instance creation wizard. #### Name Your Instance {#name-your-instance} Choose a display name for your instance. Only letters, digits and hyphens are allowed. If you leave this field blank, the instance's display name will be the instance's UUID. A good naming convention for your instances will help you work on them later, because you can filter your instance list by display name. You can also change the display name of your instance later on the instance detail view. #### Choose Your Template {#choose-your-template} From the templates list, you can choose operating systems based on Linux, BSD, or Windows. Windows Server templates are also supported on Storage Optimized instances. For this guide, we recommend choosing either the latest Ubuntu Linux or Microsoft Windows Server distribution. #### Choose Your RAM & CPU Config {#choose-your-ram--cpu-config} You can choose between different service levels, which are combinations of CPU cores and RAM memory. Some operating systems may be restricted because of their specifications. Please note you will be able to modify your service level choice later on by scaling your instance up or down. You can read [more about scaling](https://community.exoscale.com/product/compute/instances/how-to/instance-scaling/index.md) for additional details. #### Choose Your Instance Volume Size {#choose-your-instance-volume-size} Like service levels, some disk sizes may be restricted by operating system limitations. Consider initial disk size selection as a start point for the size of your volume. You can adjust disk size values later from the instance detail view, scaling up to as high as 400 GB in increments of 1 GB. You can learn more [on volume scaling](https://community.exoscale.com/product/compute/instances/how-to/instance-scaling/index.md) on its documentation page. #### SSH key pairs for Linux-based instances {#ssh-key-pairs-for-linux-based-instances} Like we mentioned at the top of this guide, we assume you will use an [SSH key pair](https://community.exoscale.com/product/compute/instances/how-to/ssh-keypairs/index.md) if you choose to start a Linux-based instance. (If you are using a Windows-based instance, you can skip this section.) Your instance will be automatically provisioned with the key you choose. You will be able to access it via SSH right away. #### Firewall rules - Security Groups {#firewall-rules---security-groups} Security Groups are firewall rules. An empty security group called `default` is already provided, but you can add more security groups or even combine them. A security group without defined rules behaves like this: * All incoming traffic is blocked * All outgoing traffic is allowed At least one security group has to be associated with an instance. If you choose no security group, `default` is associated automatically. You can also add and remove [security groups](https://community.exoscale.com/product/networking/security-group/index.md) later on from the instance details view. For this guide, choose the `default` security group to continue. #### Anti-Affinity Groups and User Data {#anti-affinity-groups-and-user-data} Anti-affinity groups ensure your machines are created on different hypervisors, and user data is a way to automatically provision your instance with additional software or settings. For example, installing Wordpress or importing more SSH keypairs. However, anti-affinity groups and user data are more advanced features. You can skip them for your first instance creation. If you are interested, you can take a look at: * [Anti-Affinity Groups](https://community.exoscale.com/product/compute/instances/how-to/anti-affinity/index.md) * [Cloud-Init and User Data](https://community.exoscale.com/product/compute/instances/how-to/cloud-init-user-data/index.md) #### Launch the instance creation {#launch-the-instance-creation} Now click on the __ADD__ button. You will be redirected to the instance list, where you will see your new instance listed. The instance will be marked as `STOPPED` at first. You should see the label change to `STARTING` and then change to `RUNNING`. Now you can log in to your new Compute instance! ### Access Your Instance #### Log into a Linux-Based Instance {#log-into-a-linux-based-instance} If you followed along and you attributed the default empty security group to your instance, your new server cannot be accessed from outside. Your security group has no rules defined, so all incoming traffic will be denied. You will access your instance via SSH. To access via SSH, we have to make sure that inbound traffic is allowed on port 22. Click on __COMPUTE__ in the main navigation and select the __SECURITY GROUPS__ section. Then click on the `default` security group. The first view is the group detail, where all rules of the group are listed. You will also see the list of instances your group is attached to. In the upper right header, you will find buttons to either choose a template (a shortcut to add the most common rules) or add your own configured rule. Choose the SSH template. Create a new rule with the following settings: * Type: inbound * Source Type: CIDR * CIDR: `/32` * Protocol: TCP * Start Port: 22 * End Port: 22 > [!IMPORTANT] > Restrict SSH access to a trusted source IP or network. Do not use > `0.0.0.0/0` unless unrestricted public access is explicitly required and you > understand the security risk. You should now be able to log into your instance from a Linux command line with: `ssh root@` You can find your server's IP in the instance list view and in the instance detail. #### Log into a Windows-Based Instance {#log-into-a-windows-based-instance} Like we mentioned with security groups, your Windows instance will not be accessible from outside until you define some rules for the security group. Click on __COMPUTE__ in the main navigation and select the __SECURITY GROUPS__ section. Then click on the `default` security group. The first view is the group detail, where all rules of the group are listed. You will also see the list of instances your group is attached to. In the upper right header, you will find commands to either choose a template (a shortcut to add the most common rules) or add your own configured rule. Choose the Remote Desktop Protocol (or RDP) template, which will create a new rule with the following settings: * Type: inbound * Source Type: CIDR * CIDR: `/32` * Protocol: TCP * Start Port: 3389 * End Port: 3389 > [!IMPORTANT] > Restrict RDP access to a trusted source IP or network. Do not expose port > 3389 to the entire internet unless it is explicitly required. After you allow traffic on port 3389, point your remote desktop client to the public IP address of your instance using the username `administrator`. You will find your instance password in the instance detail. > [!NOTE] > If you do not immediately see the password in the instance detail, wait about 60 seconds for the password to appear on the Portal. > The password will be available through the Portal for __a very short period of time__ - just a few hours, so please take note of it. > You can reset it from the same instance detail if necessary. ## Next Steps * [Scale your instance](https://community.exoscale.com/product/compute/instances/how-to/instance-scaling/index.md) * [Create and manage snapshots](https://community.exoscale.com/product/compute/instances/how-to/snapshot/index.md) * [Automate configuration with cloud-init and user data](https://community.exoscale.com/product/compute/instances/how-to/cloud-init-user-data/index.md) * [Manage groups of instances with Instance Pools](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md) --- url: https://community.exoscale.com/product/compute/instances/overview/ --- # Overview - Instances Exoscale Compute Instances are high-performance, KVM-based virtual machines designed for workloads ranging from small applications to complex distributed systems. You can provision and manage them through the Exoscale Portal, CLI, API, or infrastructure-as-code tools such as Terraform and Ansible. ## Architecture Each Compute instance runs on an Exoscale-managed KVM hypervisor in a single [Exoscale zone](https://www.exoscale.com/datacenters/). A template supplies the initial operating system, while the selected instance type determines the available CPU, memory, and local storage. Each instance boots from a root volume backed by local SSD storage. You can attach [Block Storage](https://community.exoscale.com/product/storage/block-storage/index.md) volumes when you need independently managed persistent storage. Network interfaces connect instances to public or private networks, while Security Groups control allowed traffic. SSH keys, IAM permissions, and instance metadata control administrative and automated access. [Instance Pools](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md) manage groups of instances for scaling and availability. [Anti-Affinity Groups](https://community.exoscale.com/product/compute/instances/how-to/anti-affinity/index.md) place selected instances on different physical hypervisors to reduce the impact of a host failure. ## Terminology {#terminology} Understanding the basic terms used in Exoscale Compute will help you get up and running quickly. Instance : A Compute Instance is a virtual machine (VM) running in the Exoscale cloud. It behaves like a traditional server but is virtualized and runs on shared physical infrastructure. Instances are fully self-contained environments and can run various operating systems (Linux, Windows, and custom ISOs), including on Storage Optimized instances. Instance Type : The Instance Type defines the resource configuration of your VM — such as number of vCPUs, amount of RAM, and local SSD storage. Exoscale offers different instance families optimized for CPU, memory, storage, or GPU workloads.
| Instance Family | Use Case | RAM Range | CPU Cores | Local Storage | Availability | | :--- | :--- | ---: | ---: | ---: | :---: | | Standard | General-purpose workloads | 512MB - 225GB | 1 - 24 | 10GB - 1.6TB | All zones | | CPU Optimized | Compute-intensive applications | 16GB - 128GB | 8 - 40 | 10GB - 1.6TB | All zones | | Memory Optimized | RAM-intensive applications | 16GB - 128GB | 2 - 12 | 10GB - 1.6TB | All zones | | Storage Optimized | Data-heavy workloads | 16GB - 225GB | 4 - 24 | 1TB - 15TB | All zones | | [GPU Servers](https://www.exoscale.com/gpu/#comparison-gpu) | AI/ML, HPC, simulations, and rendering | 56GB - 2.5TiB | 12 - 248 | 100GB - 10TiB | Selected zones | > Local storage is provisioned and billed per GiB-hour. Values shown in TB are approximate (1 TB ≈ 931 GiB). See [pricing](https://www.exoscale.com/pricing/) for exact per-size minimums and pricing. Template : A Template is a pre-configured disk image used to launch instances. Templates define the base OS and system configuration. You can use public templates provided by Exoscale or upload your own. Zone : A location in which an instance and its zone-scoped resources are created. An instance cannot be moved to another zone after creation. Root Volume : The instance’s boot volume, created from the selected template and backed by the local SSD storage included with the instance type. Its capacity depends on the selected instance type. Local Storage : SSD storage provided by the hypervisor. Its capacity and performance characteristics depend on the selected instance family. Block Storage : Persistent storage that can be attached to an instance and managed independently from the instance lifecycle. Snapshot : A point-in-time copy used to preserve a volume or instance state and create new storage or templates. Instance Pool : A managed group of Compute instances used to maintain capacity and support automated scaling and replacement. Anti-Affinity Group : A placement rule that distributes member instances across different physical hypervisors. Security Group : A set of stateful ingress and egress rules controlling traffic to and from an instance. ## Features {#features} ### Provisioning and Automation Rapid Deployment : Launch virtual machines within seconds through the Exoscale Portal, CLI, or API. Custom Templates and Snapshots : Create and deploy instances from custom templates, and take snapshots for backup, cloning, and recovery workflows. Built-In IAM : Use granular Identity and Access Management policies to control API permissions. ### Compute and Scaling Flexible Instance Types : Choose from instance families designed for general-purpose, CPU-intensive, memory-intensive, storage-intensive, or GPU workloads. Instance Pools : Automatically manage groups of instances for availability and scalability. ### Storage Local SSD Storage : Use enterprise-grade local SSD RAID10 storage for high I/O performance and low latency. Block Storage : Attach persistent volumes that can be managed independently of the instance. ### Availability Anti-Affinity Groups : Distribute instances across different physical hypervisors to improve fault tolerance. Instance Pools : Maintain the requested number of instances and replace unavailable members. ### Security vTPM and Secure Boot : Use vTPM for TPM 2.0 workloads, including Windows BitLocker, and Secure Boot to load only signed operating-system components. Security Groups : Control inbound and outbound network traffic with stateful firewall rules. ### Encryption at Rest {#encryption-at-rest} Exoscale encrypts Compute root volumes and Block Storage volumes transparently at the hypervisor layer. You do not need to install agents in the guest operating system or change your workflow. Encryption is enabled by default and cannot be disabled. The encryption capability will integrate with [Exoscale Key Management Service (KMS)](https://community.exoscale.com/product/security/kms/overview/index.md) for managed key lifecycle functionality. #### How it works {#how-it-works} Exoscale uses AES-256 in XTS mode to encrypt volume data. Instance local storage is encrypted with unique key material for each volume. The encryption key is destroyed when the volume is deleted. Block Storage volumes receive unique encryption keys when they are created. Snapshots inherit the key of their source volume, and volumes promoted from snapshots inherit the key of the source snapshot. Encryption and decryption are transparent to the instance operating system, filesystem, applications, and tooling. They see a normal block device. A volume encryption key is present in plaintext only in the memory of the hypervisor actively running the attached workload. The key is removed from that hypervisor when the instance stops or migrates away. > [!NOTE] > Custom templates are encrypted transparently when the hypervisor fetches > them. This encryption step can increase initial instance provisioning time. #### What is covered {#what-is-covered} **Compute root volumes** : Every new Compute instance is provisioned with an encrypted root volume. **Block Storage volumes** : Every new Block Storage volume is encrypted by default. **Block Storage snapshots** : Snapshots inherit the encryption key of their parent volume and remain encrypted throughout their lifecycle. A volume promoted from a snapshot uses the same key as the source snapshot and its parent volume. **Instance snapshots and templates on Object Storage** : Instance snapshots and templates are stored on [Object Storage](https://community.exoscale.com/product/storage/object-storage/index.md) with bucket-level encryption, so their data remains encrypted on the underlying storage media. #### Key management today {#key-management-today} Exoscale manages encryption keys on your behalf. Each volume key is generated randomly when the volume is created and stored securely in encrypted form. Key material is never exposed to customers, and Exoscale manages its lifecycle. For information about customer-managed key lifecycle operations, see the [KMS documentation](https://community.exoscale.com/product/security/kms/index.md). #### Rollout {#rollout} - **New workloads are always encrypted.** Every new Compute instance boots from an encrypted root volume, and every new Block Storage volume is encrypted when created. - **Existing instances remain unencrypted for now.** Exoscale will communicate a supported migration path before this changes. > [!IMPORTANT] > Existing Block Storage volumes are not re-encrypted in place because doing so > while they are attached risks data corruption. To encrypt existing data, > create a new encrypted Block Storage volume and copy the data to it. --- url: https://community.exoscale.com/product/compute/instances/how-to/ --- # How-To - Instances Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Create Snapshots](https://community.exoscale.com/product/compute/instances/how-to/snapshot/index.md) - Create point-in-time Exoscale instance snapshots for recovery, rollback, export, and template creation before risky changes or updates. - [Manage Instance Pools](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md) - Deploy and manage Exoscale instance pools to scale identical instances, automate updates, and use private networking and metadata. - [Use Application-Consistent Backups](https://community.exoscale.com/product/compute/instances/how-to/acs/index.md) - Enable application-consistent Windows backups with VSS and QEMU Guest Agent for safer snapshots, restores, and custom templates. - [Use Rescue Mode](https://community.exoscale.com/product/compute/instances/how-to/rescue-mode/index.md) - Use Rescue Mode to boot Exoscale instances with netboot.xyz for recovery, disk repair, password resets, and custom ISO troubleshooting. - [Use SSH Keypairs](https://community.exoscale.com/product/compute/instances/how-to/ssh-keypairs/index.md) - Use SSH keypairs to securely access Exoscale Linux instances, import public keys, and connect without relying on passwords. - [Use Anti-Affinity Groups](https://community.exoscale.com/product/compute/instances/how-to/anti-affinity/index.md) - Improve availability with Anti-Affinity Groups by spreading instances across hypervisors to reduce single-host failure impact. - [Use BitLocker on Windows](https://community.exoscale.com/product/compute/instances/how-to/bitlocker-windows/index.md) - Secure Windows instances with vTPM, Secure Boot, and BitLocker encryption, including automatic key handling and recovery guidance. - [Scale an Instance](https://community.exoscale.com/product/compute/instances/how-to/instance-scaling/index.md) - Scale Exoscale instances by resizing CPU, RAM, and disk capacity, with guidance for Linux and Windows filesystem expansion. - [Use Instance Tags](https://community.exoscale.com/product/compute/instances/how-to/instance-tags/index.md) - Use instance tags to assign key-value metadata to Exoscale instances and retrieve values through the API for configuration workflows. - [Configure Windows Server Language](https://community.exoscale.com/product/compute/instances/how-to/windows-specifics/index.md) - Configure Windows Server language settings on Exoscale during instance creation using user data for English, German, or French. - [Use Labels](https://community.exoscale.com/product/compute/instances/how-to/labels/index.md) - Add key-value labels to Exoscale resources like instance pools for organization, metadata management, and automation via Portal or CLI. - [Use Cloud-Init and User Data](https://community.exoscale.com/product/compute/instances/how-to/cloud-init-user-data/index.md) - Automate Exoscale instance setup with cloud-init and user data for scripts, YAML config, metadata access, and password management. - [Build Custom Templates](https://community.exoscale.com/product/compute/instances/how-to/custom-templates/index.md) - Build and register Exoscale custom templates with Packer or QCOW2 images for faster instance deployment and tailored configurations. - [Manage Flexible Storage](https://community.exoscale.com/product/compute/instances/how-to/flexible-storage-management/index.md) - Manage Exoscale instance storage with LVM, GPT, and UEFI to create, resize, and organize partitions for flexible disk layouts. - [Create Private Instances](https://community.exoscale.com/product/compute/instances/how-to/private-instances/index.md) - Create Exoscale private instances without public IPs and use private networks and NoCloud metadata for isolated workloads and secure access. - [Run LLMs on GPUs](https://community.exoscale.com/product/compute/instances/how-to/running-llms-on-gpus/index.md) - Run LLMs on Exoscale GPU instances with Docker, NVIDIA drivers, and vLLM for OpenAI-compatible inference and scalable deployment. - [Use GPU MIG Partitioning](https://community.exoscale.com/product/compute/instances/how-to/gpu-mig-partitioning/index.md) - Partition Exoscale MIG-capable GPUs into isolated instances with dedicated compute and memory for efficient multi-workload execution. --- url: https://community.exoscale.com/product/compute/instances/how-to/snapshot/ --- # Create Snapshots Snapshots provide a way to get point-in-time recovery for your instance. In a typical usage example, you would snapshot your instance before applying patches. After the patches are installed, if your tests are not satisfying or an incompatibility is introduced, you can revert to the snapshot and restore the previous working state. Snapshots are strongly tied to your instance: if you delete your instance, the snapshots will be deleted as well. ![](snapshot.png "Snapshots are located in the instance detail screen") ## Create a New Snapshot > [!WARNING] > It is strongly encouraged to stop a Compute instance before creating a snapshot of its storage volume in order > to ensure all data is written to the disk controller and it reaches the underlying hypervisor backend storage. > Alternatively, using the facility provided by your OS to flush cached writes to disk ensures data recently > written will be snapshotted. On Linux, you can do this with the [`sync(1)`](https://man7.org/linux/man-pages/man1/sync.1.html) command. We recommended you avoid performing any action on the related instance during a snapshot operation, so any unintended side-effects that could lead to an operation failure do not occur. From the instance detail screen, click on `CREATE SNAPSHOT` to create a new snapshot. A successfully created snapshot has a green checkmark under `STATE`. ![](snapshot-ready-state.png "Wait for a snapshot to be ready before operating on it") ## Revert to a Snapshot If you need to revert to a snapshot in the Portal, first stop your instance. Then from the snapshots list in the instance detail, click `Revert` under the `...` button in the Actions column for the snapshot you wish to revert. Using the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md), the equivalent command is: ```bash exo compute instance snapshot revert ``` ## Delete a Snapshot To delete a snapshot, click on `Delete` under the `...` button in the Actions column for the snapshot you wish to delete. Using the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md), the equivalent command is: ```bash exo compute instance snapshot delete ``` ## Export or Download a Snapshot An exported snapshot file can be downloaded either for backup purposes, or used as input to create a new [Custom Template](https://community.exoscale.com/product/compute/instances/how-to/custom-templates/index.md). To export a snapshot, use the following [CLI](https://community.exoscale.com/tools/command-line-interface/index.md) command: ```bash exo compute instance snapshot export ce295d39-421e-49c4-81f7-9890c3db3600 ``` Output: ```bash ✔ Exporting snapshot ce295d39-421e-49c4-81f7-9890c3db3600... 4s ┼──────────┼──────────────────────────────────────────────────────────────────┼ │ URL │ https://exported-snapshots-ch-gva-2-prod.sos-ch-gva-2.exo.io/... │ │ Checksum │ 34ef65cad47428e799f9bc6c02b7ebd5 │ ┼──────────┼──────────────────────────────────────────────────────────────────┼ ``` Using the CLI's templated text output format, you can download an exported snapshot disk file locally, for example as an extra backup method: ```bash wget -O ce295d39-421e-49c4-81f7-9890c3db3600.template \ $(exo compute instance snapshot export ce295d39-421e-49c4-81f7-9890c3db3600 --output-template {{.URL}} 2>/dev/null) ``` Output: ```bash --2021-09-17 10:51:12-- https://sos-ch-gva-2.exo.io/... Resolving sos-ch-gva-2.exo.io (sos-ch-gva-2.exo.io)... 194.182.160.205 Connecting to sos-ch-gva-2.exo.io (sos-ch-gva-2.exo.io)|194.182.160.205|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 10301276160 (9.6G) [application/binary] Saving to: ‘ce295d39-421e-49c4-81f7-9890c3db3600.template’ [...] ``` > [!NOTE] > The duration of a snapshot operation may vary greatly depending on the size of your volume and the amount of data stored on it. > The entire operation can take up to several hours, during which no other operation should be performed on the instance. > After the snapshot is exported, the returned pre-signed URL will only be valid for 6 hours. You can get a new one by > repeating the operation, knowing that the subsequent exports of an already exported snapshot will be instantaneous. ## Limitations - Snapshots are limited to 30 per account. Please contact support if you need more. - Only one snapshot operation is permitted at a time. For example, when a snapshot is being destroyed, you cannot create a new snapshot of the same storage volume. - Snapshots cannot be named. They are identified by a UUID. - When you delete an instance, its snapshots are deleted as well. - Snapshots are currently unavailable for storage optimized instances. --- url: https://community.exoscale.com/product/compute/instances/how-to/instance-pools/ --- # Manage Instance Pools Exoscale __Instance Pools__ are a service to provision groups of identical Compute instances automatically. You can define several instances in the pool, and the service will keep the required number up and running for you to achieve: * __High availability__: using an Instance Pool ensures that the target quantity of instances is running. * __Elasticity__: Instance Pools can be scaled up and down dynamically so the number of instances matches the actual load for better cost efficiency. ### Getting Started Before creating an Instance Pool, please note the following aspects and restrictions: * Instance Pools and their managed Compute Instances cannot span multiple [Exoscale zones]. They cannot be migrated to another zone after being created. * Instance Pool member instances might have different types. Updating the instance type applies __only to new members__; existing members remain untouched. * If an Instance Pool is referenced by a Network Load Balancer service, it cannot be deleted. You can create an Instance Pool from the [Instance Pools][portalnewipool] section in the Portal under __COMPUTE__ in the main navigation. You can also use the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md). Here is an example of Instance Pool creation using the CLI: ```bash exo compute instance-pool create web \ --zone ch-gva-2 \ --size 3 \ --description "Web servers" \ --instance-type medium \ --template "Linux Ubuntu 20.04 LTS 64-bit" \ --security-group web \ --ssh-key admin \ --ipv6 ``` Output: ```bash ✔ Creating Instance Pool "web"... 33s ┼──────────────────────┼──────────────────────────────────────┼ │ ID │ ab8fbe95-72d4-0703-fcae-6401540d86ff │ │ Name │ web │ │ Description │ Web servers │ │ Instance Type │ standard.medium │ │ Template │ Linux Ubuntu 20.04 LTS 64-bit │ │ Zone │ ch-gva-2 │ │ Anti-Affinity Groups | n/a │ │ Security Groups │ web │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ IPv6 │ true │ │ SSH Key │ admin │ │ Size │ 3 │ │ Disk Size │ 50 GiB │ │ Instance Prefix │ pool │ │ State │ running │ │ Labels │ n/a │ │ Instances │ pool-ab8fb-xbedt │ │ │ pool-ab8fb-obain │ │ │ pool-ab8fb-cjrfw │ ┼──────────────────────┼──────────────────────────────────────┼ ``` > [!NOTE] > Your organization's resource quotas constrain Instance Pool size. If you want to scale an Instance Pool up, ensure your account's instance quota allows you to do so before attempting scaling up. You can request a [quota increase][supportticket] if necessary. > [!NOTE] > If an Instance Pool needs to be deployed to a dedicated hypervisor, specify the `--deploy-target` flag. ### Managing Instance Pools In addition to normal CRUD operations, the following actions are available: * `scale`: scales an Instance Pool to a desired number of instances * `evict`: evicts specific members of an Instance Pool, shrinking its size. #### Retrieve Instance Pool Information You can access an expanded view of an instance pool to retrieve its properties. Click on the instance pool name in the [instance pools list view][portalipoolslist] on the Portal under __COMPUTE__, or use the command:`exo compute instance-pool show` in the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md): ```bash exo compute instance-pool show --zone ch-gva-2 web ``` Output: ```bash ┼──────────────────────┼──────────────────────────────────────┼ │ INSTANCE POOL │ │ ┼──────────────────────┼──────────────────────────────────────┼ │ ID │ ab8fbe95-72d4-0703-fcae-6401540d86ff │ │ Name │ web │ │ Description │ Web servers │ │ Instance Type │ standard.medium │ │ Template │ Linux Ubuntu 20.04 LTS 64-bit │ │ Zone │ ch-gva-2 │ │ Anti-Affinity Groups | n/a │ │ Security Groups │ web │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ IPv6 │ true │ │ SSH Key │ admin │ │ Size │ 3 │ │ Disk Size │ 50 GiB │ │ Instance Prefix │ pool │ │ State │ running │ │ Labels │ n/a │ │ Instances │ pool-ab8fb-xbedt │ │ │ pool-ab8fb-obain │ │ │ pool-ab8fb-cjrfw │ ┼──────────────────────┼──────────────────────────────────────┼ ``` #### Update an Instance Pool's Properties The following properties can be updated in place for an Instance Pool: * Name * Description * Deploy Target * IPv6 support * User Data * Labels * Managed Compute instances prefix * Managed Compute instances template * Managed Compute instances type * Managed Compute instances Anti-Affinity Groups * Managed Compute instances Elastic IPs * Managed Compute instances Private Networks * Managed Compute instances Security Groups * Managed Compute instances prefix * Managed Compute instances SSH key * Managed Compute instances Storage volume size To update an instance pool, click on the instance pool name on the [instance pools list][portalipoolslist] in the Portal, then click on the __UPDATE POOL__ button is on the top right of the header. In the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md), use the `exo compute instance-pool update` command: ```bash exo compute instance-pool update web --zone ch-gva-2 --disk-size 20 ``` Output: ```bash ✔ Updating Instance Pool "web"... 6s ┼──────────────────────┼──────────────────────────────────────┼ │ INSTANCE POOL │ │ ┼──────────────────────┼──────────────────────────────────────┼ │ ID │ ab8fbe95-72d4-0703-fcae-6401540d86ff │ │ Name │ web │ │ Description │ Web servers │ │ Service Offering │ Medium │ │ Template │ Linux Ubuntu 20.04 LTS 64-bit │ │ Zone │ ch-gva-2 │ │ Anti-Affinity Groups | group1 │ │ Security Groups │ web │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ IPv6 │ true │ │ SSH Key │ admin │ │ Size │ 3 │ │ Disk Size │ 20 GiB │ │ Instance Prefix │ pool │ │ State │ running │ │ Labels │ n/a | │ Instances │ pool-ab8fb-xbedt │ │ │ pool-ab8fb-obain │ │ │ pool-ab8fb-cjrfw │ ┼──────────────────────┼──────────────────────────────────────┼ ``` > [!NOTE] > When updating Instance Pool properties related to its managed Compute instances (such as template, type, > or storage volume size), the new value will be considered only for __newly__ created instances. Current > Compute Instances in the pool will not be affected by the change. These instances will need to be destroyed > manually so that the Instance Pool manager can replace them with up-to-date versions. > [!NOTE] > If an Instance Pool scales down, the excess managed Compute Instances are deleted, starting with the oldest > instances. This feature can be used to quickly recycle the Instance Pool members by temporarily scaling up the > pool to double its size. After the new Compute instances are operational, scale down the pool to its original > size to automatically delete the stale Compute instances. #### Delete an Instance Pool To delete an Instance Pool, click on the instance pool name on the [instance pools list][portalipoolslist] in the Portal, then click on the __DELETE POOL__ button in the top right of the header. You can use the `exo compute instance-pool delete` command in the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md). > [!WARNING] > __Deleting an Instance Pool also deletes its managed Compute instances.__ #### Labels Instance Pool supports [labels](https://community.exoscale.com/product/compute/instances/how-to/labels/index.md) that will also be propagated to the member instances. #### The Instance Pool Lifecycle The following states can describe an Instance Pool's lifecycle: | State | Description | | :-- | :-- | | __CREATING__ | The Instance Pool is being provisioned for the first time. | | __SCALING UP__ | The Instance Pool is being scaled up following its creation or a user's scaling request, creating Compute instances to meet the requested pool size. | | __RUNNING__ | The Instance Pool is stable, and all of its managed Compute instances are running. | | __SCALING DOWN__ | The Instance Pool is being scaled down following a user's scaling request, deleting Compute instances to meet the requested pool size. | | __DESTROYING__ | The Instance Pool is being destroyed. | ### Instance Pool Prefixes By default, Instance Pool-managed Compute instances are named as: `pool--`. This naming pattern can be customized by passing the `--instance-prefix` parameter during an Instance Pool creation or update. For example, if you pass the string `applications` to `--instance-prefix`, `pool` will be replaced by `applications` in the instance names. ### Going Further * If you intend to deploy a cluster using Instance Pools, you can leverage the Exoscale [Private Networks](https://community.exoscale.com/product/networking/private-network/index.md) functionality for high-performance and low latency connectivity between your Instance Pool member instances. * Provision Instance Pools using the [Exoscale Terraform Provider][terraform]. ### Pricing This service is offered free of charge; only the resources consumed as a byproduct of running Instance Pools (such as Compute instances, storage, and egress network traffic) are charged at our [regular rates][exopricing]. ### Resources * [Create an Instance Pool][portalnewipool] in the Portal. * Instance Pools [API documentation][ipoolapidoc]. [Exoscale zones]: https://www.exoscale.com/datacenters/ [supportticket]: https://portal.exoscale.com/tickets [portalnewipool]: https://portal.exoscale.com/compute/instancepools/add [portalipoolslist]: https://portal.exoscale.com/compute/instancepools [ipoolapidoc]: https://community.exoscale.com/reference/api/compute/instance-pool/ [exopricing]: https://www.exoscale.com/pricing/ [terraform]: https://github.com/exoscale/terraform-provider-exoscale/tree/master/examples/instance-pool [GPU Instances]: https://www.exoscale.com/gpu/ ## Private Instances At Exoscale each compute instance is provided with a public IP by default. At creation, public IP assignment can be controlled and offers three modes: - `ipv4`: The instance is assigned a Public IPv4 address - `dual`: The instance is assigned a Public IPv4 and a Public IPv6 address - `none`: No public IP attachment is done on the instance, it is a *private instance* Instances initially assigned with an IPv4 address can be promoted to dual-stack (IPv4 and IPv6), but private instances remain without public IP assignments for their entire lifetime. Similarly, public instances cannot be converted to private, ensuring their public IP assignment persists throughout their lifecycle. You can create a private instance from the Portal, or You can also use the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md). Here is an example of Private Instance creation using the CLI: ```bash exo compute instance create my-private-instance --private-instance ``` Output: ```bash ✔ Creating instance "my-private-instance"... 13s ┼──────────────────────┼──────────────────────────────────────┼ │ COMPUTE INSTANCE │ │ ┼──────────────────────┼──────────────────────────────────────┼ │ ID │ 5921300e-6bae-491b-8b15-1e927aef403a │ │ Name │ my-private-instance │ │ Creation Date │ 2023-10-02 20:12:37 +0000 UTC │ │ Instance Type │ standard.medium │ │ Template │ Linux Ubuntu 22.04 LTS 64-bit │ │ Zone │ de-fra-1 │ │ Anti-Affinity Groups │ n/a │ │ Deploy Target │ - │ │ Security Groups │ n/a │ │ Private Instance │ Yes │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ IP Address │ - │ │ IPv6 Address │ - │ │ SSH Key │ - │ │ Disk Size │ 50 GiB │ │ State │ running │ │ Labels │ n/a │ │ Reverse DNS │ │ ┼──────────────────────┼──────────────────────────────────────┼ ``` This newly created instance will not have any network. Most likely your use case involves some communication with other instances and services, and you should consider attaching a private instance to a [private network](https://community.exoscale.com/product/networking/private-network/index.md). ## Private Instance Metadata Instance metadata is typically served over the http://169.254.169.254 address, *private instances* will instead see an additional read-only drive containing their metadata, compatible with the [cloud-init](https://cloudinit.readthedocs.io/en/latest/) `NoCloud` configuration source. ### Caveats The following caveats apply: - Windows templates are not able to read metadata from the additional drive, standard Exoscale templates will require setting the password manually from the web portal console after the first boot. - Metadata drives remain mounted and may contain credential information (for instance after a password reset request), metadata should thus be acted upon quickly --- url: https://community.exoscale.com/product/compute/instances/how-to/acs/ --- # Use Application-Consistent Backups Using Volume Shadow Copy Service (VSS) is essential when snapshotting a Windows instance because it ensures application-consistent backups, not just crash-consistent ones. VSS coordinates with the Windows OS and VSS-aware applications (such as SQL Server or Exchange) to momentarily pause writes, flush in-memory data to disk, and capture a clean snapshot. This process prevents file corruption, reduces recovery issues, and makes restores faster and more reliable. In short, VSS snapshots help guarantee that your backups are usable, consistent, and production-safe on Windows systems built on Microsoft technologies. # Requirements for Application-Consistent Backups 1. **QEMU Guest Agent Installed** - The **QEMU Guest Agent** must be installed on the Windows guest. - This agent enables communication between Exoscale Hypervisor and guest for proper snapshot coordination. - For Exoscale Windows templates, this is now standard. 2. **QEMU Guest Agent Enabled** - Ensure the agent service is running and enabled on the guest. ![](windows-qemu-agent.png "Windows QEMU Guest Agent") - For Exoscale Windows templates, this is now standard. 3. **Enable Agent at Instance Creation** - When provisioning a new instance, enable **Application-consistent snapshots**. If the selected template already has this setting enabled, it will be automatically enabled for the instance. ![](acs-enable.png "Application consistent snapshot enabled") 4. **VSS Support on the Guest** - Ensure that **Volume Shadow Copy Service (VSS)** is functional within Windows guest. - VSS must be able to coordinate with applications like SQL Server, Exchange, or file services to create application-consistent snapshots. 5. **Sufficient Storage for Snapshots** - Ensure there’s enough free space to hold temporary snapshot data. 6. **Permissions and Administrative Access** - The agent and VSS must run with appropriate privileges (typically administrative) to access all necessary files and services. 7. **Regular Testing of Snapshots** - Periodically test snapshot creation and restores to ensure application consistency. For guidance on creating and validating snapshots from an existing instance, refer [to](https://community.exoscale.com/product/compute/instances/how-to/custom-templates/index.md#from-a-compute-instance-snapshot) # Using a Custom Windows Template with Application-Consistent Backups To enable **application-consistent backups** for a custom Windows template on Exoscale, follow these requirements and steps: ## Requirements 1. **QEMU Guest Agent** - The **QEMU Guest Agent** must be installed on the Windows guest. - This agent enables communication between Exoscale Hypervisor and guest for proper snapshot coordination. 2. **Volume Shadow Copy Service (VSS)** - Must be functional inside the Windows guest for application-consistent snapshots. ## Registering a Custom Template When registering your custom Windows template, you must use the `--application-consistent-snapshot-enabled` flag. **Example command:** ```bash exo compute instance-template register custom-windows \ https://sos-at-vie-1.exo.io/private-template/windows-template/windows.qcow2 \ b2dddb232d7d5680bbb7be04d56969bb \ --application-consistent-snapshot-enabled \ --boot-mode uefi \ --description "Custom Windows Template" \ --username Administrator \ -z at-vie-1 ✔ Registering template "custom-windows"... 30m4s ┼─────────────────────────────────────────┼──────────────────────────────────────┼ │ TEMPLATE │ │ ┼─────────────────────────────────────────┼──────────────────────────────────────┼ │ ID │ 4a1797f8-1480-43fe-89de-4b70ca8c5cb0 │ │ Zone │ at-vie-1 │ │ Name │ custom-windows │ │ Description │ Custom Windows Template │ │ Family │ other (64-bit) │ │ Creation Date │ 2026-02-18 12:52:07 +0000 UTC │ │ Visibility │ private │ │ Size │ 150 GiB │ │ Version │ │ │ Build │ │ │ Maintainer │ │ │ Default User │ administrator │ │ SSH key enabled │ true │ │ Password enabled │ true │ │ Boot Mode │ uefi │ │ Checksum │ b2dddb232d7d5680bbb7be04d56969bb │ │ Application Consistent Snapshot Enabled │ true │ ┼─────────────────────────────────────────┼──────────────────────────────────────┼ ``` # Enabling Application-Consistent Backups on an Existing Instance If your Windows instance does not have the **QEMU Guest Agent** installed, follow these steps to enable application-consistent backups. ## Steps ### 1. Update the Instance to Enable Application-Consistent Snapshots ```bash exo compute instance update windows-without-acs \ --application-consistent-snapshot-enabled \ -z at-vie-1 ✔ Updating instance "windows-without-acs"... 0s ┼─────────────────────────────────────────┼──────────────────────────────────────┼ │ COMPUTE INSTANCE │ │ ┼─────────────────────────────────────────┼──────────────────────────────────────┼ │ ID │ d225c530-ddab-4ffd-ae58-e38e131b5129 │ │ Name │ windows-without-acs │ │ Creation Date │ 2018-06-05 09:51:16 +0000 UTC │ │ Instance Type │ memory.huge │ │ Template │ Windows Server 2016 │ │ Zone │ at-vie-1 │ │ Anti-Affinity Groups │ n/a │ │ Deploy Target │ - │ │ Security Groups │ windows_default │ │ │ windows_default_rules │ │ Private Instance │ No │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ Public IP │ inet4 │ │ IP Address │ 185.150.10.210 │ │ IPv6 Address │ - │ │ SSH Key │ - │ │ Disk Size │ 150 GiB │ │ State │ stopped │ │ Labels │ n/a │ │ Secure Boot │ false │ │ Tpm │ false │ │ Reverse DNS │ │ │ Application-Consistent Snapshot enabled │ true │ ┼─────────────────────────────────────────┼──────────────────────────────────────┼ ``` This prepares the instance for application-consistent snapshots. ### 2. Install QEMU Guest Agent in the Operating System The **QEMU Guest Agent** allows communication between the host and Windows guest, enabling features like application-consistent snapshots. This guide covers both manual and unattended installation. On Exoscale, all official Windows templates already include and enable the QEMU Guest Agent by default, it's only needed for custom templates. ## Requirements - Windows Server 2022 or later. - Administrative privileges on the Windows guest. --- ## 1. Manual Installation 1. **Download the QEMU Guest Agent** - Available in the official **QEMU Windows installer** or from the [Fedora VirtIO Windows repository](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/). 2. **Run the Installer** - Launch the downloaded installer (`virtio-win-guest-tools.exe`). - Select **QEMU Guest Agent** during the installation wizard. 3. **Enable and Start the Service** - Open **Services** (`services.msc`). - Locate **QEMU Guest Agent**, set **Startup type** to `Automatic`, and click **Start**. 4. **Verify Installation** - Open Command Prompt (admin) and run: ```cmd sc query qemu-ga ``` - The service should display `STATE: RUNNING`. --- ## 2. Unattended Installation For automated deployments, you can install the QEMU Guest Agent silently using the installer’s MSI or EXE with command-line options. **Example using MSI (preferred if available):** ```cmd msiexec /i "qemu-ga-x64.msi" /qn /norestart ``` **Example using EXE installer:** ```cmd virtio-win-guest-tools.exe /S /COMPONENTS="GuestAgent" ``` **After installation, ensure the service is started and set to automatic:** ```cmd sc config qemu-ga start= auto sc start qemu-ga ``` - The service should display `STATE: RUNNING`. ### 3. Power Off the Instance ```bash exo compute instance stop windows-without-acs -z at-vie-1 ``` ### 4. Start the Instance Back Up ```bash exo compute instance start windows-without-acs -z at-vie-1 ``` ## Notes - The instance must have **VSS (Volume Shadow Copy Service)** enabled for application-consistent backups to work. - After completing these steps, all snapshots taken will be **application-consistent**, provided the QEMU Guest Agent remains installed and running. - If an application-consistent snapshot cannot be taken for any reason (for example, the QEMU Guest Agent is not running or VSS encounters an issue), the system will automatically fall back to creating a **crash-consistent** snapshot. ## Verifying Application-Consistent Snapshots When creating a snapshot, the Exoscale CLI now clearly indicates whether **application-consistent backups** are enabled for the instance. After the snapshot is created, the snapshot details will include the field **Application Consistent Snapshot**, showing `true` or `false`. ### Example ```bash exo compute instance snapshot create windows-acs-enabled -z hr-zag-1 ✔ Creating snapshot of instance "windows-acs-enabled"... 2m7s ┼─────────────────────────────────┼─────────────────────────────────────────┼ │ SNAPSHOT │ │ ┼─────────────────────────────────┼─────────────────────────────────────────┼ │ ID │ ae6eb677-2535-4892-a741-149d128d14e2 │ │ Name │ windows-acs-enabled-name_20260219075143 │ │ Creation Date │ 2026-02-19 07:51:43 +0000 UTC │ │ State │ exported │ │ Size (GB) │ 50 │ │ Instance │ windows-acs-enabled │ │ Zone │ hr-zag-1 │ │ Application Consistent Snapshot │ true │ ┼─────────────────────────────────┼─────────────────────────────────────────┼ ``` This makes it easy to confirm at snapshot time that the instance was backed up using an application-consistent snapshot. --- url: https://community.exoscale.com/product/compute/instances/how-to/rescue-mode/ --- # Use Rescue Mode Just like a physical machine, some user operations (such as a major upgrade of the operating system or a modification of the partition layout) could cause a Compute instance to be unable to boot normally. When an instance cannot boot normally, a rescue mode exists to access the root disk by booting from a different source. In this case, we use an open-source program called [netboot.xyz](https://netboot.xyz/) that can utilize a variety of Linux, BSD, ISO images, specialized installers, or utilities. ## Rescue Mode Prerequisites Rescue mode is not a default operation and can be operated only via the CLI or the API. Rescue mode requires: * a working [`exo` CLI](https://community.exoscale.com/tools/command-line-interface/index.md) environment * access to an [IAM API key](https://community.exoscale.com/product/security/iam/quick-start/index.md) * access to the Portal If you wish to use a custom ISO, it must be loaded in a publicly accessible URL. You can always use [Simple Object Storage](https://community.exoscale.com/product/storage/object-storage/quick-start/index.md). > [!WARNING] > Rescue Mode relies on netboot.xyz, which does not support Secure Boot. > Instances with Secure Boot enabled will therefore be unable to boot into Rescue Mode. > [!WARNING] > Exoscale is solely responsible for the instance's booting in rescue mode with the `netboot.xyz` loader. > Any operation performed in `netboot.xyz` and the repair of the instance itself are outside of Exoscale's standard support scope. > The examples in this guide are intended to point the user in the right direction without guaranteeing their outcome. > Knowledge of tooling and operations is required. > [!WARNING] > Rescue Mode relies on netboot.xyz, which requires network access for HTTP(S). > If the rescued instance has security groups restricting egress, you need to allow > port 80 (HTTP) and 443 (HTTPS) for `netboot.xyz` to properly function. > [!WARNING] > On smaller instance types, some `netboot.xyz` recovery modes may exceed > the RAM allocated to the instance. You nay need first to scale up your instance. ## Booting Into Rescue Mode To reboot in rescue mode, first start by shutting down your instance via the CLI or the Portal in the instance details: ```bash exo compute instance stop broken-vm ``` Then start your instance in either BIOS or UEFI rescue mode, depending on the template you are using. To start an instance in BIOS rescue mode: ```bash exo compute instance start --rescue-profile=netboot broken-vm ``` To start an instance in UEFI rescue mode: ```bash exo compute instance start --rescue-profile=netboot-efi broken-vm ``` ![](rescue.gif "Start Instance in Rescue Mode") The instance will now boot the `netboot.xyz` image. ## Accessing the Rescue Mode To access the rescue mode, log into the Portal and navigate to the instance detail view. Select `Console` in the `...` menu at the top right header. A new window will open and display the instance console and the `netboot.xyz` menu: ![](netboot.gif "netboot.xyz Rescue Menu from Console") > [!NOTE] > When booting a [Private Instance](https://community.exoscale.com/product/compute/instances/how-to/private-instances/index.md), > you need to enter the Failsafe Menu from `netboot.xyz` to perform a manual network configuration. You can now perform any operations needed to repair the instance and then reboot it normally after you have finished. After the instance has rebooted, it will exit rescue mode and try to boot from its root disk. ## Booting from a Custom ISO Image Through rescue mode, it is possible to boot an instance from an external ISO as long as the ISO supports VirtIO storage and network drivers. This method allows for bare metal recovery, for example. > [!NOTE] > The custom ISO must be located in a publicly accessible URL. You can always use our > [Simple Object Storage](https://community.exoscale.com/product/storage/object-storage/quick-start/index.md). To boot from an external ISO: * Start your instance in rescue mode as described above * From the main netboot.xyz menu, select `Tools -> Utilities` * Then select `netboot.xyz tools -> Test Distribution ISO` * Enter the public URL of the target ISO - e.g., https://releases.ubuntu.com/24.04/ubuntu-24.04.2-live-server-amd64.iso boots an Ubuntu Live CD ![](rescue_iso_recovery.gif "Netboot Rescue Menu from Console `iso-image`") ## Booting from a Windows Recovery Image If you need to recover a Windows instance from a Windows Recovery Image, you can use two ISOs we have provided, where all the needed [virtIO drivers](https://docs.fedoraproject.org/en-US/quick-docs/creating-windows-virtual-machines-using-virtio-drivers/) have already been integrated: - `http://sos-de-muc-1.exo.io/windows-recovery-image/w2k16` a Windows 2016 recovery image - `http://sos-de-muc-1.exo.io/windows-recovery-image/w2k19` a Windows 2019 recovery image - `http://sos-de-muc-1.exo.io/windows-recovery-image/w2k22` a Windows 2022 recovery image > [!WARNING] > Although provided for public use, the above Windows Recovery Images are provided as is, without warranties. > As for any other rescue mode operation, the user is solely responsible for the outcome of their actions, and > rescue operations beyond the booting of the `netboot.xyz` loader are out of the Exoscale standard support scope. ![](rescue-windows-recovery-boot.gif "Netboot rescue menu from console iso-image") To proceed: - Start your instance in rescue mode as described above - From the main `netboot.xyz` menu, select `Distributions -> Windows` - Select `Options -> Base URL` - Enter the URL corresponding to your instance's Windows version from the abovementioned options. Then enter any key to return to the `Windows` menu - After returning to the `Windows` menu, select `Load Microsoft Windows Installer...` - The Windows Recovery Image will load, and you will be prompted to enter some basic options. Click on __Next__ when ready - On the next screen, click on __Repair Your Computer__ You can now recover your Windows instance. ## Linux Password Reset via Rescue Environment Suppose you need to reset a Linux password, such as the root password, and cannot access the system normally. In that case, you can boot into a rescue environment and manually reset the password. Here's a step-by-step guide to doing this using a rescue environment like __`netboot.xyz`__. __Step 1: Access a Linux Rescue Environment via `netboot.xyz`__ - *Boot from `netboot.xyz`*: Use the ``netboot.xyz` tool to boot into a live or rescue environment for Linux: Stop the VM and boot it in rescue mode. Make sure your VM type is at least LARGE. ```bash exo compute instance start --rescue-profile=netboot instance_name ``` - *Select a Distribution*: In the `netboot.xyz` menu, choose an option to boot into Rescue Mode or a minimal environment. In this example, we will use the __Ubuntu__ rescue environment, but you can use any distribution available in the menu. __Step 2: Mount the Root Filesystem__ Once you're in the live environment, you'll need to identify and mount the root partition of your system. Follow these steps: - *Identify the Root Partition*: Use the following command to list available partitions and find your root partition: ```bash fdisk -l ``` Look for a partition named `/dev/sda1` or `/dev/vda1`. This is likely your root partition, where the Linux system is installed. - *Mount the Root Filesystem*: Mount the root filesystem to a directory like ``/mnt`` replace `/dev/vdX` with the root partition (e.g., `/dev/vda1`) ```bash mount /dev/vdX /mnt ``` - *Mount Additional Filesystems*: Mount the necessary system filesystems required for `chroot`: ```bash mount -t proc /proc /mnt/proc mount --rbind /sys /mnt/sys mount --rbind /dev /mnt/dev ``` __Step 3: Chroot into the Mounted Filesystem__ - *Enter the chroot environment*: Use `chroot` to change your root directory to the mounted filesystem: ```bash chroot /mnt ``` - *Reset the Password*: To reset the root password, run the following command: ```bash passwd root ``` If you need to reset the password for a specific user, replace ``root`` with the username: ```bash passwd ``` - *Exit the Chroot Environment*: After resetting the password, exit the chroot environment by typing: ```bash exit ``` __Step 4: Unmount Filesystems and Reboot__ - *Unmount the filesystems*: Unmount the filesystems you mounted earlier: ``` umount --recursive --lazy /mnt ``` - *Reboot the system*: Reboot the system with the following command: ```bash exo compute instance reboot "instance-name" ``` After the reboot, you should be able to log into the system with the new password via the console or SSH. --- url: https://community.exoscale.com/product/compute/instances/how-to/ssh-keypairs/ --- # Use SSH Keypairs SSH keypairs are a way to authenticate to your Linux instance (virtual machine) without using a password using the added security of [SSH Public-Key authentication](https://en.wikipedia.org/wiki/Public-key_cryptography). Public-Key authentication is both: * **Secure**: Breaking an SSH key requires so much time and computational power that these sorts of attacks are not practical in the real world. SSH keys are much more secure than even very strong passwords. * **Convenient**: Instead of managing per-instance passwords or sharing them across your organization, every person who needs access to your servers gives you their public key. You can then set up granular access control by adding those keys only to the relevant instances. If you need to revoke someone's access, simply revoking their key prevents them from logging in without affecting other people's workflow. Exoscale allows you to automatically provision Linux instances with SSH public keys to use for Public-Key authentication with SSHv2. Note that while you can have multiple keypairs in your account, the instance creation dialog only allows you to select one keypair. After the instance is created, you can allow additional public keys and set up more detailed access control using traditional means. Keypairs can be imported both by using the CLI or through the [Portal](https://portal.exoscale.com/compute/keypairs). > [!NOTE] > The supported SSH key formats are ssh-rsa and ssh-ed25519. ## Create a New SSH Keypair If you do not have an SSH keypair, you can create a new SSH keypair on your local machine with the following command in your terminal: `ssh-keygen -t rsa -b 4096 -C 'a-comment-to-identify-your-key'` You will be asked for a name and location to save your new keypair and for a password to protect it. Keypairs are usually stored in the `~/.ssh` folder, and the main keypair for a user is usually called `id_rsa`. You can then import the content of your new **public key** to Exoscale. ## Provision an Instance with a Keypair When creating a new instance, select the keypair you want to associate to that instance. The person holding the corresponding private key can log in via SSH. Please note that deleting a public key in the Portal does not automatically remove the authorized public key from a previously created instance. If you want to completely revoke a key, you need to do so manually by **deleting the key on every instance** holding it. ## Connecting to Your New Instance When your new instance has started and is running, you can connect to it via SSH. How to use SSH is out of the scope of this documentation, but assuming you have the following conditions: * You have SSH installed on your local machine * Your private key is stored in `~/.ssh/id_rsa` * Permissions of the `~/.ssh` folder (700) and of your private key (600) are correct * You opened TCP port 22 in your instance's [security groups](https://community.exoscale.com/product/networking/security-group/index.md) you should then be able to connect to your instance with: `ssh root@ip-address-of-your-instance` You may be asked for the password of your **private key** (not the instance password) if it has been set. You may also see a warning about the remote host identification: this is expected **on a first connection**, and you can trust the remote. --- url: https://community.exoscale.com/product/compute/instances/how-to/anti-affinity/ --- # Use Anti-Affinity Groups Anti-Affinity Groups let you specify which instances should run on separate hosts. In an HA cluster, for example, you could keep your instances on separate hypervisors to ensure more reliable fault tolerance. Two instances in the same anti-affinity group will spawn on __different hypervisors__. After creation, your instance will stay on its hypervisor for its entire life. It is best practice to define your groups in advance for a proper distribution strategy. An example of how Anti-Affinity Groups may prove helpful would be associating your instances with different groups based on their role. You could define one Anti-Affinity Group for the database servers and another Anti-Affinity Group for the front servers. In this way, any issue on one hypervisor will not affect your entire infrastructure. If you need more than eight instances per Anti-Affinity Group, you could split the group in two to grant the best spread. Anti-Affinity Groups let you specify which instances should run on separate hosts. In an HA cluster, for example, you could keep your instances on separate hypervisors to ensure more reliable fault tolerance. From __COMPUTE__ in the Portal, select the __ANTI-AFFINITY__ section. You can then create, delete, or view the details of your groups, and in the detail of a group, you can see the instances attributed to that group. ## Associating Anti-Affinity Groups When you create an instance, you will see a list of your Anti-Affinity Groups. You can choose to associate your instance with any number of groups. Please note that you will have this option __only during the instance creation__. Although there is no limit to the number of groups you may have, an Anti-Affinity Group cannot contain more than 8 instances. If a group is full, it will not be presented in the available options. ## How to Use Anti-Affinity Groups Two instances on the same group will be spawned on different hypervisors. After creation, your instance will stay on its hypervisor for its entire life. To define a proper distribution strategy, it is best practice to define your groups in advance. An example of how Anti-Affinity Groups may prove useful would be to associate your instances to different groups based on their role. You could define one Anti-Affinity Group for the database servers and another Anti-Affinity Group for the front servers. In this way, any issue on one hypervisor will not affect your entire infrastructure. If you find yourself needing more than 8 instances per Anti-Affinity Group, a possible strategy would be to split a group in two to grant the best spread possible. --- url: https://community.exoscale.com/product/compute/instances/how-to/bitlocker-windows/ --- # Use BitLocker on Windows Exoscale supports vTPM and Secureboot technology to allow usage of Windows security features like Bitlocker drive encryption. The required key to unlock the drive is safely stored in the vTPM and no interaction is required when rebooting the server. A recovery key is stored to allow recovery if the VM is migrated off Exoscale or the vTPM is lost. Tested on Windows Server 2022 and Windows Server 2025 using Exoscale Templates Tested on 20th of March 2025 ## Prerequisites As prerequisites you'll have to: * access to Exoscale environment UI * Sufficient rights to create a compute instance ## Create a Windows compute instance with vTPM and Secureboot enabled ### Via the Portal UI * Configure a Microsoft Windows Server instance as you need * Add one Block Storage Volume with 1GiB size - this will be used to store the Bitlocker Recovery Key during configuration * In the bottom of the configuration page select "TPM enabled" and "Secureboot" enabled * Create the instance ![](bitlocker-1.png "Windows Bitlocker Drive Encryption") ### Via the API * Add the following extensions to the create-instance API call: ``` "tpm-enabled": true, "secureboot-enabled": true ``` ## Install and enable Bitlocker ### Via the Portal UI * Configure the additional Block Storage Volume and format it. * Open the Server Manager and click on "Manage" -> "Add Roles and Features" * On the "Features" tab of the Wizard select "Bitlocker Drive Encryption" and add all required Features * Finish the Wizard and reboot once the installation of the Feature is done ![](bitlocker-2.png "Windows Bitlocker Drive Encryption") * After the reboot access the Windows Server and open the Explorer * Navigate to "This PC" and right click on the drive selected for encryption, click on "Turn on Bitlocker" ![](bitlocker-3.png "Windows Bitlocker Drive Encryption") * Follow the Wizard until asked how to backup the Recovery Key. Select "Save to a file" and select the 1GiB block volume, create a folder and store the file into that folder ![](bitlocker-4.png "Windows Bitlocker Drive Encryption") * Finish the Wizard to start encryption. You can let Windows Run the Bitlocker check before by selecting "Run Bitlocker system check", a reboot is required. * Click on "Start encrypting" * Open the explorer and navigate to the Block Storage Volume and copy the Recovery Key off to an safe destination outside of the compute instance. * Check the encryption is ongoing by openeing the Explorer, navigate to "This PC". Select "Manage Bitlocker" in the menu when right clicking on the disk. It should show "Bitlocker Encrypting" until the disk is encrypted, the status shows "Bitlocker on" once the disk is fully encrypted ![](bitlocker-5.png "Windows Bitlocker Drive Encryption") * Remove the Block Storage Volume in the instance configuration once the Recovery Key is secured outside of the instance ### Via Powershell * Configure the additional Block Storage Volume and format it. * Open a Powershell terminal with elevated rights * Install Bitlocker and required features: ```powershell Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools ``` * A reboot is required to finish the installation * After the reboot access the Windows Server and open a Powershell terminal with elevated rights * Enabled Bitlocker drive encryption on the selected drive: ```powershell Enable-BitLocker -MountPoint "C:" -EncryptionMethod "XtsAes256" -TpmProtector -UsedSpaceOnly -SkipHardwareTest ``` * Bitlocker will start to encrypt your drive. To check the status use: ```powershell Get-BitLockerVolume ``` ![](bitlocker-6.png "Windows Bitlocker Drive Encryption") * Create the recovery key: ```powershell Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector ``` ![](bitlocker-7.png "Windows Bitlocker Drive Encryption") * Copy the Recovery Key to a safe location outside of the compute instance. * Remove the Block Storage Volume in the instance configuration once the Recovery Key is secured outside of the compute instance. --- url: https://community.exoscale.com/product/compute/instances/how-to/instance-scaling/ --- # Scale an Instance Your application will grow in time, and so will your instances! During the life of your project, you will be able to resize your instances up and down, scale instance type (the combination of CPU cores and RAM) and disk size, and optimize them for your needs. Select the instance you wish to operate on. From the instance detail, you can access the scaling interface. > [!NOTE] > Please note that every scaling operation needs to be performed on a stopped instance. ## Scaling the Instance Type Scaling your CPU cores and the RAM of your instance is straightforward: * Stop your instance * Access the scaling view * Choose your new instance type * Restart your instance Remember that some instance types may be unavailable due to restrictions of your selected operating system. > [!NOTE] > The instance type can only be scaled in the same instance family. For example, scaling a standard instance type to > a GPU3 instance type is not supported. An exception is scaling across Standard, CPU and Memory optimized families. ## Scaling the Disk Size As for scaling the instance type, you can resize your disk size by steps of 1 GB. Here are the disk size limits per instance type: ### Standard, CPU and Memory Instance Types * Micro: 200 GB * Tiny to Large: 400 GB * Extra-Large to Mega: 800 GB * Titan to Jumbo: 1600 GB ### Storage Instance Type * Extra-Large: 2 TB * Huge: 3 TB * Mega: 5 TB * Titan: 10 TB * Jumbo: 15 TB ### GPU2, GPU3, GPU A30, GPU A5000 and GPU 3080ti Instance Types * Small: 800 GB * Medium: 1.2 TB * Large and Huge: 1.6 TB ### File System Resize on Linux and Windows For Linux OS, the file system resize happens automatically at boot time as long as the root file system isn't completely full #### Manual Disk Resize Procedure in Linux If automatic resizing does not occur, you can manually resize the file system using the following steps: 1. **Verify Available Space:** ```bash lsblk ``` Ensure the disk has unallocated space available. 2. **Resize the Partition (if needed) using** ``growpart``: ```bash sudo growpart /dev/ ``` Example: ```bash sudo growpart /dev/vda 1 ``` 3. **Resize the File System:** - If using **EXT4**, run: ```bash sudo resize2fs /dev/ ``` Example: ```bash sudo resize2fs /dev/vda1 ``` #### File System Resize on Windows For Windows OS, you will need to extend the partition size manually from **Disk Management** after boot. We prevent scaling down of your disk size, since it is difficult to safely assume where data is written on the volume. --- url: https://community.exoscale.com/product/compute/instances/how-to/instance-tags/ --- # Use Instance Tags Tags are key-value pairs associated with a resource, in our case an instance. Tags can be queried by the instance itself in order to take these values into account for its configuration. ## Creating Tags Tags can only be created once the instance is created. After your instance is created, go to the **COMPUTE** menu, choose the **INSTANCES** section, and click on your instance to display the instance details. In the instance tags area of the instance details page, you can add a key and its corresponding value. ## Usage Tags can be accessed directly from the instance. You will need to access the Exoscale API, querying the instance tags. See the [API documentation](https://community.exoscale.com/reference/api/index.md). --- url: https://community.exoscale.com/product/compute/instances/how-to/windows-specifics/ --- # Configure Windows Server Language ## Windows Server Language Selection Windows Server comes with English (en-EN), German (de-DE) and French (fr-FR) installed with English enabled as default language. You can configure your server to use any of the other languages as display and/or system language. User-Data can be used to configure the language of choice during instance creation. ### Userdata used for German language: ``` #ps1 & "C:\Program Files\Cloudbase Solutions\Cloudbase-init\Set-Language.ps1" -language German ``` ### Userdata used for French language: ``` #ps1 & "C:\Program Files\Cloudbase Solutions\Cloudbase-init\Set-Language.ps1" -language French ``` The language will be set at first login, followed by an automated logoff to activate the language for the administrator user. --- url: https://community.exoscale.com/product/compute/instances/how-to/labels/ --- # Use Labels Labels are key-value maps associated with a resource, such as [Load Balancer](https://community.exoscale.com/product/networking/nlb/overview/index.md), [Instance Pool](https://community.exoscale.com/product/compute/instances/how-to/instance-pools/index.md), et cetera. This allows you to attach additional meta information to an entity. ## Adding Labels Your resources can be labeled using the web portal as well as the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md) command. Here is an example of adding `env=prod` label on Instance Pool creation: ```bash exo compute instance-pool create web \ --zone ch-gva-2 \ --size 2 \ --description "Web servers" \ --instance-type "medium" \ --ipv6 \ --label env=prod \ --template 4635f170-4a5a-4443-8b95-006bb755060e ``` Output: ```bash ✔ Creating Instance Pool "web"... 21s ┼──────────────────────┼──────────────────────────────────────┼ │ ID │ 376d45be-9afe-4c65-996a-da68d9ef618b │ │ Name │ web │ │ Description │ Web servers │ │ Instance Type │ standard.medium │ │ Template │ TEST │ │ Zone │ ch-gva-2 │ │ Anti-Affinity Groups │ n/a │ │ Security Groups │ n/a │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ IPv6 │ true │ │ SSH Key │ - │ │ Size │ 2 │ │ Disk Size │ 50 GiB │ │ Instance Prefix │ pool │ │ State │ running │ │ Labels │ env:prod │ │ Instances │ pool-376d4-lwafb │ │ │ pool-376d4-mylpf │ ┼──────────────────────┼──────────────────────────────────────┼ ``` ## Usage > [!NOTE] > On update, labels can't be appended or changed - the existing key-value map will be replaced with a new one. ## Limitations - The label value should begin with a non-numeric character. It can contain only alphanumeric characters and the `*`, `+`, `!`, `-` (hyphen), `_` (underscore), and `?` symbols. The value is limited to 128 characters. --- url: https://community.exoscale.com/product/compute/instances/how-to/cloud-init-user-data/ --- # Use Cloud-Init and User Data User data is a way to automatically provision your instance with additional software or settings. You can provide a set of commands (a script) or enter cloud-config information as YAML. It is important to understand that the User Data provided will be used only when the machine is created. ## Cloud Init Datasources Historically, Exoscale templates used the `Cloudstack` cloud-init datasource. Since Cloud Init version `19.3`, Exoscale has its own datasource. Although the new Exoscale datasource is backwards-compatible with the Cloudstack datasource, new features such as managed private networks require using the Exoscale datasource. We recommend using the Exoscale datasource for all installations. ## Adding User Data When you create a new instance, the wizard lets you enter user data at the bottom of the form. You can find everything that can be done with user data and Cloud-Init in the [documentation](https://cloudinit.readthedocs.io/en/latest/index.html). ## Example: Script In this example, we install `screen` and `htop` on an Ubuntu instance using Apt after having upgraded all packages on an Debian/Ubuntu system. Add the following to the `User Data` field to install the `screen` package: ```yaml #cloud-config runcmd: - apt-get --yes upgrade - apt-get --yes install screen htop ``` **Note:** Cloud-Init has pre-built directives for many items. Therefore, the previous scripts launched as command lines can be achieved with: ```yaml #cloud-config package_upgrade: true packages: - screen - htop ``` ## Example: Cloud-Config YAML We will set our locale to en_US.UTF-8 using cloud-config YAML. Add the following YAML in the user data: ```yaml #cloud-config locale: "en_US.UTF-8" ``` ## Example: Installing Wordpress See our [Wordpress tutorial](https://www.exoscale.com/syslog/Hello-world/). ## Querying the User Data and Meta Data from the Instance `User Data` and `Meta Data` can be retrieved from an instance to integrate in scripts for example or configuration management tools. This information is published on the Link Local Address 169.254.169.254 which is private between the hypervisor and the running instance. * User Data (the cloud-config contents) ```bash curl http://metadata.exoscale.com/latest/user-data ``` * Meta Data, such as instance size or IP address ```bash curl http://metadata.exoscale.com/latest/meta-data curl http://metadata.exoscale.com/latest/meta-data/public-ipv4 ``` The list of available metadata is: | metadata name | description | | --- | --- | | availability-zone | The [zone - datacenter](https://www.exoscale.com/datacenters) in which the instance is running | | cloud-identifier | Returns "Exoscale Compute Platform" if running on Exoscale | | instance-id | The unique identifier or UUID for the instance | | local-hostname | The name of the instance as set during the add instance phase | | local-ipv4 | The primary network IP address of the instance | | public-hostname | Same as `local-hostname` | | public-ipv4 | The public IP address of the instance | | public-keys | The associated SSH public key associated to the instance | | service-offering | The size of the instance | | vm-id | Same as `instance-id` | ## Adding Password Management to Your Templates Exoscale provides an optional password reset feature that allows users to set a temporary admin or root password as well as reset the existing admin or root password from the Exoscale Portal. This password is provided to an instance via the Link Local Address 169.254.169.254 on port 8080: ```bash curl --header "DomU_Request: send_my_password" http://169.254.169.254:8080 ``` After the password is retrieved and changed on the running instance, issue a command to indicate that the password was saved and that it can be deleted: ```bash $ curl --header "DomU_Request: saved_password" http://169.254.169.254:8080 ``` **Notes:** * Linux-based distributions with a standard Cloud-Init implementation will follow the process outlined above automatically if the system allows for password-based logins. * Passwords are only provided one time back to the user who starts or resets an instance and are not persisted at the orchestration layer. --- url: https://community.exoscale.com/product/compute/instances/how-to/custom-templates/ --- # Build Custom Templates Exoscale provides various Compute instance [templates][templates] to choose from. However, you might want to customize templates to further suit your needs. In addition to using a [Cloud-Init configuration](https://community.exoscale.com/product/compute/instances/how-to/custom-templates/index.md#cloud-init) via an instance's user data or using a configuration management tool such as [Puppet][puppet] or [Ansible][ansible], you can also create your own customized templates. You can use custom templates to launch a custom operating system or custom template configuration on Exoscale, which allows you to deploy ready-to-go instances with minimal startup configuration. ## Create a Custom Template ### Using Packer HashiCorp [Packer][packer] is a popular tool for building cloud infrastructure compute images, which is the recommended method for creating custom templates on Exoscale. Starting from version 1.7, Packer supports a new `packer init` command which allows automatic installation of Packer plugins, including the `exoscale` [plugin][packer-exoscale-plugin]. You can read the [Packer documentation][packer-doc-init] for more information. #### Snapshot Instance Disk Using the `exoscale` Packer Builder (recommended) The `exoscale` [Packer Builder][gh-exoscale-packer-builder-doc] creates an instance in your Exoscale organization, logs into it via SSH to execute configured provisioners, and then snapshots the storage volume of the instance to register a custom template from the exported snapshot. This is the easiest way to create custom templates if you can use an existing Exoscale template as a base image. #### Import a Disk Image Using the `exoscale-import` Packer Post-processor The `exoscale-import` [Packer Post-processor][gh-exoscale-packer-post-processor-doc] takes a local disk image file (built using the Packer [QEMU][packer-builder-qemu-doc] or [File][packer-builder-file-doc] Builders) and imports it to Exoscale as a new Compute instance template. This method is useful if you need to build custom templates that are not based on an existing Exoscale template. ### Manually If you cannot use Packer, it is possible to build disk images and register them as custom templates manually. #### Prerequisites - The template image must be a **true** KVM-compatible .QCOW2 image (if you just rename your `.img`, `.iso` or `.vdmk` file, your template will fail). - The image must have the preallocation mode set to `off`. - The virtual size of the image must be between 10 GB and 1 TB. This size may differ from the actual file size, but the QCOW2 format must be within this range. - To deploy machines with attached local storage larger than 1.6 TB, you need a GPT partitioning table and UEFI boot. - To be registered, the template must be hosted on a publicly accessible HTTP or HTTPS URL, such as Exoscale [Object Storage](https://www.exoscale.com/object-storage/). - We strongly encourage you to [install cloud-init](#cloud-init) to get full functionality. KVM/QEMU tools are also required if you need to prepare your template to comply to specific requirements. For example, to convert a third party template from the `raw` format to QEMU .QCOW2 format: ```bash qemu-img convert -f raw -O qcow2 -o preallocation=off source.img destination.qcow2 ``` Additionally, you may need to resize the image to fit the minimum size required by Exoscale: ```bash qemu-img resize destination.qcow2 10G ``` We have Packer configuration examples in a [Git repository][packerex] to help you get started using the `exoscale-import` custom template building method. #### Cloud-Init Although not mandatory, **we strongly recommend** you install [cloud-init 19.3 or later][cloudinit] on Linux-based images. Cloud-init enables full integration with Exoscale. We can only provide limited support if you do not install cloud-init. Known limitations **if you do not use cloud-init** on your template: - The password reset functionality will not work - During startup, the instance will not be able to resize the partition table on the fly to match the desired VM local storage size. You will have to manually resize the partition table and the filesystem - Without cloud-init it will not be possible to pass user data to the instance at boot - The Exoscale Portal will present some inconsistencies and limited functionality We will show an example with cloud-init 19.3, the native Exoscale cloud-init datasource. During startup, cloud-init will determine the appropriate datasource (Exoscale) by reading desktop management interface (DMI) information. No specific customization is needed. You can take a look at our documentation to learn more about [cloud-init](https://community.exoscale.com/product/compute/instances/how-to/cloud-init-user-data/index.md). > [!NOTE] > The Exoscale datasource is only available for cloud-init version 19.3 or later. In case the 19.3 version is not yet available on > your platform, please use the following legacy configuration instead: ```yaml datasource_list: - Cloudstack ``` > [!NOTE] > Please note that the legacy datasource suffers from some known problems that might prevent some > Exoscale features from working as intended**. #### Virtual Disk Size The template's *Virtual Disk Size* will determine the initial space available to the filesystem. Your template needs to have the ability to automatically adapt the filesystem disk size to the actual volume size in order to use the entire space at startup. Namely, it needs: 1. A template has a virtual disk size of 10 GB 2. The template is used to start an instance with a disk size of 200 GB 3. Without the ability to scale automatically, the filesystem has only 10 GB available, and an extra non-partitioned and non-used space of 190 GB 4. You will still be invoiced for the full volume size, which is 200 GB This ability is enabled through [cloud-init](#cloud-init). You can adapt your filesystem partitions manually, but its important to keep these points in mind to avoid unexpected results or billing changes. #### Register a Custom Template After your template image is ready, you must host it on a publicly accessible HTTPS service such as Exoscale [Object Storage](https://community.exoscale.com/product/storage/object-storage/index.md), as you will need to a URL to point to during template registration. You can register a template using the `exo` [CLI](https://community.exoscale.com/tools/command-line-interface/index.md), the API, or the Portal in the Templates section. The following information is required to register a template: * The template name * The template image file checksum (MD5) to ensure import integrity * The template location (a public URL to retrieve the template) > [!NOTE] > If the `from-snapshot` flag is used, the `url` and `checksum` flags are no longer required. There are also optional properties you can set: * A template description * Whether the template allows user [password reset](https://community.exoscale.com/product/compute/instances/how-to/cloud-init-user-data/index.md#adding-password-management-to-your-templates) * Whether the template allows a [SSH key](https://community.exoscale.com/product/compute/instances/how-to/ssh-keypairs/index.md) to be copied during instance creation * A username: this is used to better integrate with Exoscale tools, such as the instance details view in the Portal or the CLI. This will allow shortcuts and commands that connect to the instance to be correctly displayed. * A template boot-mode (Legacy or UEFI) Note: a Custom Template is registered per [zone][zone]. If you want to use your template in multiple zones, you have to repeat this step for each zone you want the template to be used in. This is what a template registration looks like in the CLI: ```bash exo compute instance-template register \ my-custom-template \ https://example.net/my-template.qcow2 \ 15dc21cc9505a68cc0380a9a66654536 \ --zone de-fra-1 \ --description "My custom template" \ --username "foo" ``` You can run the `exo compute instance-template --help` command for more information on commands and options. After you register your custom template, you can use the template to deploy an instance with all Exoscale tools - the Portal, the CLI, the API or third-party integrations. #### From a Compute Instance Snapshot In addition to building a custom template from scratch, you can also export a Compute instance volume snapshot and register the exported file as you would do with a manually created disk image. This allows you to effectively build a template from a snapshot: ```bash SNAPSHOT_ID=ce295d39-421e-49c4-81f7-9890c3db3600 TEMPLATE_ID=$(exo compute instance snapshot show --output-template {{.ID}} $SNAPSHOT_ID) $ BOOTMODE=$(exo compute instance-template show --output-template {{.BootMode}} ${TEMPLATE_ID}) $ USERNAME=$(exo compute instance-template show --output-template {{.DefaultUser}} ${TEMPLATE_ID}) exo compute instance-template register \ my-template \ --zone de-fra-1 \ --from-snapshot $SNAPSHOT_ID \ --description "A template registered from a snapshot" \ --boot-mode $BOOTMODE \ --username $USERNAME ``` Output: ```bash ✔ Registering template "my-template"... 11m21s ┼──────────────────┼──────────────────────────────────────┼ │ TEMPLATE │ │ ┼──────────────────┼──────────────────────────────────────┼ │ ID │ 0a7bfba5-9854-479b-8095-676ca73bcfcd │ │ Name │ my-template │ │ Description │ A template registered from a snapshot│ │ Family │ other (64-bit) │ │ Creation Date │ 2021-09-17 13:17:46 +0000 UTC │ │ Visibility │ private │ │ Size │ 10 GiB │ │ Version │ │ │ Build │ │ │ Default User │ centos │ │ SSH key enabled │ true │ │ Password enabled │ true │ │ Boot Mode │ legacy │ │ Checksum │ 33d592a033bfe0aefafafeb0834d37d9 │ ┼──────────────────┼──────────────────────────────────────┼ ``` We have a blog post on [creating templates from snapshots][snapshottemplatepost] if you want to learn more. ### Based on an ISO File - Create a Linux [instance](https://community.exoscale.com/product/compute/instances/quick-start/index.md) on the Exoscale Portal - Install KVM, virt-manager and all necessary packages to configure a virtual instance. - Download your ISO file on your instance > [!NOTE] > If you are using a Mac, you will need to install xquartz and reboot your machine. - Connect to your instance using -Y option - Make sure to add your user to the libvirt group - Now that everything is set, you can start creating a new virtual machine (graphically): ```bash virt-manager ``` Gives you the following selections: ```bash Create new VM Local browse for iso file Begin Installation ``` You can refer to this article on *Tecmint* on [how to create virtual machines in KVM using Virt-Manager](https://www.tecmint.com/create-virtual-machines-in-kvm-using-virt-manager/) for additional information. > [!NOTE] > Those actions can also be performed using Virtualbox or VMware. - After installation is finished, an image will be created (.qcow2 file) - Resize the image ```bash qemu-img convert -C -O qcow2 -p source.qcow2 target.qcow2 ``` - Calculate an MD5 checksum for registration - Refer to Register a Custom Template (previous section) ## Limitations - Custom Templates actively used by an instance cannot be deleted. - Compute instances that run a Custom Template cannot be moved from one organization to another, as Custom Templates are organization-specific. - Templates not using cloud-init will not integrate entirely with Exoscale, and require manual handling. See the [cloud init](https://community.exoscale.com/product/compute/instances/how-to/custom-templates/index.md#cloud-init) section for more details. [templates]: https://www.exoscale.com/templates/ [puppet]: https://www.puppet.com/ [ansible]: https://www.redhat.com/en/ansible-collaborative [packer]: https://developer.hashicorp.com/packer [packer-doc-init]: https://developer.hashicorp.com/packer/docs/commands/init [exopricing]: https://www.exoscale.com/pricing/ [gh-exoscale-packer-builder-doc]: https://github.com/exoscale/packer-plugin-exoscale/blob/main/docs/builders/exoscale.md [packer-exoscale-plugin]: https://github.com/exoscale/packer-plugin-exoscale [gh-exoscale-packer-post-processor-doc]: https://developer.hashicorp.com/packer/docs/commands/init [packer-builder-qemu-doc]: https://github.com/exoscale/packer-plugin-exoscale/blob/main/docs/builders/exoscale.md [packer-builder-file-doc]: https://developer.hashicorp.com/packer/docs/builders/file [packerex]: https://github.com/exoscale/packer-examples [cloudinit]: https://cloudinit.readthedocs.io/en/latest/index.html [zone]: https://www.exoscale.com/datacenters/ [snapshottemplatepost]: https://www.exoscale.com/blog/exporting-snapshot-custom-template/ --- url: https://community.exoscale.com/product/compute/instances/how-to/flexible-storage-management/ --- # Manage Flexible Storage The Exoscale __Flexible Storage Template__ aims to empower users so they can manage their instance's disk/storage as they deem fit. The storage template provides: - A minimalistic [Debian][debian-os]-based template with no extraneous components and only what is required to get you started (namely, `cloud-init` and `sudo`) - A built-from-scratch template using the [Debian][debian-cdimage] `netinst` installation media and the `ssh-server` installation scenario (AKA `tasksel`) - Uses [UEFI][wikipedia-uefi] boot mode and a [GPT][wikipedia-gpt] partition table (as opposed to Debian's stock cloud image) to enable support for disk images larger than 2 TB (along [Exoscale Storage Optimized Instances][exoscale-offering-storage]) - Uses [LVM][wikipedia-lvm] logical partitioning (as opposed to Debian's stock cloud image) to allow you to manage partitions and file systems as you deem fit The flexible storage template is based on - but deviates minimally from - Debian's stock installation configuration, so it is easy to embrace for users accustomed to Debian or Ubuntu. [debian-os]: https://www.debian.org/ [debian-cdimage]: https://cdimage.debian.org/cdimage/release/current/amd64/iso-cd/ [exoscale-offering-storage]: https://www.exoscale.com/pricing/#storage-optimized-instances [wikipedia-uefi]: https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface [wikipedia-gpt]: https://en.wikipedia.org/wiki/GUID_Partition_Table [wikipedia-lvm]: https://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 ## Deploying a Flexible Storage Instance The flexible storage template is based on - but deviates minimally from - Debian’s stock installation configuration, so it is easy to embrace for users accustomed to Debian or Ubuntu. ```bash exo compute instance create storage \ --zone \ --template 'Exoscale Flexible Storage 10' \ --disk-size 50 \ --ssh-key ``` [exoscale-doc-cli]: https://community.exoscale.com/tools/command-line-interface/ ### Log In After the instance is deployed, log into it via SSH with the CLI: ```bash exo compute instance ssh storage # [output] debian@storage:~$ ``` Then use `sudo` to obtain administrative privileges: ```bash debian@storage:~$ sudo -i # [output] root@storage:~# ``` (For the sake of readability, we will hide the `root@storage:...#` command prompt in further shell commands examples.) ## Flexible Storage Management ### Create Flexible Storage Instance Creating a flexible storage instance is similar to creating any other Exoscale Compute instance. Here is an example with the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md): ```bash exo compute instance create storage \ --zone \ --template 'Exoscale Flexible Storage 10' \ --disk-size 50 \ --ssh-key ``` ### Log In via SSH After the instance is deployed, log into it via SSH with the CLI: ```bash exo compute instance ssh storage # [output] debian@storage:~$ ``` Then use `sudo` to obtain administrative privileges: ```bash debian@storage:~$ sudo -i # [output] root@storage:~# ``` > [!NOTE] > For readability, further shell commands will omit the `root@storage:...#` command prompt. ## Default Partition Layout Thanks to the [Linux Logical Volume Manager (LVM)][wikipedia-lvm], as well as following the [Linux Filesystem Hierarchy Standard (FHS)][wikipedia-fhs] and general best practices, the flexible storage template's initial partitioning separates a few systems. These are `ext4`-formatted partitions, namely `/` (root), `/var`, `/tmp` (as well as `/boot` and `/boot/efi`): ```bash lsblk ``` List block devices (disks/partitions): ```bash # [output] NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 50G 0 disk |-vda1 254:1 0 511M 0 part /boot/efi |-vda2 254:2 0 512M 0 part /boot `-vda3 254:3 0 9G 0 part |-vg.flex-lv.root 253:0 0 5G 0 lvm / |-vg.flex-lv.var 253:1 0 2G 0 lvm /var `-vg.flex-lv.tmp 253:2 0 1G 0 lvm /tmp ``` > [!NOTE] > The `50G` disk (`vda`) space not being entirely used by underlying partitions (`vda`). [wikipedia-fhs]: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard As opposed to most other templates, partition sizes will __not automatically grow__ after an instance's disk is [resized](https://community.exoscale.com/product/compute/instances/how-to/instance-scaling/index.md#scaling-the-disk-size). You can create or resize partitions according to your requirements. ## Storage Management Operations Further, as an example, we will demonstrate both: - how to create a new `/data` partition with the `xfs` filesystem - how to resize the `/var` partition ### Create New Logical Volume You can create as many partitions or file systems as you need. Here is an example with a `xfs`-formatted `/data` partition - install XFS utilities: ```bash apt-get install xfsprogs ``` Create the LVM Logical Volume (LV): ```bash lvcreate -n lv.data -L 20G vg.flex ``` Output: ```bash Logical volume "lv.data" created. ``` Show the LVM Logical Volume (LV) details: ```bash lvdisplay /dev/mapper/vg.flex-lv.data ``` Output (partial): ```bash --- Logical volume --- LV Path /dev/vg.flex/lv.data LV Name lv.data VG Name vg.flex LV Status available LV Size 20.00 GiB ``` Create the filesystem: ```bash $ mkfs.xfs -L DATA /dev/mapper/vg.flex-lv.data ``` Output (partial): ```bash meta-data=/dev/mapper/vg.flex-lv.data isize=512 agcount=4, agsize=1310720 blks ``` Create the filesystem mountpoint: ```bash mkdir -p /data ``` Mount the filesystem: ```bash $ mount /dev/mapper/vg.flex-lv.data /data ``` Show the filesystem capacity/usage: ```bash df -h /data ``` Output: ```bash Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg.flex-lv.data 20G 53M 20G 1% /data ``` You may want to add to `/etc/fstab` to allow automatic mounting at boot time: ```bash grep /data /etc/fstab ``` Output: ```bash /dev/mapper/vg.flex-lv.data /data xfs defaults 0 2 ``` ### Resize the Physical Volume The first step is to grow the `/dev/vda3` partition, corresponding to the LVM Physical Volume (PV) - show LVM Volume Groups (VGs) ```bash vgs ``` Output: ```bash VG #PV #LV #SN Attr VSize VFree vg.flex 1 3 0 wz--n- <9.00g 1.00g ``` Grow the LVM-backing disk partition: ```bash growpart /dev/vda 3 ``` Output: ```bash CHANGED: partition=3 start=2097152 old: size=18872320 end=20969472 new: size=102760415,end=104857567 ``` Grow the LVM Physical Volume (PV): ```bash pvresize /dev/vda3 ``` Output: ```bash Physical volume "/dev/vda3" changed 1 physical volume(s) resized or updated / 0 physical volume(s) not resized ``` Show LVM Volume Groups (VGs): ```bash $ vgs ``` Output: ```bash VG #PV #LV #SN Attr VSize VFree vg.flex 1 3 0 wz--n- <49.00g 41.00g ``` > [!NOTE] > The increase of `VFree` space in the LVM Volume Group (VG). ### Resize a Logical Volume To resize (or extend) an existing LVM Logical Volume (LV) and partition (with `/var` as an example) - grow the LVM Logical Volume (LV): ```bash lvresize -L +10G /dev/mapper/vg.flex-lv.var ``` Output: ```bash Size of logical volume vg.flex/lv.var changed from <2.00 GiB (511 extents) to <12.00 GiB (3071 extents). Logical volume vg.flex/lv.var successfully resized. ``` Grow the filesystem: ```bash resize2fs /dev/mapper/vg.flex-lv.var ``` Output: ```bash resize2fs 1.44.5 (15-Dec-2018) Filesystem at /dev/mapper/vg.flex-lv.var is mounted on /var; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 2 The filesystem on /dev/mapper/vg.flex-lv.var is now 3144704 (4k) blocks long. ``` Show the filesystem capacity/usage: ```bash df -h /var ``` Output: ```bash Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg.flex-lv.var 12G 217M 12G 2% /var ``` [ansible]: https://www.ansible.com/ [cloudinit]: https://cloudinit.readthedocs.io/en/latest/index.html [exotemplates]: https://www.exoscale.com/templates/ [gh-exoscale-packer-builder-doc]: https://github.com/exoscale/packer-plugin-exoscale/blob/main/docs/builders/exoscale.md [gh-exoscale-packer-post-processor-doc]: https://github.com/exoscale/packer-plugin-exoscale/blob/main/docs/post-processors/exoscale-import.md [packer-builder-file-doc]: https://www.packer.io/docs/builders/file [packer-builder-qemu-doc]: https://www.packer.io/plugins/builders/qemu [packer-doc-init]: https://www.packer.io/docs/commands/init [packer-exoscale-plugin]: https://github.com/exoscale/packer-plugin-exoscale [packer-qemu]: https://www.packer.io/docs/builders/qemu.htm [packer]: https://www.packer.io/ [packerex]: https://github.com/exoscale/packer-examples [puppet]: https://puppet.com/ [snapshottemplatepost]: https://www.exoscale.com/syslog/exporting-snapshots-from-exoscale-registering-as-custom-template/ [zone]: https://www.exoscale.com/datacenters/ --- url: https://community.exoscale.com/product/compute/instances/how-to/private-instances/ --- # Create Private Instances At Exoscale each compute instance is provided with a public IP by default. At creation, public IP assignment can be controlled and offers three modes: - `ipv4`: The instance is assigned a Public IPv4 address - `dual`: The instance is assigned a Public IPv4 and a Public IPv6 address - `none`: No public IP attachment is done on the instance, it is a *private instance* Instances initially assigned with an IPv4 address can be promoted to dual-stack (IPv4 and IPv6), but private instances remain without public IP assignments for their entire lifetime. Similarly, public instances cannot be converted to private, ensuring their public IP assignment persists throughout their lifecycle. You can create a private instance from the Portal, or You can also use the [CLI](https://community.exoscale.com/tools/command-line-interface/index.md). Here is an example of Private Instance creation using the CLI: ```bash exo compute instance create my-private-instance --private-instance ``` Output: ```bash ✔ Creating instance "my-private-instance"... 13s ┼──────────────────────┼──────────────────────────────────────┼ │ COMPUTE INSTANCE │ │ ┼──────────────────────┼──────────────────────────────────────┼ │ ID │ 5921300e-6bae-491b-8b15-1e927aef403a │ │ Name │ my-private-instance │ │ Creation Date │ 2023-10-02 20:12:37 +0000 UTC │ │ Instance Type │ standard.medium │ │ Template │ Linux Ubuntu 22.04 LTS 64-bit │ │ Zone │ de-fra-1 │ │ Anti-Affinity Groups │ n/a │ │ Deploy Target │ - │ │ Security Groups │ n/a │ │ Private Instance │ Yes │ │ Private Networks │ n/a │ │ Elastic IPs │ n/a │ │ IP Address │ - │ │ IPv6 Address │ - │ │ SSH Key │ - │ │ Disk Size │ 50 GiB │ │ State │ running │ │ Labels │ n/a │ │ Reverse DNS │ │ ┼──────────────────────┼──────────────────────────────────────┼ ``` This newly created instance will not have any network. Most likely your use case involves some communication with other instances and services, and you should consider attaching a private instance to a [private network](https://community.exoscale.com/product/networking/private-network/index.md). ## Private Instance Metadata Instance metadata is typically served over the http://169.254.169.254 address, *private instances* will instead see an additional read-only drive containing their metadata, compatible with the [cloud-init](https://cloudinit.readthedocs.io/en/latest/) `NoCloud` configuration source. ### Caveats The following caveats apply: - Windows templates are not able to read metadata from the additional drive, standard Exoscale templates will require setting the password manually from the web portal console after the first boot. - Metadata drives remain mounted and may contain credential information (for instance after a password reset request), metadata should thus be acted upon quickly --- url: https://community.exoscale.com/product/compute/instances/how-to/running-llms-on-gpus/ --- # Run LLMs on GPUs For a quick and easy setup, we’ll run a containerized vLLM server on one of Exoscale’s GPU instances. This guide shows an “advanced-but-practical” setup you can adapt for production. You can also run LLMs more easily and natively by simply installing [Ollama](https://ollama.com/) in section [Access the instance using SSH](#access-the-instance-using-ssh) and be done immediately. ## Provisioning a GPU Instance ### Request GPU Quota GPU instance types (e.g., GPU A30, A5000, A40) require granted quotas. You can request access via the [Exoscale Portal](https://portal.exoscale.com): 1. Go to the **Create Instance** view. 2. Find your **GPU instance type** of choice. 3. Select the **zone** where it is available. 4. Click **Enable** for that type. Please be sure that your overall **GPU quota** is sufficient! You can request additional quota under **Organization → Quotas**. Once granted, the quota shows up under **Organization → Quotas → GPUs**. ### Launch GPU instance To list available GPU instance-types, execute the following command: ```shell exo compute instance-type list | grep gpu ``` Create a GPU instance with 24GB of vRAM (e.g., Small GPUA30 in ch-gva-2 or Small GPUA5000 in at-vie-2): ```shell exo compute instance create llm-a30 \ --instance-type gpua30.small \ --zone ch-gva-2 \ --ssh-key \ --security-group \ --template "Linux Ubuntu 24.04 LTS 64-bit" ``` Depending on your needs, adjust for A5000 or A40 by using types `gpua5000.medium` or `gpu3.medium` (and the corresponding zone). ## Prepare VM Environment ### Access the instance using SSH ```shell ssh root@ ``` For a simplified setup, the machine is already ready to run Ollama at this point: ```shell apt update && apt install ollama ollama run llama3.3:latest ``` Ollama is not considered production-ready and scalable. ### Install Docker & NVIDIA support ```shell # install docker curl -fsSL https://get.docker.com | sh # add nvidia production package repository curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | tee /etc/apt/sources.list.d/nvidia-container-toolkit.list # install nvidia drivers apt update apt install -y nvidia-driver-570 nvidia-container-toolkit systemctl restart docker # Validate NVIDIA runtime is available: docker run --gpus all nvidia/cuda:12.9.1-base-ubuntu24.04 nvidia-smi ``` ## Run vLLM Inference Server Three steps for running an OpenAI-compatible vLLM Inference Server: 1. Get a Hugging Face Token 2. Deploy via Docker Compose 3. Test Inference ### Get Hugging Face Token Create/retrieve a Hugging Face Token with read access to your model: https://huggingface.co/settings/tokens ### Deploy via Docker Compose Write the following content to a file called `docker-compose.yml`: ```yaml services: vllm: image: vllm/vllm-openai:gptoss deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] ports: - "8000:8000" ipc: host environment: - HUGGING_FACE_HUB_TOKEN= - NVIDIA_VISIBLE_DEVICES=all - VLLM_ATTENTION_BACKEND=TRITON_ATTN_VLLM_V1 volumes: - ~/.cache/huggingface:/root/.cache/huggingface command: > --host 0.0.0.0 --port 8000 --model openai/gpt-oss-20b --dtype auto --trust-remote-code --tensor-parallel-size 1 --max-num-seqs 64 ``` Launch: ```shell docker compose up -d docker logs -f vllm ``` vLLM will then download and optimize the model for your GPU, which will take a few minutes. Once you see the following logs, you know that your server is ready: ``` (APIServer pid=1) INFO 08-21 08:31:01 [api_server.py:1857] Starting vLLM API server 0 on http://0.0.0.0:8000 (APIServer pid=1) INFO 08-21 08:31:01 [launcher.py:29] Available routes are: (APIServer pid=1) INFO 08-21 08:31:01 [launcher.py:37] Route: /openapi.json, Methods: HEAD, GET ... (APIServer pid=1) INFO: Started server process [1] (APIServer pid=1) INFO: Waiting for application startup. (APIServer pid=1) INFO: Application startup complete. ``` ### Test Inference ```shell curl -X POST localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model":"openai/gpt-oss-20b", "messages":[{"role":"user","content":"What is the capital of Switzerland?"}], "max_tokens":50 }' ``` ## Considerations - Use [nvidia-smi](https://developer.nvidia.com/system-management-interface) to monitor utilization during load testing. - Ensure you have enough GPU memory to avoid OOM. - Ports, instance stopping/starting, and SSH key handling are best automated via Terraform or scripts. - Be careful of exposing your endpoint to the public internet without added security and protections. --- url: https://community.exoscale.com/product/compute/instances/how-to/gpu-mig-partitioning/ --- # Use GPU MIG Partitioning [Multi-Instance GPU (MIG)](https://www.nvidia.com/en-us/technologies/multi-instance-gpu/) allows you to partition a physical GPU into multiple isolated instances, each with dedicated memory and compute resources. This is particularly useful when you need to run multiple workloads that don't require a full GPU. ## Prerequisites - A GPU instance with a MIG-capable GPU. On Exoscale, the following GPU types support MIG: - [GPU A30](https://www.exoscale.com/gpu/a30/) - [GPU RTX Pro 6000](https://www.exoscale.com/gpu/rtx6000/) - A supported NVIDIA datacenter driver installed in the guest (R460 or later) ## Install NVIDIA Driver Install a supported NVIDIA datacenter driver in the guest. For MIG support, you need a driver that supports MIG (R460 or later). We recommend using the server driver variant for stability: ```shell # Add NVIDIA repository curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \ gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list # Install driver (requires reboot) sudo apt update sudo apt install -y nvidia-driver-570-server sudo reboot ``` ## Check MIG Capability Verify that your GPU supports MIG: ```shell nvidia-smi -L nvidia-smi -q | less ``` Look for MIG capability in the output. If your GPU supports MIG, you'll see MIG devices listed. ## Enable MIG Mode Enable MIG mode on the GPU: ```shell sudo nvidia-smi -i 0 -mig 1 ``` Replace `0` with the appropriate GPU index if you have multiple GPUs. ## Create GPU Partitions List available MIG profiles: ```shell sudo nvidia-smi mig -lgip ``` Create a GPU partition using the profile ID: ```shell sudo nvidia-smi mig --create-gpu-instance --default-compute-instance -i 0 ``` Replace `` with the ID of the desired MIG profile from the previous step. The `--default-compute-instance` flag creates a compute instance along with the GPU instance. > On GPU A30, MIG configurations persist beyond the lifecycle of the instance. > Make sure to [clean up the configuration](#clean-up-mig-configuration-applicable-for-a30-only) before stopping or deleting the VM to avoid impacting future workloads. ## Verify MIG Devices Confirm the created MIG devices: ```shell nvidia-smi -L ``` You should see multiple MIG devices listed, each with its own UUID. ## Clean Up MIG Configuration (applicable for A30 only) On GPU A30, MIG configurations persist on the GPU even after a virtual machine is stopped or deleted. This means that if a GPU is reused by another instance, previously created MIG partitions may still be present and affect expected behavior. To avoid conflicts or unexpected errors, it is recommended to remove any MIG configuration before stopping or deleting the instance. Also apply this command in case the GPU instance started with an unwanted MIG configuration to access the full GPU A30 performance. Example: ```shell sudo nvidia-smi mig -i 0 -dgi ``` ## Run Workloads on MIG Devices ### Using CUDA Set the `CUDA_VISIBLE_DEVICES` environment variable to target a specific MIG device: ```shell export CUDA_VISIBLE_DEVICES=MIG-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ``` Replace the UUID with the MIG device you want to use. You can get the UUID from the `nvidia-smi -L` output. ### Using Docker First, install Docker and the NVIDIA container toolkit: ```shell # Install Docker curl -fsSL https://get.docker.com | sh # Add NVIDIA container toolkit curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \ gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo systemctl restart docker ``` You can run Docker containers against specific MIG devices using the NVIDIA runtime: ```shell docker run --gpus ' MIG-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' nvidia/cuda:12.9.1-base-ubuntu24.04 nvidia-smi ``` To run two Docker containers each using a different MIG partition: ```shell # Get MIG device UUIDs MIG_UUIDS=$(nvidia-smi -L | grep MIG | awk -F'MIG-' '{print "MIG-" $2}' | awk -F')' '{print $1}') # Extract individual UUIDs MIG1=$(echo $MIG_UUIDS | cut -d' ' -f1) MIG2=$(echo $MIG_UUIDS | cut -d' ' -f2) # Run container on first MIG device docker run --gpus "$MIG1" -it --name container1 nvidia/cuda:12.9.1-base-ubuntu24.04 nvidia-smi # Run container on second MIG device docker run --gpus "$MIG2" -it --name container2 nvidia/cuda:12.9.1-base-ubuntu24.04 nvidia-smi ``` ## Considerations - MIG partitions are fixed in size and cannot be resized after creation - Each MIG instance has dedicated memory that cannot be oversubscribed - Not all GPUs support MIG - check NVIDIA's documentation for supported hardware - MIG mode must be enabled before creating partitions and cannot be disabled without rebooting - On some GPUs (such as A30), MIG configurations persist until explicitly removed. On Blackwell generation, MIG configurations do not persist across reboots. ## References: - [Use GPU MIG Partitioning (on SKS)](https://community.exoscale.com/product/compute/containers/how-to/gpu-mig-partitioning/index.md). --- url: https://community.exoscale.com/product/compute/instances/service-boundaries/ --- # Service Boundaries - Instances - [Limits and Quotas - Instances](https://community.exoscale.com/product/compute/instances/service-boundaries/limits-and-quotas/index.md) - Instances Limitations and Quotas - [SLA - Instances](https://community.exoscale.com/product/compute/instances/service-boundaries/sla/index.md) - Instances Service Level Agreement - [Pricing ↗︎](https://www.exoscale.com/pricing/#standard-instances) --- url: https://community.exoscale.com/product/compute/instances/service-boundaries/limits-and-quotas/ --- # Limits and Quotas - Instances ## Limits The following table shows which limits are enforced on Compute usage. It also highlights some of the characteristics of the product: Instance Quotas : Organizations can create up to 20 instances. Quota increases can be requested via the Exoscale Portal. Special Instance Types : Access to certain instance types (e.g., GPU, Mega, Titan, Jumbo) requires activation by the support team. Requests can be made during instance creation. vTPM and Secureboot : This setting conflicts with netboot profiles as those are not signed and will not boot on an instance with Secureboot enabled. Zone Constraints : Instances and Instance Pools are confined to a single zone and cannot be migrated across zones post-creation. Elastic Ips : Organizations are initially limited to 5 Elastic IPs. Instances sharing an Elastic IP cannot communicate with each other using that IP. Block Storage Attachments : A maximum of 5 block storage volumes can be attached to a single instance by default. Anti-Affinity Groups : Although there is no limit to the number of groups you may have, an Anti-Affinity Group cannot contain more than 8 instances. ## Quotas Compute Instances : Are initially limited to 20 per organization. You can ask for a quota increase in the [quotas section](https://portal.exoscale.com/organization/quotas/) of the web portal. GPU Quotas : GPU instance deployment is controlled through GPU quotas, which are managed per GPU type. By default, newly created organizations receive a quota of 0 for all GPU types. If you require GPU resources, you can request additional quota by opening a Support ticket. You can view your current GPU quotas using the Exoscale CLI: ``` bash exo api list-quotas ``` > [!NOTE] > GPU quotas are operational limits that authorize your organization to deploy GPU instances. They do not reserve GPU capacity or guarantee hardware availability. > GPU quotas may be reviewed and adjusted over time based on platform capacity and resource usage. > Existing running GPU instances are not affected if your GPU quota is reduced. > [!NOTE] > **Need guaranteed GPU capacity?** > If your workloads require guaranteed GPU availability, contact us via a Support ticket to discuss GPU Capacity Reservations through a Volume Commitment Contract. Specific Instance : type families as GPU and bigger instance types as e.g. Mega, Titan, and Jumbo, need to be enabled by our support team. You can ask for their activation directly in the instance creation view. ## Availability Instances are available in all zones. --- url: https://community.exoscale.com/product/compute/instances/service-boundaries/sla/ --- # SLA - Instances ## Compute Instances Service Level Agreement (SLA) These product-specific SLAs define the Service Availability Target for Exoscale Compute Instances. It applies to each Client using the Service and for each instance individually. Capitalized terms used herein but not defined herein shall have the meanings set forth in the Exoscale Terms and Conditions or EUSA, whichever applies. ### SLA | Metric | Target | Definition | | -------- | -------- | ------------ | | Compute Service Availability | >= 99.95% Monthly Uptime Percentage | The percentage of total minutes in a calendar month during which Exoscale Compute Instances are available and operational for use. This objective ensures consistent access to your virtual machines, with a monthly overall availability of 99.95%. | | GPU Servers Service Availability | >= 99.95% Monthly Uptime Percentage | The percentage of total minutes in a calendar month during which Exoscale GPU Server instances are available and operational for use. This objective ensures consistent access to your virtual machines, with a monthly overall availability of 99.95%. The availability is not depleted in case of a notified proactive maintenance: downtime of the underlying hypervisor requiring an offline migration of the instance. | ### Non-binding objectives | Metric | Target | Definition | | -------- | -------- | ------------ | | VM Creation Success Rate | Out of every 1000 VM creation API requests, at least 999 are expected to succeed. | This metric measures the success rate of API requests to create new Compute Instances, including scenarios where capacity might be unavailable. | | Snapshot Durability | >= 99.999999999% Durability | Snapshots of Compute Instances are stored with high durability to protect against data loss. Leveraging our redundant object storage backend, snapshots are designed for long-term integrity, ensuring safe and resilient point-in-time backups of your instances. | #### Nature of the Non-binding Objectives Commitment - This provision does not constitute a legally binding obligation but rather specifies a target value that Exoscale will endeavor to achieve. - In this case, no monetary credits or other compensation will be granted if the objective is missed. - This is provided for transparency and capacity‑planning purposes only and may be affected by temporary capacity shortages, including GPU resource constraints. ### Other product specifications For detailed product features, technical specifications, and tutorials, please refer to the [Exoscale documentation](https://community.exoscale.com/product/compute/instances/index.md). ### Exclusions No compensation shall be granted to the Client if the failure to comply with the Compute Service Level Objective is due to any of the following reasons: * Unavailability of components under the client's control, such as client-side software, applications, or operating system configurations installed on the Compute Instances. For the complete list of SLA exclusions, please refer to the [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/). ### Client Responsibilities While Exoscale is responsible for the availability and operation of the Compute and GPU Server infrastructure, Client remains responsible for all components deployed within their instances, including but not limited to: * Operating system, custom templates, applications, middleware, runtime environments, and dependencies. * Data stored on Compute Instances, including data classification, retention, and deletion. * Configuration and management of firewalls, security groups, network rules, and exposed services. * Identity and access management, including SSH keys, user accounts, associated roles and credentials. * Client defined encryption and recovery keys. * Reviewing access, logs, and vulnerabilities. * Backup strategy, snapshot usage, restore validation, and disaster recovery planning. * Monitoring of resource usage, performance, and costs. Snapshots and storage durability provided by Exoscale do not replace client managed backup and recovery processes. Clients are responsible for defining appropriate backup policies and regularly validating restore procedures. The Service Level Agreement applies solely to Compute Instance and GPU Server availability as defined above and does not cover application performance, operating system behavior, data integrity, or Client workload configuration. For a complete explanation of the shared responsibility framework between Exoscale and Clients, please see the [Exoscale Shared Responsibility Model documentation](https://community.exoscale.com/platform/compliance/shared-responsability-model/index.md). ### Retribution The standard retribution and SLA credit schemes apply for this product as described under [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or [EUSA](https://www.exoscale.com/eusa/) whichever applies. In the event that the Monthly Uptime Percentage for Exoscale Compute Instances falls below the committed Service Level Objective, the Client will be eligible for service credits as follows: | Monthly Uptime Percentage | Service Credit Percentage of Monthly Service Fees for Affected Resources | | -------- | -------- | | from 99.95% to 98.3% | 50% | | below 98.3% | 100% | #### Claim Service Credit To request a service credit, refer to the Service Unavailability Credit section of the [Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies. --- url: https://community.exoscale.com/product/compute/instances/reference/ --- # Reference - Instances - [API Instances](https://community.exoscale.com/reference/api/compute/instance/index.md) - All operations on Instances (external) - [CLI Instances](https://community.exoscale.com/reference/cli/exo/compute/instance/index.md) - All commands on Instances (external)