FAQ
Frequently Asked Questions about Hyperstack.
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
- Infrahub API
To enable SSH access to your virtual machine in Hyperstack:
-
Within Hyperstack, navigate to the Virtual Machines page.
-
Click on the virtual machine for which you intend to enable SSH access.
-
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
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.
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
}'
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.
-
In Hyperstack, go to the "Virtual Machines" tab and click on the virtual machines "NAME" you want to access, to view its details.
-
Within the VM's details, click "Open VNC Console".
-
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. -
Select "
Advanced options
" > "Recovery mode
" from the grub menu. -
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). -
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. -
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
- YAML
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
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:
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 asssh -G -i .ssh/id_rsa ubuntu@<public-ip>
. This command prints the client's configuration. Verify that the configuration appears correct, particularly checking theuser
,hostname
, andidentityfile
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>
. Eachv
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 statingIdentitiesOnly 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:
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:
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:
-
Create a new API key or copy your existing API key. For additional information on accessing your API key, click here.
-
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.
-
Execute the following command in a terminal, replacing
<VM-ID>
with the virtual machine ID and<API-KEY>
with your API key.
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"
}'
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:
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:
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.
curl -X GET "https://infrahub-api.nexgencloud.com/v1/core/virtual-machines" \
-H "accept: application/json"\
-H "api_key: YOUR API KEY"
{
"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:
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:
-
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.
-
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.
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.
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).
-
Create a volume either through Hyperstack, or by using the Infrahub API's "Create volume" endpoint.
-
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.
-
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.
-
With the data now saved on the volume, you can modify the state of the virtual machine without the risk of data loss.
References:
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:
-
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.
-
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.
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.
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).
-
Create a volume either through Hyperstack, or by using the Infrahub API's "Create volume" endpoint.
-
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.
-
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.
-
With the data now saved on the volume, you can modify the state of the virtual machine without the risk of data loss.
References:
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:
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:
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 |
For Linux-based virtual machines, Ubuntu versions 20.04 or 22.04 must be used with the H100 GPU.
References:
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
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
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:
-
We suggest turning off automatically installed updates. To do this on Ubuntu machines, execute
sudo dpkg-reconfigure unattended-upgrades
and choose "no" when prompted. -
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 -
the
nvidia-smi
command again, it should now work. -
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:
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:
- 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.
- 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.
- 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:
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:
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.
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"
{
"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.
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"
{
"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:
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:
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:
-
Within Hyperstack, click "Edit Rules" in the "Firewall Rules" section of your virtual machine, to manage its firewall rules.
-
Click "Add New Inbound Rule" to create a firewall rule for incoming traffic.
-
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. -
Click "Add", to create a firewall rule enabling all incoming traffic.
-
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.
-
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. -
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. |
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"
}'
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".
{
"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. |
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".
{
"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.
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:
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:
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.
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).
-
Create a volume either through Hyperstack, or by using the Infrahub API's "Create volume" endpoint.
-
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.
-
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.
-
After the volume has successfully stored the data from the ephemeral disk, you can detach it from the virtual machine.
-
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:
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:
-
Create a new bootable volume. See instructions on how to create a new bootable volume.
-
The new bootable volume must be attached to the virtual machine containing the custom data you wish to save. See volume attachment details.
-
Once the bootable volume is attached, the VM can be deleted as the data is stored on the volume.
-
Create a new VM with your desired specifications (flavor) from the bootable volume that contains the saved custom data.
References:
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:
-
Create a bootable volume with sufficient storage capacity for all your data.
-
Create a CPU-only virtual machine configuration from the volume in step 1 to serve as an NFS server.
-
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.
#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.
#cloud-config
packages:
- nfs-common
package_update: true
mounts:
- [ "10.0.0.128:/data/nfshare", "/mnt", "nfs", "defaults", "0","0" ]
runcmd:
- mount /mnt
-
Create a firewall rule to permit traffic to port 2049/TCP on your local subnet (eg: 10.1.1.0/24).
-
Create one or more VMs with your desired configurations and attach the cloud-init NFS clients example script.
-
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:
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:
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.
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.
References:
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.
References:
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 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.
References:
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.
References: