FAQ

Frequently Asked Questions about Hyperstack.

Topics

• VM access and SSH
• Billing
• Drivers and GPUs
• Network and firewalls
• Data centers
• Storage and volumes
• Glossary

About Hyperstack

Hyperstack is a GPU-as-a-service platform that allows you to easily deploy any workload in the cloud on the latest infrastructure, paying only for what you consume. Hyperstack virtual machines deliver exceptional speed and performance at cost-effective rates. The platform is designed for user-friendly operation, simplifying the creation and management of GPU virtual machines and related resources.

---

VM Access and SSH

Q: How do I enable SSH access to my virtual machine?

A: Create a firewall enabling incoming traffic on port 22. Click here to learn how.

Hyperstack

To enable SSH access to your virtual machine in Hyperstack:

1. Within Hyperstack, navigate to the Virtual Machines page.

2. Click on the virtual machine for which you intend to enable SSH access.

3. In the Firewall Rules section of the virtual machine, click the Enable SSH access button. This action will automatically generate a firewall rule allowing incoming traffic from any IP (0.0.0.0/0) on port 22 via the TCP protocol.

Incoming SSH traffic to this virtual machine will now be permitted.

Before

After

Infrahub API

Send a POST request to /core/virtual-machines/{virtual-machine-id}/sg-rules endpoint replacing virtual-machine-id in the path with the ID of the virtual machine for which you want to enable SSH access, and complete the body of the request as specified below.

• Include the integer ID of the virtual machine that this firewall rule is being attached to in the path of the request as follows:

  • /core/virtual-machines/{VM ID HERE}/sg-rules

• Complete the request body with the following fields and values:

  Field Name	Field Input	Description
  remote_ip_prefix	0.0.0.0/0	Allows traffic from any source IP address.
  direction	ingress	Designates that the firewall rule is for incoming traffic.
  ethertype	IPv4	Indicates the use of Internet Protocol version 4.
  protocol	icmp	Specifies the use of Internet Control Message Protocol.
  port_range_min	22	Specifies the minimum port value for SSH.
  port_range_max	22	Specifies the maximum port value for SSH.

Request

curl -X POST https://infrahub-api.nexgencloud.com/core/virtual-machines/{virtual-machine-id}/sg-rules \
  -H "accept: application/json" \
  -H "api_key: YOUR API KEY" \
  -d '{
        "remote_ip_prefix": "0.0.0.0/0",
        "direction": "ingress",
        "ethertype": "IPv4",
        "protocol": "tcp",
        "port_range_min": 22, 
        "port_range_max": 22
    }'

note

To authenticate Infrahub API requests, add an authorization header to your API request that contains an API Key as follows:

  -H "api_key: YOUR API KEY"

Q: I don't have access to the SSH key associated with my virtual machine. How can I login without it?

A: Use VNC console recovery mode to access your VM without the need for an SSH key. Click here to learn how.

The following instructions guide you through accessing your virtual machines without the need for an SSH key, utilizing the VNC console recovery mode. Note that these procedures are designed for Ubuntu 22 instances; details may differ for other operating systems.

1. In Hyperstack, go to the "Virtual Machines" tab and click on the virtual machines "NAME" you want to access, to view its details.

2. Within the VM's details, click "Open VNC Console".

3. To access the grub menu, click the "Send CtrlAltDel" command (found at the top right of the console), and then click on the black console window while holding the "Shift" key.

   

4. Select "Advanced options" > "Recovery mode" from the grub menu.

   

5. Use arrow keys to navigate to the menu option labeled "root", and press "Enter" (it may appear distorted due to console messages, this is expected).

   

6. Root access to the system will be granted, allowing you to carry out administrative tasks.

   

   How to reset your Ubuntu password:
   a. Send the "passwd" command.
   b. Enter your new password twice.

7. Execute the "reboot now" command to restart the virtual machine, and the system changes will take effect.

Now, with root privileges, you can access and manage your virtual machine without needing your SSH key.

Q: Can I provision my VM to use a password instead of an SSH key?

A: To enable password-based authentication for your VM, use a script during deployment. Click here to learn how.

To access your VM, use the SSH key that was associated with your VM during the deployment process, or configure your VM during deployment to allow password-based authentication. Please note that accessing your VM via SSH is more secure than using a password-only connection.

Bash

To enable password-based login for your VM, set a user password during provisioning using the following Bash script:

echo "root:Your-Super-Secure-Password" | chpasswd
echo "ubuntu:Another-Super-Secure-Password" | chpasswd
sed -i -E 's/^#?(PermitRootLogin\s+).*/\1yes/' /etc/ssh/sshd_config
sed -i -E 's/^#?(PasswordAuthentication\s+).*/\1yes/' /etc/ssh/sshd_config
systemctl restart sshd

YAML

To enable password-based logins to your VM, you must set a password for your user. During the provisioning process, use the following Cloud-Init script to enable password authentication and set user passwords:

#cloud-config
ssh_pwauth: True
chpasswd:
  expire: false
  users:
  - {name: root, password: Your-Super-Secure-Password, type: text}
  - {name: ubuntu, password: Another-Super-Secure-Password, type: text}
runcmd:
  - sed -i -E 's/^#?(PermitRootLogin\s+).*/\1yes/' /etc/ssh/sshd_config
  - systemctl restart sshd

References:

• Infrahub Docs | Initialization Configuration
• Infrahub Docs | Secure Shell (SSH) Access

Q: Attempting to connect with an SSH key is leading to too many authentication failures.

A: This can occur for a few reasons. Click here to learn how to resolve it.

This occurs for one of two reasons:

• You have not configured your SSH client with a valid authentication method.
• Your SSH client is configured with multiple authentication methods, and it tries too many that fail before it reaches the one that succeeds.

To debug this issue, consider the following steps:

• Utilize the -G flag, such as ssh -G -i .ssh/id_rsa ubuntu@<public-ip>. This command prints the client's configuration. Verify that the configuration appears correct, particularly checking the user, hostname, and identityfile fields. (Note: identityfile is another term for private key.)
• Enable debug output in your SSH client: ssh -vvv -i .ssh/id_rsa ubuntu@<public-ip>. Each v in -vvv increases the level of debug verbosity. With this output, you can pinpoint where the authentication handshake fails.

If you observe that your SSH client is attempting too many incorrect keys instead of your preferred ones, you can force it to stop using the other keys by employing the IdentitiesOnly configuration option. This can be enabled in two ways:

• If you use a .ssh/config file, add a line to your virtual machine's configuration stating IdentitiesOnly yes.
• If you prefer not to modify your .ssh/config, add it to your command line: ssh -i .ssh/id_rsa -o IdentitiesOnly=yes ubuntu@<public-ip>

References:

• Infrahub Docs | Secure Shell (SSH) Access

Q: How do I access my virtual machine from my local Ubuntu after adding an SSH key pair?

A: Click here to learn how to connect to you VM via SSH.

To gain access to your virtual machine via Secure Shell (SSH), follow the procedures found here.

References:

• Infrahub Docs | Secure Shell (SSH) Access

Q: If I don't enable the public IP address, how can I access my virtual machine?

A: A public IP is required for SSH access; however, you can access your Windows VM via the VNC console. Learn more here.

Linux:
For virtual machines running Linux-based operating systems, setting a public IP is required because SSH key pairs must be used for login.

Windows:
For virtual machines running Windows operating systems, you need to set an administrator password through a VNC console login. However, to access your virtual machines from your local machine, a public IP address is necessary.

Q: I'm experiencing complete packet loss when attempting to ping the public IP associated with a virtual machine.

A: Click here to learn how to resolve this issue by creating a firewall rule.

To solve this issue, create a firewall Rule through the Infrahub API that permits incoming ICMP (ping) traffic from any IP address for your virtual machine.

Follow these steps:

1. Create a new API key or copy your existing API key. For additional information on accessing your API key, click here.

2. In Hyperstack, navigate to the virtual machines report (2nd menu option) and copy the ID field of the VM for which you are creating a firewall rule.

3. Execute the following command in a terminal, replacing <VM-ID> with the virtual machine ID and <API-KEY> with your API key.

Request

curl 'https://infrahub-api.nexgencloud.com/core/virtual-machines/<VM-ID>/sg-rules' -X POST \
	-H 'api-key: <API-KEY>' \
	--data-raw '{
        "remote_ip_prefix":"0.0.0.0/0",
        "direction":"ingress",
        "ethertype":"IPv4",
        "protocol":"icmp"
    }'

note

You can share the necessary <VM-ID> values with us, granting authorization to carry out these actions on your behalf.

This issue is currently under investigation, and we anticipate it will be resolved in an upcoming release.

References:

• Infrahub Docs | Firewall Rules
• Infrahub Docs | API Keys

Billing

Q: Which virtual machine states incur billing costs?

A: VMs are only billed when in the ACTIVE and SHUTOFF states. Click here to learn more.

We bill only for VMs in the ACTIVE and SHUTOFF states. For HIBERNATED VMs, charges apply only to the storage and public IP addresses that remain attached during hibernation. Transitional states like HIBERNATING or RESTORING do not incur charges. Additionally, the ERROR state resulting from failed VM operations is also charge-free.

States and billing status of virtual machines

The table below details the virtual machine (VM) states, indicating whether each state results in charges.

Power state	Description	Billing
ACTIVE	The VM is running. This is the standard working state.	Billed
SHUTOFF	The VM has been successfully shutdown. Billing continues for VMs in the SHUTOFF state as all resources, including CPUs, memory, GPUs, storage, and public IP addresses, remain allocated to the VM.	Billed
HIBERNATED	When a VM is in the HIBERNATED state, its configuration and disk data are saved, and all resources, except storage and IP addresses, are de-allocated. Billing continues only for the storage and public IP addresses that remain attached to the VM.	Partially Billed

User-initiated states

The table below outlines the user-initiated transitional states of virtual machines. It's important to note that none of these transitional states result in charges. Additionally, the ERROR state, which occurs due to failed operations on the VM, incurs no charges.

Power state	Description	Billing
HIBERNATING	The VM is transitioning into a HIBERNATED state.	Not Billed
RESTORING	The VM operating system and software are restarting from HIBERNATION and returning to an ACTIVE state.	Not Billed
STARTING	The request to start the VM has been accepted.	Not Billed
STOPPING	The VM is being stopped. This is the transition state between ACTIVE and SHUTOFF.	Not Billed
REBOOTING	The VM is being restarted, simulating the process of unplugging and rebooting a physical machine.	Not Billed
CREATING	The request to create the VM has been accepted.	Not Billed
BUILD	The VM is being built with the specified configuration.	Not Billed
DELETING	The VM is being deleted.	Not Billed
ERROR	The VM is stuck in an error state. The last operation on the virtual machine was unsuccessful.	Not Billed

References:

• Infrahub Docs | States and Billing Status of Virtual Machines

Q: How do I check the billing status of my virtual machines?

A: You can easily check the status of your virtual machines in Hyperstack. Click here to learn how.

You can easily check the status of your virtual machines by navigating to the Virtual Machines page in Hyperstack. This user-friendly interface offers a convenient way to view the running states of your virtual machines, as shown in the example below.

The status of your virtual machines can also be accessed through the List virtual machines Infrahub API endpoint by making a GET request to /core/virtual-machines. This API call provides detailed information about the running states of your virtual machines as, illustrated below.

Example request

curl -X GET "https://infrahub-api.nexgencloud.com/v1/core/virtual-machines" \
  -H "accept: application/json"\
  -H "api_key: YOUR API KEY" 

Response

{
    "status": true,
    "message": "Getting VMs successful",
    "instances": [
        {
            "id": 731,
            "name": "documentation-vm",
            "status": "HIBERNATED",
        },
        ...
    ]
}

The status field indicates the current running state of the virtual machine. In this example, the status is HIBERNATED, signifying that the virtual machine's state is saved, and all resources, except for storage and IP address, are de-allocated. Billing continues only for the attached storage and public IP address during the hibernation period.

References:

• Infrahub Docs | States and Billing Status of Virtual Machines

Q: What is the difference between the virtual machine states SHUTOFF and HIBERNATED?

A: Click here to learn about the differences between VM states in Hyperstack.

When a virtual machine is in the SHUTOFF state, billing persists as the resources it utilizes are exclusively reserved for you.

When a virtual is HIBERNATED, the current state of the VM is saved, resulting in cost savings for the temporarily unused resources. During the HIBERNATED, billing stops for all resources except for the public IP address and storage. When you RESTORE your virtual machine, you will regain access with the same resource configuration, and billing resumes for these resources.

You won't incur charges for transition states like HIBERNATING or RESTORING, and there are no charges for a VM in the ERROR state resulting from failed operations.

Click here for instructions on how to change the state of your virtual machines.

In Hyperstack, you can change the state of your virtual machines using these steps:

1. Go to the details page of the VM you want to modify as illustrated below, and hover your cursor over the "More Options V" dropdown in the top right corner of the window to see the VM state-changing actions available for execution on the virtual machine.

2. Select the VM state-changing action based on your needs.

• Stop - Transitions your virtual machine into a SHUTOFF state.
• Hard Reboot - Restarts the virtual machine's operating system and all its running programs.
• Hibernate this VM - Transitions your virtual machine into a HIBERNATED state.
• Delete - Permanently deletes a virtual machine.

note

The transition of your virtual machine to the new state might take some time.

Changing VM state using the Infrahub API:

The Infrahub API can be used to HIBERNATE or DELETE your virtual machine, refer to the instructions available here.

info

To avoid data loss, before modifying your virtual machines (hibernate, resize, or delete), back up the data from the temporary storage of the current session, known as the ephemeral disk, to one or more Shared Storage Volumes (SSVs). See the instructions below:

How to save your workload data to an SSV

VM data can be stored by utilizing Shared Storage volumes (SSVs).

1. Create a volume either through Hyperstack, or by using the Infrahub API's "Create volume" endpoint.

2. Attach and mount the volume to your virtual machine, achieved either through Hyperstack or by using the "Attach volumes to virtual machine" Infrahub API endpoint.

3. Once the volume is attached to your virtual machine, you can proceed to move or copy the data from the ephemeral disk to the shared storage volume, saving your data.

4. With the data now saved on the volume, you can modify the state of the virtual machine without the risk of data loss.

References:

• Infrahub Docs | States and Billing Status of Virtual Machines

Q: Why am I being charged for a VM in SHUTOFF state?

A: Click here to learn why billing continues for SHUTOFF VMs and how to avoid it.

When you stop a virtual machine to transition it into a SHUTOFF state, billing continues as the resources it utilizes remain exclusively reserved for you.

To stop billing costs, make sure the virtual machine is either HIBERNATED or deleted.

You won't incur charges for transition states like HIBERNATING or RESTORING, and there are no charges for a VM in the ERROR state resulting from failed operations.

Q: How to change the state of your virtual machines within Hyperstack:

In Hyperstack, you can change the state of your virtual machines using these steps:

1. Go to the details page of the VM you want to modify as illustrated below, and hover your cursor over the "More Options V" dropdown in the top right corner of the window to see the VM state-changing actions available for execution on the virtual machine.

2. Select the VM state-changing action based on your needs.

• Stop - Transitions your virtual machine into a SHUTOFF state.
• Hard Reboot - Restarts the operating system and all its running programs.
• Hibernate this VM - Transitions your virtual machine into a HIBERNATED state.
• Delete - Permanently deletes a virtual machine.

note

The transition of your virtual machine to the new state might take some time.

Changing VM state using the Infrahub API:

The Infrahub API can be used to HIBERNATE or DELETE your virtual machine, refer to the instructions available here.

info

To avoid data loss, before modifying your virtual machines (hibernate, resize, or delete), back up the data from the temporary storage of the current session, known as the ephemeral disk, to one or more Shared Storage Volumes (SSVs). See the instructions below:

How to save your workload data to an SSV

VM data can be stored by utilizing Shared Storage volumes (SSVs).

1. Create a volume either through Hyperstack, or by using the Infrahub API's "Create volume" endpoint.

2. Attach and mount the volume to your virtual machine, achieved either through Hyperstack or by using the "Attach volumes to virtual machine" Infrahub API endpoint.

3. Once the volume is attached to your virtual machine, you can proceed to move or copy the data from the ephemeral disk to the shared storage volume, saving your data.

4. With the data now saved on the volume, you can modify the state of the virtual machine without the risk of data loss.

References:

• Infrahub Docs | States and Billing Status of Virtual Machines
• Infrahub Docs | Manage your virtual machines
• Hyperstack | My Virtual Machines

Q: I shutdown a virtual machine manually, but the current state is not accurately reflected in Hyperstack.

A: Click here to learn why this unintended behavior occurs and how to resolve it.

The use of the VM "Shutdown now" option is currently resulting in this unintended behavior. The VM was expected to shut down and update the Dashboard with its new status, but this communication did not occur. Consequently, it became stuck in the "stopping" state even though it was already shut off. To resolve this, we manually update the status on your dashboard to accurately reflect the current state.

Please reach out to support for assistance at [email protected].

We are actively working towards a resolution for this issue.

References:

• Infrahub Docs | Statuses of Virtual Machines

Q: My virtual machine is ACTIVE but not reachable.

A: Click here to learn why this issue occurs and explore possible solutions.

If, after successfully deploying a virtual machine, it displays the ACTIVE status, but attempts to connect indicate it's unreachable, the VM may still be booting. Especially if it's a VM with a large, high-performance flavor like the 8xH100, the booting process might take several minutes after it shows an ACTIVE status. Please verify the accurate status of the VM by checking the VM console.

To troubleshoot potential issues with SSH connection, click here.

References:

• Infrahub Docs | Statuses of Virtual Machines
• Infrahub Docs | Secure Shell (SSH) Access

Drivers and GPUs

Q: What are the Nvidia and CUDA driver requirements for my virtual machine?

A: Click here to learn about the OS, CUDA version, and Nvidia driver compatibility for the GPUs offered by Hyperstack.

The following table outlines the operating system, CUDA version, and Nvidia driver compatibility for the GPUs offered by Hyperstack. The requirements vary based on the GPU of your virtual machine.

GPU	Operating system	CUDA version	Nvidia drivers
H100	Ubuntu: 20.04/22.04 Windows: 10/11 Pro, Server 2019/2020	12.x or later	Linux: R535 or later Windows: R535 or later
A100	Ubuntu: 20.04/22.04 Windows: 10/11 Pro, Server 2019/2020	11.x or later	Linux: R535 or later Windows: R535 or later
RTX (A-4000, A-5000, A-6000, 6000-ada)	Ubuntu: 20.04/22.04 Windows: 10/11 Pro, Server 2019/2020	11.x or later	Linux: R535 or later Windows: R535 U8 or later
L40	Ubuntu: 20.04/22.04 Windows: 10/11 Pro, Server 2019/2020	11.x or later	Linux: R525 or later Windows: R525 or later

note

For Linux-based virtual machines, Ubuntu versions 20.04 or 22.04 must be used with the H100 GPU.

References:

• Infrahub Docs | GPU Compatibility: Operating Systems, Drivers, and CUDA

Q: nvidia-smi is returning "NVML: Driver/library version mismatch".

A: Click here to learn how to resolve this driver issue.

Symptoms:

Failed to initialize NVML: driver/library version mismatch

nvidia-smi failure

root@instance-1:/var/log/apt# nvidia-smi` `Failed to initialize NVML: Driver/library version mismatch
NVML library version: 535.113

• This is caused by a version mismatch between the NVIDIA GPU driver and the NVML library.

NVRM: API mismatch

/var/log/sysloglog shows NVRM error

NVRM: API mismatch: the client has the version 535.113.01, but
this kernel module has the version 535.104.12.

• API mismatch between the NVIDIA GPU driver and the client.

Cause of issue:

This mismatch is caused by automatic updates installed on a new driver version.

Diagnostic Commands

grep NVRM /var/log/syslog
dpkg -l |egrep "cuda|nvidia" -i
dkms status

• These commands gather information about the NVIDIA drivers, kernel modules, and related packages on the system, helpful for troubleshooting.

Solution:

1. We suggest turning off automatically installed updates. To do this on Ubuntu machines, execute sudo dpkg-reconfigure unattended-upgrades and choose "no" when prompted.

2. Execute the following commands to re-install Nvidia-driver, and libraries, and reboot the instance.

   sudo apt purge nvidia* libnvidia*
   
   # Update the version number 535 to the correct version, usually the driver version reported in the logs.
   sudo apt install nvidia-driver-535
   
   reboot now

3. the nvidia-smi command again, it should now work.

4. If you receive this error:

   NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running

   Execute the following commands to re-install CUDA libraries and reboot again.

   sudo apt-get update
   sudo apt-get -y install cuda
   reboot now

The driver should function without problems after boot; verify this with the nvidia-smi command.

Q: How do I monitor GPU utilization for my virtual machine?

A: Click here to learn how to use the nvidia-smi command to monitor GPU utilization.

To monitor GPU usage for your virtual machine while your workflows are running, execute the nvidia-smi command in the Ubuntu terminal.

References:

• Monitor GPU utilization with nvidia-smi

Q: Why is my GPU not being detected?

A: Click here to learn how to disable MIG mode for proper GPU detection.

If your GPU is not being detected properly and the nvidia-smi command shows MIG M. as Enabled, it means Multi-Instance GPU (MIG) mode is enabled on your NVIDIA GPU. MIG mode partitions the GPU into smaller, isolated instances, which can cause detection issues with software that doesn't support this mode. Disabling MIG mode will revert the GPU to its full, non-partitioned state, allowing for proper detection and usage.

Follow these steps to disable MIG mode:

1. Open a terminal and run the following command to check the current status of your GPUs and identify the GPU ID (usually starting from 0):

nvidia-smi

Example output: The GPU ID is shown on the left, and MIG mode enabled is indicated on the right.

2. Use the following command to disable MIG mode for the undetected GPU, replacing <gpu_id> with the GPU's ID:

sudo nvidia-smi -i <gpu_id> -mig 0

This command uses sudo to grant superuser permissions, nvidia-smi as the NVIDIA System Management Interface command, -i <gpu_id> to specify the GPU ID, and -mig 0 to disable MIG mode.

3. Run the nvidia-smi command again to verify that MIG mode has been disabled:

nvidia-smi

Example output: This output indicates that MIG mode has been disabled.

By following these steps, you will disable MIG mode on your NVIDIA GPU, allowing it to be detected properly.

References:

• Monitor GPU utilization with nvidia-smi

Q: My VM has stuck GPU(s). How can I restore it?

A: Click here to learn how to restore your VM.

When one or more GPUs within a virtual machine become stuck due to hung processes and the VM is improperly rebooted, it can cause the VM to become unresponsive, leading it to enter an ERROR state. To restore a VM with stuck GPU(s) to a functional state, you must first SHUTOFF the VM to release any hung processes. Once in the SHUTOFF state, you can then issue the start command to reboot the operating system and software stack, thereby restoring the VM.

Follow the instructions below to restore a VM with stuck GPU(s) using the Infrahub API:

note

This solution also applies to a VM that is in ERROR state. However, we recommend contacting support in these cases at [email protected].

1. Shutting down the VM

To restore the VM, you'll first need to shut it down to release any hung processes. This can be done by issuing the stop command through the Infrahub API. Simply call the GET /core/virtual-machines/{virtual_machine_id}/stop endpoint and include the virtual machine's ID in the request path.

A successful stop request will return a message indicating that the VM is scheduled to stop.

Example request

curl -X GET "https://infrahub-api.nexgencloud.com/v1/core/virtual-machines/{virtual_machine_id}/stop" \
  -H "accept: application/json"\
  -H "api_key: YOUR API KEY" 

Response

{
    "status": true,
    "message": "VM example-vm is scheduled to stop."
}

The Hyperstack UI will display the SHUTOFF status when the virtual machine has shut down successfully.

2. Starting the VM

After the virtual machine has been successfully shut down and is in the SHUTOFF state, you can start it by calling the GET /core/virtual-machines/{virtual_machine_id}/start endpoint and providing the virtual machine's ID in the request path.

A successful start request will return a message indicating that the VM is scheduled to start.

Example request

curl -X GET "https://infrahub-api.nexgencloud.com/v1/core/virtual-machines/{virtual_machine_id}/start" \
  -H "accept: application/json"\
  -H "api_key: YOUR API KEY" 

Response

{
    "status": true,
    "message": "VM example-vm is scheduled to start."
}

The Hyperstack UI will display the ACTIVE status when the virtual machine has started successfully.

The virtual machine is now restored and it is ready for use.

References:

• Infrahub Docs | VM Status and State Management

Network and firewalls

Q: How do I create firewall rules for my virtual machine?

A: Click here to see full guide on creating firewall rules in Hyperstack.

To see guides for creating various types of firewalls and firewall rules in Hyperstack, click here.

References:

• Infrahub Docs | Virtual Machine Firewall Rules

Q: How can I configure my virtual machine to permit unrestricted incoming and outgoing traffic?

A: Click here to learn how to create a firewall to permit unrestricted traffic.

To enable all incoming and outgoing traffic for your virtual machine, configure firewall rules to permit inbound and outbound traffic on all ports and IP addresses.

Firewall rules for your virtual machines can be created using two different methods: the Hyperstack platform and Infrahub API.

Hyperstack - How to create firewall rules to permit unrestricted incoming and outgoing traffic.

These instructions guide you through the process of creating firewall rules that allow all incoming traffic from any port and any IP address to your virtual machine using the Hyperstack platform:

1. Within Hyperstack, click "Edit Rules" in the "Firewall Rules" section of your virtual machine, to manage its firewall rules.

   

2. Click "Add New Inbound Rule" to create a firewall rule for incoming traffic.

   

3. Complete the fields as specified below to enable all incoming traffic on all ports from any IP address.

   

   Field Name	Field Input
   ETHER TYPE	Leave as default (usually IPv4)
   PROTOCOL	Select "icmp" (Internet Control Message Protocol)
   PORT RANGE	This field is left empty, permitting traffic from all ports.
   REMOTE IP PREFIX	Use "0.0.0.0/0" to allow traffic from any source IP address.

4. Click "Add", to create a firewall rule enabling all incoming traffic.

5. Now that you've created a firewall rule allowing all incoming traffic, follow the same steps to establish a rule for outgoing traffic. Click "Add New Outbound Rule" to configure a firewall rule for outgoing traffic.

   

6. Complete the fields as specified below to enable all outgoing traffic on all ports to any IP address.

   

   Field Name	Field Input
   ETHER TYPE	Leave as default (usually IPv4)
   PROTOCOL	Select "icmp" (Internet Control Message Protocol)
   PORT RANGE	This field is left empty, permitting traffic to all ports.
   REMOTE IP PREFIX	Use "0.0.0.0/0" to allow traffic to any IP address.

7. Your inbound and outbound firewall rules should appear as follows:

   

Congratulations! Your virtual machine is now configured to allow all incoming traffic on all ports from any IP address and all outgoing traffic on all ports to any IP address.

Infrahub API - How to create firewall rules to permit unrestricted incoming and outgoing traffic.

These instructions walk you through the process of creating firewall rules that allow all incoming and outgoing traffic from any port and any IP address to your virtual machine using the Infrahub API.

1. Create an inbound rule via the Infrahub API

Path parameters

Include the integer ID of the virtual machine that this firewall rule is being attached to in the path of the request as follows: /core/virtual-machines/{VM ID HERE}/sg-rules

Request body parameters

Complete the request body with the following fields and values.

Field Name	Field Input
direction	"ingress" to designate that the firewall rule is for incoming traffic.
protocol	Select "icmp" (Internet Control Message Protocol).
ethertype	"IPv4".
remote_ip_prefix	Use "0.0.0.0/0" to allow traffic from any source IP address.

Example request

curl -X POST "https://infrahub-api.nexgencloud.com/v1/core/virtual-machines/123/sg-rules" \
-H "accept: application/json"\
-H "content-type: application/json" \
-H "api_key: YOUR API KEY" \
-d '{
  "direction": "ingress",
  "protocol": "icmp",
  "ethertype": "IPv4",
  "remote_ip_prefix": "0.0.0.0/0"
}'

note

To authenticate Infrahub API requests, add an authorization header to your API request that contains an API Key as follows:

  -H "api_key: YOUR API KEY"

Returns

Returns the status of the firewall rule creation operation, along with the configuration details that were specified in the request body.

This response indicates the successful addition of a firewall rule that will permit all incoming traffic (ingress) from all ports, using the ICMP protocol and Ethernet type "IPv4" for the virtual machine with the ID "123".

Response

{
    "status": true,
    "message": "Security Rule created successfully",
    "security_rule": {
        "id": 2296,
        "direction": "ingress",
        "protocol": "icmp",
        "port_range_min": null,
        "port_range_max": null,
        "ethertype": "IPv4",
        "remote_ip_prefix": "0.0.0.0/0",
        "status": "pending",
        "created_at": "2023-11-24T19:59:01"
    }
}

2. Create an outbound rule via the Infrahub API

Path parameters

Include the integer ID of the virtual machine that this firewall rule is being attached to in the path of the request as follows: /core/virtual-machines/{VM ID HERE}/sg-rules

Request body parameters

Complete the request body with the following fields and values.

Field Name	Field Input
direction	"egress" to designate that the firewall rule is for outgoing traffic.
protocol	Select "icmp" (Internet Control Message Protocol).
ethertype	"IPv4".
remote_ip_prefix	Use "0.0.0.0/0" to allow traffic to any IP address.

Example request

curl -X POST "https://infrahub-api.nexgencloud.com/v1/core/virtual-machines/123/sg-rules" \
-H "accept: application/json"\
-H "content-type: application/json" \
-H "api_key: YOUR API KEY" \
-d '{
  "direction": "egress",
  "protocol": "icmp",
  "ethertype": "IPv4",
  "remote_ip_prefix": "0.0.0.0/0"
}'

Returns

Returns the status of the firewall rule creation operation, along with the configuration details that were specified in the request body.

This response indicates the successful addition of a firewall rule that will permit all outgoing traffic (egress) to all ports, using the ICMP protocol and Ethernet type "IPv4" for the virtual machine with the ID "123".

Response

{
    "status": true,
    "message": "Security Rule created successfully",
    "security_rule": {
        "id": 2297,
        "direction": "egress",
        "protocol": "icmp",
        "port_range_min": null,
        "port_range_max": null,
        "ethertype": "IPv4",
        "remote_ip_prefix": "0.0.0.0/0",
        "status": "pending",
        "created_at": "2023-11-24T20:33:46"
    }
}

Congratulations! Your virtual machine is now configured to allow all incoming traffic on all ports from any IP address and all outgoing traffic on all ports to any IP address.

note

Keep in mind that allowing all traffic might pose firewall risks, so use this configuration carefully and consider the specific requirements of your use case.

References:

• Infrahub Docs | Virtual Machine Firewall Rules

Q: What is the maximum number of packets allowed for communication between VMs?

A: The packet limit for communication between VMs is 800,000 packets. Click here to learn more.

The packet limit for inter-VM communication within virtualized environments is 800,000 packets. Exceeding this threshold will result in the affected VM automatically shutting down. This limit is important for maintaining optimized network performance, security, and resource allocation in virtualized environments.

Data centers

Q: What certifications do NexGen Cloud data centers hold?

A: Our data centers are certified Tier 3 and have SOC Type II certification. Click here to learn more.

NexGen Cloud prioritizes the firewall and dependability of its infrastructure by housing data in data centers certified as Tier 3. These centers adhere to stringent guidelines for power redundancy, cooling, and system backups. Our data centers are concurrently maintainable, allowing for maintenance without service interruptions and maintaining an uptime of 99.982% annually.

Additionally, our data centers undergo independent audits and hold SOC 2 Type II certification. This certification validates the implementation of robust controls for firewall, availability, processing integrity, confidentiality, and privacy of data.

References:

• SOC 2® - SOC for Service Organizations: Trust Services Criteria
• Data Center Tier Classification

Storage and volumes

Q: How can I transfer data between virtual machines?

A: There are multiple possible solutions, including the use of volumes and data transfer software. Click here to learn more.

note

In the potential solutions listed below, make sure that the VM you plan to transfer data to is located in the same environment as the VM you are transferring data from. This is important because data transfer is restricted to virtual machines within the same environment.

It's important to note that a volume can only be attached to a single virtual machine at a time due to the lack of support for parallel access to a single disk by most operating systems and file systems.

Possible solutions:

Volume attachment

VM data can be stored and transferred by utilizing one or more Shared Storage volumes (SSVs).

1. Create a volume either through Hyperstack, or by using the Infrahub API's "Create volume" endpoint.

2. Attach and mount the volume to your virtual machine, achieved either through Hyperstack or by using the "Attach volumes to virtual machine" Infrahub API endpoint.

3. Once the volume is attached to your virtual machine, you can proceed to move or copy the data from the ephemeral disk to the SSV, saving your data.

4. After the volume has successfully stored the data from the ephemeral disk, you can detach it from the virtual machine.

5. Finally, you can now attach this volume to any new VM within the same environment for data transfer.

Bootable volumes

In cases where you wish to maintain the same operating system on the VM you are transferring data to, we recommend creating a bootable volume which is an SSV with an operating system image installed.

Data transfer tools

Create the new virtual machine that you wish to transfer files to in the same environment as your existing VM, and transfer your data through Secure Shell - Secure Copy Protocol (SSH-SCP), Rsync, Network File System (NFS) or any other similar tool.

References:

• Infrahub Docs | Storage Types
• Infrahub Docs | Environments
• Infrahub Docs | Volumes
• Infrahub Docs | Bootable volumes

Q: How can I change the specifications of my virtual machine without losing its data/configurations?

A: Click here to learn how to use bootable volumes to save your data.

Solutions:
If the virtual machine you want to modify was created from a bootable volume:

• The VM created from a bootable volume can be deleted without losing its data since the data is stored on the volume. Subsequently, you can create a new virtual machine from the existing bootable volume by specifying the volume's name in the volume_name field during VM creation or the Hyperstack UI. This allows the new VM to access the saved data on the volume and use its operating system, offering a way to change the VM's specifications without losing its data. Note that a bootable volume can only be attached to a single virtual machine at a time due to the limited support for parallel access to a single disk by most operating systems and file systems.

If the virtual machine was NOT created from a bootable volume:

1. Create a new bootable volume. See instructions on how to create a new bootable volume.

2. The new bootable volume must be attached to the virtual machine containing the custom data you wish to save. See volume attachment details.

3. Once the bootable volume is attached, the VM can be deleted as the data is stored on the volume.

4. Create a new VM with your desired specifications (flavor) from the bootable volume that contains the saved custom data.

References:

• Infrahub Docs | Bootable volumes
• Infrahub Docs | Volume
• Infrahub Docs | Flavors

Q: Can I attach a single volume to multiple virtual machines?

A: A volume can only be attached to one virtual machine at a time. Click here to learn more and explore solutions.

A volume can only be attached to a single virtual machine at a time due to the lack of support for parallel access to a single disk by most operating systems and file systems.

However, NFS sharing can be used to share a single volume between multiple virtual machines.

Follow these steps:

1. Create a bootable volume with sufficient storage capacity for all your data.

2. Create a CPU-only virtual machine configuration from the volume in step 1 to serve as an NFS server.

3. Use a cloud-init script to install packages and enable NFS sharing.

Click here to see an example NFS server cloud-init script.

Note: "/data/nfshare" and "*(rw,no_root_squash)" should be edited according to the required behavior.

NFS server script

#cloud-config

packages:
- nfs-kernel-server
package_update: true

runcmd:
- mkdir -p /data/nfshare
- echo "/data/nfshare    *(rw,no_root_squash)" >> /etc/exports
- exportfs -ravs

Click here to see an example NFS client cloud-init script.

Note: "10.0.0.128:/data/nfshare" and "/mnt" must be changed according to the required behavior.

NFS client script

#cloud-config

packages:
    - nfs-common
package_update: true

mounts:
    - [ "10.0.0.128:/data/nfshare", "/mnt", "nfs", "defaults", "0","0" ]

runcmd:
    - mount /mnt  

4. Create a firewall rule to permit traffic to port 2049/TCP on your local subnet (eg: 10.1.1.0/24).

5. Create one or more VMs with your desired configurations and attach the cloud-init NFS clients example script.

6. Optionally, the client configurations can be saved as a Provisioning Profile for future usage.

References:

• Infrahub Docs | Storage Types
• Infrahub Docs | Provisioning Profiles
• Infrahub Docs | Volume Attachment
• Configure NFS Server on Ubuntu - Debian
• Configure NFS Client on Ubuntu - Linux
• Cloud config script examples

Q: How can I save my virtual machines, similar to the process of creating an AWS machine image?

A: Currently, Hyperstack doesn't support volume snapshots or backup features. Click here to explore solutions.

Currently, Hyperstack doesn't support volume snapshots or backup features.

Solutions:

• Currently, a possible solution could be to employ a cloud-init script and save a Provisioning Profile (The last option on the VM creation page in Hyperstack) for future VM creations.
• Shared Storage volumes are available for persistent data storage; however, please note that these volumes can only be attached to a single VM at any given time.

References:

• Infrahub Docs | Storage Types
• Infrahub Docs | Provisioning Profiles
• Cloud config script examples

Q: What is a bootable volume?

A: A volume with an installed OS image can be used for provisioning VMs. Click here to learn more.

A bootable volume is a Shared Storage Volume (SSV) with an operating system image pre-installed. If a virtual machine is created from a bootable volume, it can access the data saved on the volume and use its operating system. It's important to note that a bootable volume can only be attached to a single virtual machine at a time due to the lack of support for parallel access to a single disk by most operating systems and file systems.

To learn more about bootable volumes and see guides on creating them, click here.

References:

• Infrahub Docs | Volumes
• Infrahub Docs | Bootable volumes
• Infrahub Docs | Operating System Images

Glossary

Q: What is the relationship between Hyperstack and Infrahub API?

A: Hyperstack is the user-friendly interface of the Infrahub API. Click here to learn more.

The Hyperstack platform operates on the Infrahub API. Its core functionalities are carried out through the Infrahub API, with Hyperstack serving as a user-friendly interface to interact with the powerful capabilities of the API.

Q: What are regions and environments, and how do they relate to each other?

A: Click here to learn about the relationship between regions and environments.

A region represents a distinct geographic location housing a data center. Regions provide the flexibility to host your resources in various global locations. Each region is intentionally isolated from others, enhancing redundancy and stability.

• Learn more about regions.

Environments are predefined user spaces that are created within a region, offering a logical way to organize your resources. All your resources, including SSH key pairs, virtual machines, volumes, etc., are created within a designated environment.

• Learn more about environments.

References:

• Infrahub Docs | Regions
• Infrahub Docs | Environments

Q: What is an organization?

A: The Hyperstack organization feature enables you to organize your team members and their access to resources.

The organization feature is designed to efficiently organize your team members and their access to resources. When you sign up for a Hyperstack account, you automatically become the owner of an organization in your name. Ownership allows you to invite other team members to join your organization. You can then grant permissions to other organization members, allowing them to create and manage resources within your organization. You can manage resource access for team members using the Role-Based Access Control (RBAC) system which allows you to grant specific access permissions for each resource.

• Learn more about organizations.

References:

• Infrahub Docs | Organizations
• Infrahub Docs | Role-Based Access Control

Q: What is a flavor?

A: Flavors are hardawre configurations for your virtual machines, including GPUs, CPUs, RAM, and disk.

A flavor includes the GPU model, CPUs, RAM, and system disk. Flavors provide a convenient method to choose virtual machine specifications for your specific workloads. The hourly price of a virtual machine varies depending on the specifications of the selected flavor.

Here is an example of a flavor you can choose during virtual machine creation within Hyperstack:

Resource type	Units
RTX-A6000 graphics card	1
CPU cores	16
RAM	59.5 GB
Disk space	425 GB

In development

In the near future, we will introduce the capability to create custom flavors tailored to the specific requirements of your workloads. Additionally, you will be able to modify the flavor of your existing virtual machines through a process known as resizing.

• Learn more about flavors.

References:

• Infrahub Docs | Flavors

Q: What is a firewall?

A: A firewall acts as a filter for network traffic to and from resources in a virtual network.

Firewalls allow you to specify which ports are open to the public for both incoming and outgoing traffic, and define the permitted IP addresses, enabling you to secure your resources.

• Click here to learn more about firewall rules.

References:

• Infrahub Docs | Firewall Rules

Back to top