Blog

1. Overview

This article lists the guest operating system templates currently available on the Cloud platform.

Some legacy operating system templates are available for compatibility or migration purposes. However, operating systems that have reached End of Life (EOL) are not recommended for new production deployments because they may no longer receive security updates or patches from the vendor.

For production environments, it is recommended to use actively supported operating systems such as Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, or Rocky Linux 9.

2. Supported Linux Operating Systems

Notes

• CentOS 7.x reached End of Life (EOL) in June 2024. It may remain available for compatibility or migration purposes but is not recommended for new deployments.
• Debian 11.x is approaching End of Life (EOL) in August 2026. For long-term production workloads, use Debian 12.x or another actively supported Linux distribution.

3. Supported Windows Operating Systems

Notes

• Windows Server 2019 reached End of Life (EOL) in January 2024. It no longer receives vendor security updates or patches. It may remain available for compatibility or migration purposes but is not recommended for new deployments.

4. Important Considerations

Architecture Support

Cloud guest operating system templates are currently supported on AMD-based x86_64 virtual machine infrastructure.

GPU Workloads

GPU-enabled workloads are currently available only in the IN-WEST2 region.

The NVIDIA driver installation guide for L4 GPU Virtual Machines currently supports the following operating systems:

• Ubuntu 20.04 LTS
• Ubuntu 22.04 LTS
• Ubuntu 24.04 LTS

GPU Driver Compatibility

GPU driver installation and compatibility depend on the selected guest operating system version and workload requirements.

Verify application and driver compatibility before deploying GPU workloads.

1. Overview

This guide explains how to identify and resolve common errors that may occur while creating a Virtual Machine (VM) on the Cloud platform.

2. Common Virtual Machine Creation Errors

2.1 No Available Public IPs

Cause

The selected region has no available public IP addresses.

Resolution

• Select a different region (for example, create the VM in West-3 instead of West-2).
• If a public IP is not required, create the VM using only a private IP address.

2.2 Insufficient Quota

Cause

The project has reached its allocated quota for resources such as CPU, RAM, storage volumes, or GPU.

Resolution

• Delete any unused Virtual Machines or storage volumes.
• If additional resources are required, request a quota increase from Cloud Support.

2.3 Network or Subnet Not Found

Cause

The selected network is incorrect, or the required network or subnet has been deleted.

Resolution

• Select the correct network and subnet during Virtual Machine creation.
• If the required network or subnet does not exist, create a new private network and subnet.

2.4 Volume Creation Failed

Cause

The storage backend encountered an error, or there is insufficient storage capacity.

Resolution

• Try creating the Virtual Machine again.
• Verify that the storage quota has not been exceeded.
• Create the volume manually and attach it to the Virtual Machine.

3. When to Contact Support

Contact Cloud Support if:

• The same error occurs in multiple regions.
• No public IP addresses are available in the selected region.
• There are issues related to images or flavors.

Provide the following information when contacting support:

• Screenshot of the error message.
• Region name.
• Virtual Machine flavor.
• Operating system image.
• Time when the error occurred.

1. Overview

Snap is a universal package management system for Linux that packages applications together with all required dependencies. This allows software to run consistently across different Linux distributions.

This guide explains what Snap is, its main features, how to install it on different Linux distributions, and how to use it.

2. What Is Snap?

Snap is a Linux packaging system that bundles applications with their required dependencies.

This helps ensure that applications run reliably on different Linux distributions without requiring additional packages.

3. Features of Snap

Snap provides the following features:

• Includes all required dependencies within the package.
• Supports automatic background updates.
• Works across multiple Linux distributions.
• Uses security confinement (sandboxing) to help isolate applications.

4. Why Use Snap?

Snap simplifies software installation and management by providing:

• Compatibility across multiple Linux distributions.
• Automatic updates.
• Application isolation through sandboxing.
• Access to newer software versions than those available in traditional package repositories.

Examples:

Install Visual Studio Code:

sudo snap install code –classic

Install Spotify:

sudo snap install spotify

Install Docker:

sudo snap install docker

5. Snap Components

Snap consists of the following components:

• Snap Packages – Self-contained applications that include their dependencies.
• snapd – The background service that manages Snap packages.
• Channels – Release channels such as stable, candidate, beta, and edge, allowing you to choose between stable releases and newer features.

6. Install Snap

Ubuntu

Snap is usually installed by default.

Verify the installation:

snap version

If Snap is not installed:

sudo apt update
sudo apt install snapd

Debian

sudo apt update
sudo apt install snapd
sudo systemctl enable –now snapd.socket

Fedora

sudo dnf install snapd
sudo ln -s /var/lib/snapd/snap /snap

CentOS / RHEL

sudo yum install epel-release
sudo yum install snapd
sudo systemctl enable –now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap

Arch Linux

sudo pacman -S snapd
sudo systemctl enable –now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap

7. Common Snap Commands

Search for a Package

snap find <package-name>

Install a Package

sudo snap install <package-name>

Remove a Package

sudo snap remove <package-name>

List Installed Packages

snap list

Update Installed Packages

sudo snap refresh

Example

Install VLC:
sudo snap install vlc

Display installed Snap packages:

snap list

8. Troubleshooting

Snap Service Is Not Running

Start and enable the Snap service:

sudo systemctl enable –now snapd.socket

Snap Command Not Found

Verify that snapd is installed and that the system PATH is configured correctly.

Permission Issues

If required, run Snap commands with sudo.

9. Conclusion

Snap provides a simple way to install and manage software on Linux by packaging applications together with their dependencies.

It supports multiple Linux distributions, provides automatic updates, and helps avoid dependency conflicts while keeping software up to date.

1. Overview

This guide explains how to identify and resolve health check failures when using a Cloud Load Balancer.

2. Operating System Checks

2.1 Verify That the Application or Service Is Running

Linux

Check the service status:

systemctl status <service-name>

Restart the service if required:

systemctl restart <service-name>

Verify that the application is listening on the required port:

ss -tulnp | grep <port>

Windows

Open Services (services.msc) and verify that the required service is running.

Check the listening port:

netstat -ano | findstr <port>

Find the process using the PID:

tasklist /FI “PID eq <pid>”

2.2 Test the Health Check Endpoint Locally

Linux

curl -I http://localhost:<port>/<health-path>

or

curl http://127.0.0.1:<port>/<health-path>

Windows (PowerShell)

Invoke-WebRequest -Uri http://localhost:<port>/<health-path> -UseBasicParsing

Note: For HTTP or HTTPS health checks, the endpoint should return an HTTP status code between 200 and 299.

2.3 Check the Operating System Firewall

Linux

For systems using firewalld:

sudo firewall-cmd –list-all

For Ubuntu using UFW:

sudo ufw status

For systems using iptables:

sudo iptables -L -n

Windows

Get-NetFirewallRule | Where-Object { $_.Direction -eq ‘Inbound’ -and $_.Enabled -eq ‘True’ } | Format-Table DisplayName,Profile,Action

2.4 Verify That the Application Is Listening on the Private Interface

If the application is listening only on 127.0.0.1, the Load Balancer cannot reach it.

The application should listen on 0.0.0.0 or the VM’s private IP address.

Linux

ss -tulnp | grep <port>

or

netstat -tulnp | grep <port>

2.5 Test Connectivity from Another Internal Virtual Machine

Test the backend service from another VM on the same network.

curl http://<backend-private-IP>:<port>/<health-path>

or

telnet <backend-private-IP> <port>

or

nc -vz <backend-private-IP> <port>

Note: If direct connectivity fails, resolve the backend application, firewall, or operating system issue before troubleshooting the Load Balancer.

2.6 Check Application Logs

Linux

View the service logs:

journalctl -u <service-name> -n 200

View system logs:

tail -n 200 /var/log/messages

View web server logs:

tail -n 200 /var/log/nginx/error.log

or

tail -n 200 /var/log/httpd/error_log

Windows

• Open Event Viewer and review the Application and System logs.
• For IIS, review the logs located at:

C:\inetpub\logs\LogFiles

2.7 Check System Resources

Linux

top
free -m
df -h

Windows

Use Task Manager to check:

• CPU usage
• Memory usage
• Disk usage

3. Load Balancer Checks

3.1 Verify the Health Check Configuration

Confirm that the health check settings match the backend application.

Verify the following:

• Protocol: TCP, HTTP, or HTTPS
• Port: Matches the backend service port
• Health Check Path (HTTP/HTTPS): Returns an HTTP status code between 200 and 299

Recommended settings:

3.2 Verify Backend Pool Configuration

Confirm the following:

• The correct backend Virtual Machine is added to the backend pool.
• The correct private IP address is selected, especially if the VM has multiple network interfaces.
• The backend service port is configured correctly.

3.3 Verify Firewall and Security Rules

Ensure that the backend firewall or security rules allow inbound traffic from the Load Balancer’s private IP range on the configured health check port.

If the Load Balancer cannot reach the backend because of firewall restrictions, the health checks will fail.

1. Overview

This guide explains how to resolve the “No Bootable Device” error that may occur when installing Windows 11 from an uploaded ISO file.

The issue is caused by missing virtual TPM (vTPM) support, which is required for Windows 11 installation.

2. Issue

When creating a new Virtual Machine (VM) and installing Windows 11 using an uploaded ISO, the VM may fail to boot and display the following message:

Booting from Hard Disk…
Boot failed: not a bootable disk
No bootable device.

3. Cause

This issue occurs because the Virtual Machine is not configured with vTPM (Virtual Trusted Platform Module).

Windows 11 requires hardware features such as:

• TPM 2.0
• Secure Boot support

If vTPM is not enabled, the installation may fail or the ISO may not be recognized as a bootable device.

4. Solution

Follow these steps to create and deploy the Windows 11 Virtual Machine.

Step 1: Select the Region

Log in to the Cloud dashboard and select the region where you want to deploy the Virtual Machine.

Step 2: Open the Advance Panel

Navigate to:
Advance Panel → Create Virtual Machine

Step 3: Configure the Virtual Machine

Configure the following settings:

• Deploy From: Image
• Image: Select the uploaded Windows 11 ISO
• Volumes:
  • Boot Volume
  • CD/DVD Volume
• Flavor: Select the required CPU and RAM configuration.
• Network Interfaces: Assign the required network.

Step 4: Configure the Boot Settings

Enable the following options:

• UEFI Boot (automatically selected)
• vTPM (Virtual Trusted Platform Module)

Secure Boot is optional and may remain disabled if it is not required.

Step 5: Deploy the Virtual Machine

Click Deploy.

The Virtual Machine will boot from the Windows 11 installation media and display the Windows setup screen.

5. What Is vTPM?

vTPM (Virtual Trusted Platform Module) is a virtual implementation of the TPM 2.0 hardware module.

It provides cryptographic security functions for Virtual Machines and allows Windows 11 to detect the required TPM functionality during installation.

6. Why vTPM Must Be Enabled

Windows 11 requires TPM 2.0 for installation and secure operation.

If vTPM is not enabled:

• The Virtual Machine may not recognize the Windows ISO as a bootable device.
• The installation may fail with errors such as:
  • No bootable device
  • This PC can’t run Windows 11

1. Overview

MTR (My Traceroute) is a network diagnostic tool that combines the functionality of ping and traceroute.

Unlike ping or traceroute, which provide a single snapshot of the network, MTR continuously monitors the network path and displays real-time information about latency and packet loss.

This guide explains what MTR is, how it works, how to interpret the results, and how to use it on different operating systems.

2. What Is MTR?

MTR (My Traceroute) is a network troubleshooting tool that:

• Combines the features of ping and traceroute.
• Displays real-time latency and packet loss statistics.
• Continuously monitors the route between your system and the destination host.

MTR is commonly used by system administrators, network engineers, and support teams to identify network connectivity issues.

3. Why Use MTR?

MTR helps you:

• Identify where packet loss occurs.
• Detect network latency at different hops.
• Determine whether the issue is:
  • Within the local network.
  • With the Internet Service Provider (ISP).
  • Within a transit provider’s network.
  • At the destination server.
• Collect information for troubleshooting and support cases.

4. How MTR Works

MTR combines two network tools:

• Traceroute, which identifies the path packets take to the destination.
• Ping, which continuously sends packets to each hop and measures latency and packet loss.

Unlike traceroute, MTR continuously updates the results, allowing you to monitor network conditions in real time.

5. Understanding MTR Output

Running the following command:

mtr <hostname>

produces output similar to:

Interpreting the Results

• High packet loss at the first hop usually indicates a local network issue.
• Packet loss beginning at one hop and continuing through later hops may indicate an issue with the network provider.
• Packet loss shown on one intermediate hop, while later hops show no loss, usually indicates ICMP rate limiting and is generally not a network problem.
• Latency that increases and remains high across subsequent hops may indicate network congestion.

6. Using MTR

Linux

Install MTR

Ubuntu / Debian

sudo apt update
sudo apt install mtr

CentOS / RHEL

sudo yum install mtr

Run MTR

mtr google.com

Generate a report using 100 packets:

mtr -r -c 100 google.com

macOS

Install MTR using Homebrew:

brew install mtr

Run MTR:

sudo mtr google.com

Windows

Use WinMTR, the graphical version of MTR.

1. Download WinMTR.
2. Run WinMTR.exe.
3. Enter the destination hostname (for example, google.com).
4. Start the test.

7. Common Use Cases

MTR can be used for:

• Troubleshooting slow website connections.
• Identifying packet loss caused by an ISP.
• Monitoring connectivity between data centers.
• Collecting network information for support cases.

8. Best Practices

• Use at least 100 packets (-c 100) for more accurate results.
• Test the connection in both directions whenever possible.
• Do not assume packet loss on an intermediate hop is a problem unless it continues to later hops.
• Use MTR together with other network tools such as ping, iperf, and netstat for a complete analysis.

9. Conclusion

MTR is a real-time network diagnostic tool that combines the features of ping and traceroute.
By continuously monitoring latency and packet loss, MTR helps identify network issues more accurately and provides useful information for troubleshooting and escalation.

1. Overview

This guide explains how to authenticate with the Cloud API in the West 2 region using an Application Credential ID and Secret Key.

After successful authentication, you will receive an authentication token that can be used for subsequent API requests.

2. Required Credentials

Before you begin, ensure you have the following credentials provided by the administrator:

• Application Credential ID (Sample: f963abac76886493#########)
• Project ID (Sample: 831f026XXXXXXXXX83de1ce1e923)
• Application Credential Secret (Sample: my_super_secret_pass)

Note: You can refer to the appropriate article to generate these credentials.

3. Prerequisites

Ensure the following tools are installed on your system:

• curl
• jq

4. Install Required Tools

Install curl

CentOS / RHEL / AlmaLinux / Rocky Linux

sudo yum install curl -y

Ubuntu / Debian

sudo apt update
sudo apt install curl -y

Install jq

Ubuntu / Debian

sudo apt update
sudo apt install -y jq

CentOS / RHEL / AlmaLinux

sudo yum install -y jq

Verify the Installation

Verify that both utilities are installed successfully.

jq –version
curl –version

5. Verify API Availability

Before authenticating, confirm that the API endpoint is reachable.
Run:

curl -kv https://in-west2.controlcloud.app:5000/

If the API is available, the command returns the response headers indicating that the Keystone authentication service is reachable.

6. Authenticate with the API

Send a POST request to obtain an authentication token.

curl -ksD – -o /dev/null \
-H “Content-Type: application/json” \
-d ‘{
“auth”: {
“identity”: {
“methods”: [
“application_credential”
],
“application_credential”: {
“id”: “d638abac76884533#########”,
“secret”: “my_super_secret_pass”
}
}
}
}’ https://in-west2.controlcloud.app:5000/v3/auth/tokens

Replace the sample ID and Secret with the credentials provided to you.

7. Expected Response

If authentication is successful, the API returns:

• HTTP 201 Created
• An authentication token in the response headers.

If authentication fails, the API returns:

• HTTP 401 Unauthorized

8. Troubleshooting

Authentication Failed (401 Unauthorized)

If you receive a 401 Unauthorized response, verify the following:

• Confirm that the Application Credential ID and Secret are correct.
• Verify that you are using the correct authentication URL.
• Check that the API endpoint is reachable by running:

curl -kv https://in-west2.controlcloud.app:5000/

• Ensure that the credentials have permission to access the API.

9. View Authenticated Session Details

To retrieve information about the authenticated session, run:

curl -X GET “https://in-west2.controlcloud.app:5000/v3/auth/tokens” \
-H “X-Auth-Token: <AUTH_TOKEN>” \
-H “X-Subject-Token: <AUTH_TOKEN>” \
-H “Content-Type: application/json” | jq

Replace <AUTH_TOKEN> with the authentication token returned during the authentication request.

Response Details

The command returns information such as:

• Authenticated user details.
• Assigned roles.
• Accessible projects.
• Available service endpoints.

10. Conclusion

After successful authentication, an authentication token is returned.

Use this token in the X-Auth-Token header when making additional API requests, and store it securely for future use.