Luna Node - User contributions [en]

Burstable Resources

2023-12-27T16:45:28Z

Favyen Bastani: /* Burst Points System */

In order to maximize affordability and flexibility, Luna Node General-Purpose and Memory-Optimized virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

Compute-Optimized virtual machines are assigned dedicated CPU cores.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 100% CPU utilization for every 1.0 CPU-Points specified in the plan (for example, s.half includes 0.2 CPU-Points, and a baseline performance of 20% CPU utilization)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to their baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account in the same region with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs in the same region with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of the two available cores over 30 days on a s.1 VM, which has 0.4 plan cpu-points. Your VM will need an additional 0.6 burst points for every five-minute interval in the month, on top of the 0.4 baseline performance included in the plan. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Server monitoring

2023-01-08T21:01:27Z

Favyen Bastani:

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 164.90.140.121 / 2604:a880:800:10::a73:1 (New York)
* 161.35.81.251 / 2a03:b0c0:2:d0::ed8:f001 (Amsterdam)
* 24.199.97.144 / 2604:a880:4:1d0::73e:6000 (San Francisco)
* 46.101.19.128 / 2a03:b0c0:1:d0::1091:d001 (London)

Application Templates

2022-04-22T17:37:39Z

Favyen Bastani:

Application templates allow you to quickly spin up a ubuntu virtual machine with preinstalled software.

We have templates for:

* LAMP stack - Apache, MySQL, PHP
* LEMP stack - nginx, MySQL, PHP
* [https://gitlab.com/ GitLab] - web management of git repositories
* [https://owncloud.org/ OwnCloud] - file synchronization and sharing platform
* [https://wordpress.com/ WordPress] - blog software
* [http://dokku.viewdocs.io/dokku/ Dokku] - single-server git-push-to-deploy PaaS

All templates use Ubuntu 20.04 64-bit.

After the VM is provisioned, you will receive an e-mail with details on how to proceed. In general, any login information will be written to /home/ubuntu/application.txt.

== LAMP and LEMP ==

These templates come with basic webserver and database installed. For PHP, mod_php is used for Apache and php5-fpm for nginx.

The web root directory and MySQL root password can be found in /home/ubuntu/application.txt.

We include a script /opt/ssl.py that will set up your webserver to support SSL, and to automatically obtain and renew SSL certificates via Let's Encrypt. To use it, pass the domains that will be served to the script, e.g. <tt>/opt/ssl.py example.com www.example.com</tt>.

== GitLab ==

GitLab is a git repository management tool that includes features such as pull requests, issue tracking, and wikis.

After the VM is provisioned, go to http://[VM external IP]/ and enter a password. You will then be prompted to login; the username is "root", and the password is what you just entered.

== OwnCloud ==

After the VM is provisioned, go to http://[VM external IP]/ and enter the initial account information.

The MySQL login details for both the root database user and the OwnCloud database can be found in /home/ubuntu/application.txt. OwnCloud will be configured to automatically detect the MySQL database, so you do not ordinarily need to use this.

We include a script /opt/ssl.py that will set up your webserver to support SSL, and to automatically obtain and renew SSL certificates via Let's Encrypt. To use it, pass the domains that will be served to the script, e.g. <tt>/opt/ssl.py example.com www.example.com</tt>.

== WordPress ==

After the VM is provisioned, go to http://[VM external IP]/ and enter the initial account information and other configuration details.

The MySQL login details for both the root database user and the WordPress database can be found in /home/ubuntu/application.txt. WordPress will be configured to automatically detect the MySQL database, so you do not ordinarily need to use this.

We include a script /opt/ssl.py that will set up your webserver to support SSL, and to automatically obtain and renew SSL certificates via Let's Encrypt. To use it, pass the domains that will be served to the script, e.g. <tt>/opt/ssl.py example.com www.example.com</tt>.

== Dokku ==

If you selected an SSH key when provisioning the VM, then Dokku will already be set up with the key. Otherwise, go to http://[VM external IP]/ to configure Dokku.

You can modify the hostname used by Dokku later by editing /home/dokku/HOSTNAME.

Frequently asked questions

2021-02-24T20:20:56Z

Favyen Bastani: /* I cannot login as root! */

=== Cannot connect with SSH to newly booted VM ===

The provisioning and booting process may take as long as five minutes in some cases, depending on the specific operating system you are selecting. You can monitor progress over VNC by hitting the VNC Connection button. Once booted, you will be able to authenticate via SSH using the username and password displayed on the virtual machine page (or SSH key if you specified one).

Note that if you selected an image marked "ISO" when provisioning the VM, you will have to install the operating system via VNC. If you simply want a ready-made VM up and running, you should select an image marked "template" instead.

=== I cannot ping my IP address 172.20.8.187 ===

The IP address starting with 172 is the private IP address for your VM. Go to your VM details page and look for the "external IP address".

=== Do you support IPv6? ===

Yes! We support IPv6 in Toronto. Virtual machines are automatically assigned an IPv6 address via SLAAC. User-created virtual networks receive a /64 IPv6 allocation, and virtual machines created on such networks can use any address on the allocated subnet.

=== How to resize my VM? ===

To resize your VM, select the VM and use the Resize utility.

Note that the resize will fail if you attempt to resize a local-storage-backed instance to a plan with a smaller disk size. Follow these steps to resize a VM down:

* Take a snapshot of the VM
* Once the snapshot is ready (you can monitor the progress from the Images tab), go to the Volumes tab and create a volume from the snapshot with the old snapshot size
* Boot a new VM with "Ubuntu 14.04 64-bit" template, and attach the volume to the VM
* Assuming that the volume is attached at /dev/vdc, run <tt>resize2fs /dev/vdc1 10G</tt> (replacing 10G with desired size in gigabytes; aim for as small a size as possible, so that the partition and disk will fit)
* Then, run fdisk /dev/vdc and re-create the partition; make sure the start sector is the same, and also make sure to set the bootable flag:

<nowiki># fdisk /dev/vdc

Command (m for help): p

Disk /dev/vdc: 37.6 GB, 37580963840 bytes
4 heads, 32 sectors/track, 573440 cylinders, total 73400320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d8e94

Device Boot Start End Blocks Id System
/dev/vdc1 * 2048 73400319 36699136 83 Linux

Command (m for help): d 1
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-73400319, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-73400319, default 73400319): 33556479

Command (m for help): a
Partition number (1-4): 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.</nowiki>

Above, to calculate the last sector, you can try multiplying the default last sector by the fraction that you're resizing down; e.g. if resizing from 35 GB to 15 GB, multiply (73400319 / 35 * 14) (we use 14 instead of just 15 since the partition table and other elements take up some space; do make sure that the filesystem has been resized to less than this many GB in the <tt>resize2fs</tt> command earlier).

* Create a new volume with the desired size, and attach it to the same VM
* Use <tt>fdisk /dev/vdd</tt> to create identical partitions on the new volume
* Use <tt>dd if=/dev/vdc1 of=/dev/vdd1 bs=64k</tt> to copy data from the partition on the old volume to the partition on the new volume
* Detach both volumes from the VM, and delete the volume with old size
* Select the volume with new size from the Volumes tab, and convert it to an image
* Boot the new VM from the image

=== Unable to attach volume to my Windows VM ===

Volumes are best used with Linux virtual machines using the virtio driver. If you are using another operating system or ide driver, then you likely will need to shut down the VM before attaching or detaching volumes. You may also need to specify the attachment target as /dev/hdc or /dev/hdd or etc.

=== What is the default username for virtual machines provisioned using the stock templates ===
The administrative username for template-based virtual machines are as the following:
*Ubuntu: ubuntu
*Debian: debian
*CentOS: cloud-user / centos
*Fedora: fedora
*CoreOS: core

=== I cannot login as root! ===

Virtual machines are configured by default to accept logins over SSH as an administrative user (e.g. "ubuntu" or "centos").

Once authenticated as the administrative user, you can execute <tt>sudo su -</tt> to login as root.

If you wish, you can configure your VM so that you can directly login over SSH as root. To do so:

# Login as the administrative user, then run <tt>sudo su -</tt> to login as root
# Set a root user password: run <tt>passwd</tt>
# <tt>sed -i 's/.*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config</tt>
# <tt>service ssh restart; service sshd restart</tt>

Then logout and you should be able to authenicate via SSH directly as the root user with your newly set password.

Alternatively, you can use a [[Startup scripts|startup script]] so that the root password is set when the VM boots.

Note: use an SSH client like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] to authenticate.

Please note that our services are unmanaged and you are responsible or the security of your VM; if your VM is taken over and used in denial of service attacks, spam, or other activities that violate our [https://dynamic.lunanode.com/terms terms of service], your account may be suspended depending on the circumstances.

=== Is additional bandwidth usage billed hourly? ===

Bandwidth is billed as a '''consumable resource''', i.e., you are charged for the amount that you use; it is not per-hour or per-month since there is no timespan. Bandwidth allocations from VM plans are allocated on a per-calendar-month basis. So, if you have an s.half VM and use 1500 GB bandwidth in a month (500 GB over the plan allocation), then you will be billed $0.003 for each additional GB ($1.50 total), and it does not matter how many hours it took you to use that 500 GB.

=== My disk space is smaller than the plan disk ===

Almost all of the templates will automatically resize the partition and filesystem the first time that the virtual machine boots. If you install from ISO, you can also choose the partitioning scheme.

So, if you are having this problem where filesystem doesn't actually get resized, it likely means you are using the CentOS 6 template, which does not support automatic filesystem resizing. You can instead run the following commands to manually resize the partition/filesystem:

<nowiki>
fdisk /dev/vda
> u
(this will switch units to sector; it is important that you use sectors and not cylinders!)
> p
(this will print all of the partitions, we will refer to the data later)
> d 1
(this will display "Selected partition 1" and delete the first partition)
> n
(select "p" for primary partition)
(partition number should be 1, but make sure it matches the number displayed in print command)
(first sector should be 2048, but make sure it matches the "Start" column displayed in print command)
(and set last sector to the default value)
> a
(type "1" to make new first partition bootable)
> w
(this will write the new partitions and exit fdisk)
shutdown -r 0
(connect to VM after it reboots, if it has resized partition but not filesystem then run resize2fs)
</nowiki>

Warning: when creating the new partition, make sure that the first sector matches the sector displayed in print command (typically 2048). The default option that fdisk will provide is incorrect.

=== The VNC connection doesn't work for me ===

This is usually caused by a firewall on your computer, router, or at your ISP; or because of outdated browser software. If you are using the noVNC client, first try switching to another browser and see if it works there.

If it still doesn't connect (e.g. you get "Connection Timeout" error), then you can try to use the VNC tunnel connection method so that you can use your own desktop VNC client instead of noVNC. To do this, go to the Account tab in the top right, scroll down to VNC Connection Method, and change to tunnel. Then, when you click the VNC button, you will be given VNC login details that you can plug into your desktop VNC client to connect to your virtual machine instance.

Note: you may have to subtract 5900 from the port provided by the tunnel in some cases. So for example, if the panel says to connect to 167.114.159.49:6105, and that doesn't work, then also try connecting to 167.114.159.49:205.

=== Can I shutdown my VMs to avoid being billed? ===

You can use the Shelve functionality to deactivate your virtual machine. Once a VM is shelved, you will only be billed for the storage space, at $0.03/GB/mo, and assigned IP addresses, at $1/mo (both fees are charged hourly); the pricing change will be reflected in the billing section of the panel dashboard. You can reactivate the VM at any time by pressing Unshelve from the VM details.

=== Why is my geo-location database showing the IP address in an incorrect location? ===

We set standard Referral Whois (RWhois) records that indicate the exact location of all IP addresses that we operate. If your geo-location database does not show the correct location for our IP addresses, that means that the database provider is not checking our RWhois records. You would need to direct questions regarding the inaccuracy of their database to them. Please do not contact us with any questions about IP geo-location as we do not maintain these databases.

Burstable Resources

2019-04-11T17:05:48Z

Favyen Bastani: /* Paying for CPU Performance above the Baseline */

In order to maximize affordability and flexibility, Luna Node General-Purpose and Memory-Optimized virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

Compute-Optimized virtual machines are assigned dedicated CPU cores.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 100% CPU utilization for every 1.0 CPU-Points specified in the plan (for example, s.half includes 0.2 CPU-Points, and a baseline performance of 20% CPU utilization)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to their baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of the two available cores over 30 days on a s.1 VM, which has 0.4 plan cpu-points. Your VM will need an additional 0.6 burst points for every five-minute interval in the month, on top of the 0.4 baseline performance included in the plan. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

API

2018-12-17T23:15:53Z

Favyen Bastani:

'''For the latest API documentation, refer to https://www.lunanode.com/api/overview'''

The Luna Node Dynamic API enables you to write software to automate VM management. This page details how the API can be accessed. Visit the [https://dynamic.lunanode.com/panel/api API tab] to manage your API keys.

== Overview ==

Each API token consists of an API ID and an API key. Both are needed for authentication of all API commands.

API actions consist of a category label, action label, and a set of parameters. For example, to start a VM, the category label is "vm", action label is "start", and a "vm_id" parameter must be set. [[API#Action_list|See the full API action list.]]

API requests are made over HTTPS. Once the server completes processing of your request, it will return a JSON-encoded response.

== Usage ==

We provide open source (under MIT License) [https://github.com/LunaNode/lndynamic-api PHP and Python libraries] for accessing the Luna Node Dynamic API. These libraries make interaction with the API easier, handling transaction from category, action, and parameters to the HTTPS request, and from the JSON-encoded response to a PHP associative array or Python dictionary. [https://github.com/LunaNode/lndynamic-api Get the libraries here.]

Third party libraries are also available:

* Golang: a [https://github.com/LunaNode/lobster/tree/master/vmi/lunanode Golang client API] is available as part of the Lobster project.
* C#: [https://github.com/rickparrish/lndapi rickparrish/lndapi] is a C# API wrapper.
* PHP: [https://github.com/sdavis1902/lunanode-api-php sdavis1902/lunanode-api-php]
* Ruby: [https://github.com/nomoon/lunanode nomoon/lunanode] Ruby Gem

If you are using another programming language, you can view the API call [[API#Technical_details|technical details]] below. You may also find it easier to implement the [[API#Legacy_API|Legacy API]].

=== Examples ===

List your virtual machines:

<nowiki><?php

require_once('lndynamic.php');
$api_id = 'YOUR API ID';
$api_key = 'YOUR API KEY';
$api = new LNDynamic($api_id, $api_key);
print_r($api->request('vm', 'list'));

?></nowiki>

<nowiki>from lndynamic import LNDynamic
api_id = 'YOUR API ID'
api_key = 'YOUR API KEY'
api = LNDynamic(api_id, api_key)
print api.request('vm', 'list')</nowiki>

Recreate a VM with the same IP:

<nowiki><?php

require_once('lndynamic.php');
$api_id = 'YOUR API ID';
$api_key = 'YOUR API KEY';
$target_vm_name = 'myvm';
$target_image_name = 'Ubuntu 14.04 64-bit (template)';
$api = new LNDynamic($api_id, $api_key);

// find the target virtual machine ID
$vms = $api->request('vm', 'list');
$target_vm_id = false;

foreach($vms['vms'] as $vm) {
if(strcasecmp($vm['name'], $target_vm_name) === 0) {
$target_vm_id = $vm['vm_id'];
break;
}
}

//find the target image ID
$images = $api->request('image', 'list');
$target_image_id = false;

foreach($images['images'] as $image) {
if(strcasecmp($image['name'], $target_image_name) === 0) {
$target_image_id = $image['image_id'];
break;
}
}

if($target_vm_id === false) {
die('No VM found!');
}

if($target_image_id === false) {
die('No image found!');
}

// disassociate the IP address
$info = $api->request('vm', 'info', array('vm_id' => $target_vm_id));
if(empty($info['info']['ip'])) {
die('VM does not have IP!');
}
$api->request('vm', 'floatingip-delete', array('vm_id' => $target_vm_id, 'keep' => 'yes'));
$api->request('vm', 'delete', array('vm_id' => $target_vm_id));
$api->request('vm', 'create', array('hostname' => $info['info']['hostname'], 'plan_id' => $info['extra']['plan_id'], 'image_id' => $target_image_id, 'ip' => $info['info']['ip']));

?></nowiki>

=== Technical details ===

A request can be made given an API ID, API key, category, action, and parameters. The steps are described below. See the code of [https://github.com/LunaNode/lndynamic-api provided API libraries] for more details.

* Create request array by taking parameters and adding "api_id" => API ID and "api_partialkey" => first 64 characters of API key.
* JSON-encode the request array to get a '''raw request message'''.
* The '''nonce''' is the current UTC time in seconds since epoch (in PHP, <code>$nonce = time();</code>).
* The handler path is "{category}/{action}/"
* The target URL is https://dynamic.lunanode.com/api/{handler_path}
* Calculate the signature as SHA512-HMAC("{handler path}|{raw request message}|{nonce}"), using the API key as the HMAC key; here, we are signing the string formed from concatenating handler path, raw request message, and nonce delimited by pipe (|) characters
* Submit POST request to target URL with these form keys:
** '''req''': the raw request message
** '''signature''': the hex-digest output of the SHA512-HMAC
** '''nonce''': the nonce value
* The server's response will be a JSON-encoded associative array.

=== Legacy API ===

The legacy API uses simple GET and POST requests for each API action. All API actions are submitted via https://dynamic.lunanode.com/api

For example, to get the info for a virtual machine with hostname "hostname.example.tld", you can use the following API actions (find the ID for the hostname, then get the info from the ID):

<nowiki>https://dynamic.lunanode.com/api?api_id=YOUR_API_ID&api_key=YOUR_API_KEY&category=vm&action=list
https://dynamic.lunanode.com/api?api_id=YOUR_API_ID&api_key=YOUR_API_KEY&category=vm&action=info&vm_id=FOUND_VM_ID</nowiki>

The legacy API isn't necessarily less secure than the newer API, as either way all API actions are encrypted under HTTPS; however, the new API does offer greater protection against timing attacks and hides the API key even if an attacker were able to successfully forge an SSL certificate. So, we encourage usage of the new API where it is not inconvenient, but we plan to maintain the legacy API indefinitely.

== Action list ==

This list serves as a reference for available API actions. See [[API Detail]] for additional details for some API operations.

=== Virtual machine ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|vm
|start
|vm_id
|None
|-
|vm
|stop
|vm_id
|None
|-
|vm
|reboot
|vm_id
|None
|-
|vm
|diskswap
|vm_id
|None
|-
|vm
|info
|vm_id
|None
|-
|vm
|delete
|vm_id
|None
|-
|vm
|reimage
|vm_id, image_id
|None
|-
|vm
|resize
|vm_id, plan_id
|None
|-
|vm
|rescue
|vm_id
|None
|-
|vm
|vnc
|vm_id
|None
|-
|vm
|floatingip-add
|vm_id
|ip (string unattached floating IP address on your account), private_ip (string internal IP on VM)
|-
|vm
|floatingip-delete
|vm_id
|ip (string floating IP attached to VM), keep ('yes' to keep floating IP on account; default 'no')
|-
|vm
|iplist
|vm_id
|None
|-
|vm
|ip-add
|vm_id
|ip (string unallocated IP in virtual network)
|-
|vm
|ip-delete
|vm_id, ip
|None
|-
|vm
|securitygroup-add
|vm_id, group_id
|None
|-
|vm
|securitygroup-remove
|vm_id, group_id
|None
|-
|vm
|create
|hostname, plan_id, image_id
|region (default 'toronto'), ip (a floating IP on your account), net_id, securitygroups, scripts, volume_id, volume_virtio, key_id, set_password, affinity_group
|-
|vm
|snapshot
|vm_id, name (e.g. 'mysnapshot')
|None
|-
|vm
|list
|None
|None
|-
|vm
|shelve
|vm_id
|None
|-
|vm
|unshelve
|vm_id
|None
|-
|vm
|rename
|vm_id, hostname
|None
|}

Note: for create command, net_id is a network ID number, securitygroups is a comma-separated list of security group ID numbers, scripts is a comma-separated list of script ID numbers, volume_id is the ID number of an unattached volume that the new VM should be booted from (if volume_id is set, image_id is not required), and affinity_group is an affinity group UUID. Also, if volume_id is set, then the driver is ide if volume_virtio is not set, or virtio of volume_virtio is set (value of volume_virtio is ignored). Finally, key_id is an [https://dynamic.lunanode.com/panel/key SSH keypair ID], and set_password can be set if you want the system to add a startup script to set a randomly generated password (this is ignored if key_id is set; also, the system will set password by default for official templates).

=== DNS ===

API calls relating to DNS are listed below (see next section for Legacy DNS).

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|dns2
|zone-list
|None
|None
|-
|dns2
|zone-add
|name (e.g. 'example.com'), ttl
|None
|-
|dns2
|zone-remove
|zone_id
|None
|-
|dns2
|record-list
|zone_id
|None
|-
|dns2
|record-add
|zone_id, name, data, ttl, type
|policy, weight, region, regiongroup, country, continent, global, latitude, longitude, aux, monitor_id, orig_record_id
|-
|dns2
|record-remove
|zone_id, record_id
|None
|}

Here are details for parameters to the '''record-add''' action:

* '''name''': e.g. 'blah' or 'blah.example.com.' for 'blah.example.com.'
* '''data''': the record contents, e.g. '1.2.3.4' for an A record or 'other.example.org.' for a CNAME/MX record
* '''ttl''': time-to-live, e.g. 3600
* '''type''': one of 'A', 'AAAA', 'CNAME', 'ALIAS', 'MX', 'NS', 'TXT', 'SPF', 'SRV'
* '''policy (optional)''': geo-targeting policy, 'none' for no geo-targeting, 'latlong' to route to record with closest latitude/longitude to the user's location, and 'region' for hierarchical region-based routing
* '''weight (optional)''': the record weight (this is used for load balancing or non-round-robin DNS failover)
* '''region, regiongroup, country, continent, global (optional)''': parameters for hierarchical region-based routing, see the UI for details (set global to 'no' to disable for global group)
* '''latitude, longitude (optional)''': latitude/longitude for 'latlong' policy
* '''aux (optional)''': priority for certain record types, such as MX and SRV
* '''monitor_id (optional)''': the ID of a monitor check (see monitor.check-list action), this record will be disabled if the check fails
* '''orig_record_id (optional)''': update an existing record with the specified ID instead of creating a new record

=== Legacy DNS ===

API calls relating to Legacy DNS are listed below. Valid DNS record types are 'A', 'AAAA', 'CNAME', 'HINFO', 'MX', 'NAPTR', 'NS', 'PTR', 'RP', 'SRV', and 'TXT'.

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|dns
|list
|None
|None
|-
|dns
|set
|ip, hostname
|None
|-
|dns
|zone-list
|None
|None
|-
|dns
|zone-add
|origin (e.g., 'example.tld.')
|ttl
|-
|dns
|zone-remove
|zone_id
|None
|-
|dns
|record-list
|zone_id
|None
|-
|dns
|record-add
|zone_id, name (e.g., 'www'), data (e.g., '1.2.3.4'), ttl, type
|None
|-
|dns
|record-remove
|record_id
|None
|-
|dns
|dyn-list
|None
|None
|-
|dns
|dyn-add
|name, ip
|None
|-
|dns
|dyn-update
|dyn_id, name, ip
|None
|-
|dns
|dyn-remove
|dyn_id
|None
|}

=== Image ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|image
|list
|None
|region (will show images across all regions by default)
|-
|image
|delete
|image_id
|None
|-
|image
|details
|image_id
|None
|-
|image
|replicate
|image_id, region
|None
|-
|image
|fetch
|region, name, location, format ('iso' or 'qcow2')
|virtio
|-
|image
|retrieve
|image_id
|None
|-
|image
|rename
|image_id, name
|None
|}

image.fetch fetches an image from an external source. image.retrieve sends the contents of an existing image as the response body.

=== Volume ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|volume
|list
|region
|None
|-
|volume
|create
|region, label (e.g. 'myvolume'), size (in GB)
|image, snapshot_id
|-
|volume
|delete
|region, volume_id
|None
|-
|volume
|attach
|region, volume_id, vm_id, target (e.g. 'auto' or '/dev/vdc')
|None
|-
|volume
|detach
|region, volume_id
|None
|-
|volume
|info
|region, volume_id
|None
|-
|volume
|extend
|region, volume_id, size (in GB)
|None
|-
|volume
|snapshot-create
|region, volume_id, label
|None
|-
|volume
|snapshot-delete
|region, snapshot_id
|None
|-
|volume
|snapshot-list
|region
|None
|-
|volume
|snapshot-replicate
|region, snapshot_id, image_name (e.g. 'myimage'), dst_region (e.g. 'toronto')
|None
|-
|volume
|rename
|volume_id, name
|None
|}

For volume creation, if image parameter (which should be an image ID) and snapshot_id parameter are not set, then an empty volume will be created. If both are set, an error will be returned.

=== Floating IP ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|floating
|list
|None
|None
|-
|floating
|add
|region
|None
|-
|floating
|delete
|region, ip
|None
|}

=== Virtual Network ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|network
|list
|None
|region
|-
|network
|create
|region, name, subnet (e.g. '192.168.30' for 192.168.30.0/24), dns (e.g. '8.8.8.8,8.8.4.4')
|None
|-
|network
|delete
|region, net_id
|None
|}

=== Load Balancer ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|lb
|list
|region
|net_id
|-
|lb
|create
|region, net_id, name, method ('ROUND_ROBIN', 'LEAST_CONNECTIONS', or 'SOURCE_IP'), protocol ('HTTP', 'HTTPS', or 'TCP'), connection_limit (-1 for unlimited), port
|None
|-
|lb
|delete
|region, lb_id
|None
|-
|lb
|info
|region, lb_id
|None
|-
|lb
|member_add
|region, lb_id, ip, port
|None
|-
|lb
|member_remove
|region, lb_id, member_id (see lb/info output)
|None
|-
|lb
|associate
|region, lb_id, ip
|None
|}

=== Plan and region ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|plan
|list
|None
|None
|-
|region
|list
|None
|None
|}

=== Server monitoring ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|monitor
|check-list
|None
|None
|-
|monitor
|check-types
|None
|None
|-
|monitor
|check-add
|name, type, fail_count, success_count, check_interval, (also any parameters needed from check-types)
|None
|-
|monitor
|check-remove
|check_id
|None
|-
|monitor
|contact-list
|None
|None
|-
|monitor
|contact-add
|None
|None
|-
|monitor
|contact-remove
|type ('email', 'sms_twilio', or 'http'), rel (e-mail address, phone number, or URL)
|None
|-
|monitor
|alert-list
|check_id
|None
|-
|monitor
|alert-add
|check_id, contact_id
|None
|-
|monitor
|alert-remove
|alert_id
|None
|}

=== Security groups ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|securitygroup
|list
|None
|None
|-
|securitygroup
|create
|region, name
|None
|-
|securitygroup
|delete
|region, group_id
|None
|-
|securitygroup
|rename
|region, group_id, name
|None
|-
|securitygroup
|rule-list
|region, group_id
|None
|-
|securitygroup
|rule-insert
|region, group_id, direction ('ingress' or 'egress'), type (4 or 6), protocol ('*', 'tcp', 'udp', or 'icmp'), remote_type ('cidr' or 'group'), remote_value (CIDR or group ID)
|port_min, port_max, label
|-
|securitygroup
|rule-delete
|region, group_id, rule_id
|None
|}

=== Startup scripts ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|script
|list
|None
|None
|-
|script
|get
|script_id
|None
|-
|script
|create
|name, content
|None
|-
|script
|update
|script_id, name, content
|None
|-
|script
|delete
|script_id
|None
|}

=== Billing ===

You can check your credit balance from the API.

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|billing
|credit
|None
|None
|}

=== E-mail ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|email
|usage
|None
|None
|-
|email
|domain-list
|None
|None
|-
|email
|domain-add
|name
|None
|-
|email
|domain-remove
|domain_id
|None
|-
|email
|domain-dkim-set
|domain_id, selector, private_key
|None
|-
|email
|domain-dkim-unset
|domain_id
|None
|-
|email
|user-list
|domain_id
|None
|-
|email
|user-add
|domain_id, username, password
|None
|-
|email
|user-set-password
|domain_id, user_id, password
|None
|-
|email
|user-remove
|domain_id, user_id
|None
|-
|email
|alias-list
|domain_id
|None
|-
|email
|alias-add
|domain_id, name, target
|None
|-
|email
|alias-remove
|domain_id, alias_id
|None
|}

Main Page

2018-12-08T03:28:22Z

Favyen Bastani: /* Functionality */

Welcome to the [https://lunanode.com/ Luna Node] wiki! You may have been looking for our main [https://dynamic.lunanode.com/info Luna Node Dynamic] website.

== Getting started ==
* [https://dynamic.lunanode.com/info General information]
* [[Create your first instance]]
* [[Billing]]
* [http://status.lunanode.com/ Network/power status]
* [[Frequently asked questions]]

== Functionality ==

See these pages for details on how to use the core cloud features:

* [[Snapshots]]
* [[Security groups]]
* [[Volumes]]
* [[Startup scripts]]
* [[Floating IP addresses]]
* [[Virtual networks]]

We also have various miscellaneous features and information:

* [[Server monitoring]]
* [[DNS]]
* [[API]]
* [[Hardware specifications]]
* [[Application Templates]]
* [[Shelving]]
* [[Rescue Mode]]
* [[Burstable Resources]]
* [[Hosted E-mail]]

== How To ==

* [[ISO Installation]]
* [[Panel authentication|Control panel authentication]]
* [[Reselling]]
* [[Network configuration]]
* [[Volume-backed instance]]

Below are short pages with miscellaneous information.

* [[Increase network throughput]]
* [[Receive encrypted mail]]

Main Page

2018-11-30T17:45:16Z

Favyen Bastani: /* Getting started */

Welcome to the [https://lunanode.com/ Luna Node] wiki! You may have been looking for our main [https://dynamic.lunanode.com/info Luna Node Dynamic] website.

== Getting started ==
* [https://dynamic.lunanode.com/info General information]
* [[Create your first instance]]
* [[Billing]]
* [http://status.lunanode.com/ Network/power status]
* [[Frequently asked questions]]

== Functionality ==

See these pages for details on how to use the core cloud features:

* [[Snapshots]]
* [[Security groups]]
* [[Volumes]]
* [[Startup scripts]]
* [[Floating IP addresses]]
* [[Virtual networks]]

We also have various miscellaneous features and information:

* [[Server monitoring]]
* [[DNS]]
* [[API]]
* [[Managed Support]]
* [[Hardware specifications]]
* [[Application Templates]]
* [[Shelving]]
* [[Rescue Mode]]
* [[Burstable Resources]]
* [[Hosted E-mail]]

== How To ==

* [[ISO Installation]]
* [[Panel authentication|Control panel authentication]]
* [[Reselling]]
* [[Network configuration]]
* [[Volume-backed instance]]

Below are short pages with miscellaneous information.

* [[Increase network throughput]]
* [[Receive encrypted mail]]

Main Page

2018-11-30T17:45:10Z

Favyen Bastani:

Welcome to the [https://lunanode.com/ Luna Node] wiki! You may have been looking for our main [https://dynamic.lunanode.com/info Luna Node Dynamic] website.

== Getting started ==
* [https://dynamic.lunanode.com/info.php General information]
* [[Create your first instance]]
* [[Billing]]
* [http://status.lunanode.com/ Network/power status]
* [[Frequently asked questions]]

== Functionality ==

See these pages for details on how to use the core cloud features:

* [[Snapshots]]
* [[Security groups]]
* [[Volumes]]
* [[Startup scripts]]
* [[Floating IP addresses]]
* [[Virtual networks]]

We also have various miscellaneous features and information:

* [[Server monitoring]]
* [[DNS]]
* [[API]]
* [[Managed Support]]
* [[Hardware specifications]]
* [[Application Templates]]
* [[Shelving]]
* [[Rescue Mode]]
* [[Burstable Resources]]
* [[Hosted E-mail]]

== How To ==

* [[ISO Installation]]
* [[Panel authentication|Control panel authentication]]
* [[Reselling]]
* [[Network configuration]]
* [[Volume-backed instance]]

Below are short pages with miscellaneous information.

* [[Increase network throughput]]
* [[Receive encrypted mail]]

Frequently asked questions

2018-08-10T20:57:14Z

Favyen Bastani: /* Is additional bandwidth usage billed hourly? What about CPU usage for flexible plans? */

=== Cannot connect with SSH to newly booted VM ===

The provisioning and booting process may take as long as five minutes in some cases, depending on the specific operating system you are selecting. You can monitor progress over VNC by hitting the VNC Connection button. Once booted, you will be able to authenticate via SSH using the username and password displayed on the virtual machine page (or SSH key if you specified one).

Note that if you selected an image marked "ISO" when provisioning the VM, you will have to install the operating system via VNC. If you simply want a ready-made VM up and running, you should select an image marked "template" instead.

=== I cannot ping my IP address 172.20.8.187 ===

The IP address starting with 172 is the private IP address for your VM. Go to your VM details page and look for the "external IP address".

=== Do you support IPv6? ===

Yes! We support IPv6 in Toronto. Virtual machines are automatically assigned an IPv6 address via SLAAC. User-created virtual networks receive a /64 IPv6 allocation, and virtual machines created on such networks can use any address on the allocated subnet.

=== How to resize my VM? ===

To resize your VM, select the VM and use the Resize utility.

Note that the resize will fail if you attempt to resize a local-storage-backed instance to a plan with a smaller disk size. Follow these steps to resize a VM down:

* Take a snapshot of the VM
* Once the snapshot is ready (you can monitor the progress from the Images tab), go to the Volumes tab and create a volume from the snapshot with the old snapshot size
* Boot a new VM with "Ubuntu 14.04 64-bit" template, and attach the volume to the VM
* Assuming that the volume is attached at /dev/vdc, run <tt>resize2fs /dev/vdc1 10G</tt> (replacing 10G with desired size in gigabytes; aim for as small a size as possible, so that the partition and disk will fit)
* Then, run fdisk /dev/vdc and re-create the partition; make sure the start sector is the same, and also make sure to set the bootable flag:

<nowiki># fdisk /dev/vdc

Command (m for help): p

Disk /dev/vdc: 37.6 GB, 37580963840 bytes
4 heads, 32 sectors/track, 573440 cylinders, total 73400320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d8e94

Device Boot Start End Blocks Id System
/dev/vdc1 * 2048 73400319 36699136 83 Linux

Command (m for help): d 1
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-73400319, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-73400319, default 73400319): 33556479

Command (m for help): a
Partition number (1-4): 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.</nowiki>

Above, to calculate the last sector, you can try multiplying the default last sector by the fraction that you're resizing down; e.g. if resizing from 35 GB to 15 GB, multiply (73400319 / 35 * 14) (we use 14 instead of just 15 since the partition table and other elements take up some space; do make sure that the filesystem has been resized to less than this many GB in the <tt>resize2fs</tt> command earlier).

* Create a new volume with the desired size, and attach it to the same VM
* Use <tt>fdisk /dev/vdd</tt> to create identical partitions on the new volume
* Use <tt>dd if=/dev/vdc1 of=/dev/vdd1 bs=64k</tt> to copy data from the partition on the old volume to the partition on the new volume
* Detach both volumes from the VM, and delete the volume with old size
* Select the volume with new size from the Volumes tab, and convert it to an image
* Boot the new VM from the image

=== Unable to attach volume to my Windows VM ===

Volumes are best used with Linux virtual machines using the virtio driver. If you are using another operating system or ide driver, then you likely will need to shut down the VM before attaching or detaching volumes. You may also need to specify the attachment target as /dev/hdc or /dev/hdd or etc.

=== What is the default username for virtual machines provisioned using the stock templates ===
The administrative username for template-based virtual machines are as the following:
*Ubuntu: ubuntu
*Debian: debian
*CentOS: cloud-user / centos
*Fedora: fedora
*CoreOS: core

=== I cannot login as root! ===

As stated in the "VM provisioned successfully" email, template-based virtual machines are configured to accept connections with the administrative user. The password is displayed on the virtual machine details page. For security reasons, the VM does not accept root login by default.

Once authenticated as the administrative user, you can execute <tt>sudo su</tt> to login as root.

If you wish, you can of course set a root password. First, login as root by authenticating with the administrative user and running <tt>sudo su</tt>. Then, run <tt>passwd</tt> to set a root user password. Finally, edit the SSH configuration:

<nowiki>sed -i 's/.*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
service ssh restart; service sshd restart
</nowiki>

Then logout and you should be able to authenicate via SSH directly as the root user with your newly set password.

Alternatively, you can use a [[Startup scripts|startup script]] so that the root password is set when the VM boots.

Note: use an SSH client like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] to authenticate.

Please note that our services are unmanaged and you are responsible or the security of your VM; if your VM is taken over and used in denial of service attacks, spam, or other activities that violate our [https://dynamic.lunanode.com/terms terms of service], your account may be suspended depending on the circumstances.

=== Is additional bandwidth usage billed hourly? ===

Bandwidth is billed as a '''consumable resource''', i.e., you are charged for the amount that you use; it is not per-hour or per-month since there is no timespan. Bandwidth allocations from VM plans are allocated on a per-calendar-month basis. So, if you have an s.half VM and use 1500 GB bandwidth in a month (500 GB over the plan allocation), then you will be billed $0.003 for each additional GB ($1.50 total), and it does not matter how many hours it took you to use that 500 GB.

=== My disk space is smaller than the plan disk ===

Almost all of the templates will automatically resize the partition and filesystem the first time that the virtual machine boots. If you install from ISO, you can also choose the partitioning scheme.

So, if you are having this problem where filesystem doesn't actually get resized, it likely means you are using the CentOS 6 template, which does not support automatic filesystem resizing. You can instead run the following commands to manually resize the partition/filesystem:

<nowiki>
fdisk /dev/vda
> u
(this will switch units to sector; it is important that you use sectors and not cylinders!)
> p
(this will print all of the partitions, we will refer to the data later)
> d 1
(this will display "Selected partition 1" and delete the first partition)
> n
(select "p" for primary partition)
(partition number should be 1, but make sure it matches the number displayed in print command)
(first sector should be 2048, but make sure it matches the "Start" column displayed in print command)
(and set last sector to the default value)
> a
(type "1" to make new first partition bootable)
> w
(this will write the new partitions and exit fdisk)
shutdown -r 0
(connect to VM after it reboots, if it has resized partition but not filesystem then run resize2fs)
</nowiki>

Warning: when creating the new partition, make sure that the first sector matches the sector displayed in print command (typically 2048). The default option that fdisk will provide is incorrect.

=== The VNC connection doesn't work for me ===

This is usually caused by a firewall on your computer, router, or at your ISP; or because of outdated browser software. If you are using the noVNC client, first try switching to another browser and see if it works there.

If it still doesn't connect (e.g. you get "Connection Timeout" error), then you can try to use the VNC tunnel connection method so that you can use your own desktop VNC client instead of noVNC. To do this, go to the Account tab in the top right, scroll down to VNC Connection Method, and change to tunnel. Then, when you click the VNC button, you will be given VNC login details that you can plug into your desktop VNC client to connect to your virtual machine instance.

Note: you may have to subtract 5900 from the port provided by the tunnel in some cases. So for example, if the panel says to connect to 167.114.159.49:6105, and that doesn't work, then also try connecting to 167.114.159.49:205.

=== Can I shutdown my VMs to avoid being billed? ===

You can use the Shelve functionality to deactivate your virtual machine. Once a VM is shelved, you will only be billed for the storage space, at $0.03/GB/mo, and assigned IP addresses, at $1/mo (both fees are charged hourly); the pricing change will be reflected in the billing section of the panel dashboard. You can reactivate the VM at any time by pressing Unshelve from the VM details.

=== Why is my geo-location database showing the IP address in an incorrect location? ===

We set standard Referral Whois (RWhois) records that indicate the exact location of all IP addresses that we operate. If your geo-location database does not show the correct location for our IP addresses, that means that the database provider is not checking our RWhois records. You would need to direct questions regarding the inaccuracy of their database to them. Please do not contact us with any questions about IP geo-location as we do not maintain these databases.

Frequently asked questions

2018-08-10T20:53:01Z

Favyen Bastani: /* How to purchase the Special XYZ plan? */

=== Cannot connect with SSH to newly booted VM ===

The provisioning and booting process may take as long as five minutes in some cases, depending on the specific operating system you are selecting. You can monitor progress over VNC by hitting the VNC Connection button. Once booted, you will be able to authenticate via SSH using the username and password displayed on the virtual machine page (or SSH key if you specified one).

Note that if you selected an image marked "ISO" when provisioning the VM, you will have to install the operating system via VNC. If you simply want a ready-made VM up and running, you should select an image marked "template" instead.

=== I cannot ping my IP address 172.20.8.187 ===

The IP address starting with 172 is the private IP address for your VM. Go to your VM details page and look for the "external IP address".

=== Do you support IPv6? ===

Yes! We support IPv6 in Toronto. Virtual machines are automatically assigned an IPv6 address via SLAAC. User-created virtual networks receive a /64 IPv6 allocation, and virtual machines created on such networks can use any address on the allocated subnet.

=== How to resize my VM? ===

To resize your VM, select the VM and use the Resize utility.

Note that the resize will fail if you attempt to resize a local-storage-backed instance to a plan with a smaller disk size. Follow these steps to resize a VM down:

* Take a snapshot of the VM
* Once the snapshot is ready (you can monitor the progress from the Images tab), go to the Volumes tab and create a volume from the snapshot with the old snapshot size
* Boot a new VM with "Ubuntu 14.04 64-bit" template, and attach the volume to the VM
* Assuming that the volume is attached at /dev/vdc, run <tt>resize2fs /dev/vdc1 10G</tt> (replacing 10G with desired size in gigabytes; aim for as small a size as possible, so that the partition and disk will fit)
* Then, run fdisk /dev/vdc and re-create the partition; make sure the start sector is the same, and also make sure to set the bootable flag:

<nowiki># fdisk /dev/vdc

Command (m for help): p

Disk /dev/vdc: 37.6 GB, 37580963840 bytes
4 heads, 32 sectors/track, 573440 cylinders, total 73400320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d8e94

Device Boot Start End Blocks Id System
/dev/vdc1 * 2048 73400319 36699136 83 Linux

Command (m for help): d 1
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-73400319, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-73400319, default 73400319): 33556479

Command (m for help): a
Partition number (1-4): 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.</nowiki>

Above, to calculate the last sector, you can try multiplying the default last sector by the fraction that you're resizing down; e.g. if resizing from 35 GB to 15 GB, multiply (73400319 / 35 * 14) (we use 14 instead of just 15 since the partition table and other elements take up some space; do make sure that the filesystem has been resized to less than this many GB in the <tt>resize2fs</tt> command earlier).

* Create a new volume with the desired size, and attach it to the same VM
* Use <tt>fdisk /dev/vdd</tt> to create identical partitions on the new volume
* Use <tt>dd if=/dev/vdc1 of=/dev/vdd1 bs=64k</tt> to copy data from the partition on the old volume to the partition on the new volume
* Detach both volumes from the VM, and delete the volume with old size
* Select the volume with new size from the Volumes tab, and convert it to an image
* Boot the new VM from the image

=== Unable to attach volume to my Windows VM ===

Volumes are best used with Linux virtual machines using the virtio driver. If you are using another operating system or ide driver, then you likely will need to shut down the VM before attaching or detaching volumes. You may also need to specify the attachment target as /dev/hdc or /dev/hdd or etc.

=== What is the default username for virtual machines provisioned using the stock templates ===
The administrative username for template-based virtual machines are as the following:
*Ubuntu: ubuntu
*Debian: debian
*CentOS: cloud-user / centos
*Fedora: fedora
*CoreOS: core

=== I cannot login as root! ===

As stated in the "VM provisioned successfully" email, template-based virtual machines are configured to accept connections with the administrative user. The password is displayed on the virtual machine details page. For security reasons, the VM does not accept root login by default.

Once authenticated as the administrative user, you can execute <tt>sudo su</tt> to login as root.

If you wish, you can of course set a root password. First, login as root by authenticating with the administrative user and running <tt>sudo su</tt>. Then, run <tt>passwd</tt> to set a root user password. Finally, edit the SSH configuration:

<nowiki>sed -i 's/.*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
service ssh restart; service sshd restart
</nowiki>

Then logout and you should be able to authenicate via SSH directly as the root user with your newly set password.

Alternatively, you can use a [[Startup scripts|startup script]] so that the root password is set when the VM boots.

Note: use an SSH client like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] to authenticate.

Please note that our services are unmanaged and you are responsible or the security of your VM; if your VM is taken over and used in denial of service attacks, spam, or other activities that violate our [https://dynamic.lunanode.com/terms terms of service], your account may be suspended depending on the circumstances.

=== Is additional bandwidth usage billed hourly? What about CPU usage for flexible plans? ===

Both bandwidth and CPU are billed as '''consumable resources''', i.e., you are charged for the amount that you use. For example, if you use 5 GB bandwidth, then you will be billed $0.003 for each GB, and it does not matter how long it takes you to use that 5 GB. Similarly, for CPU usage, if you use 10 CPU-core-hours (e.g. 5% of a CPU core for 200 hours, or 100% of a CPU core for 10 hours) then you will be billed $0.22, and again it doesn't matter what timespan you use it over.

So, the question of whether we bill "hourly" versus "monthly" doesn't make sense for flexible resources (including additional bandwidth on all plans, as well as bandwidth / CPU for flexible plans). For fixed resources (memory, disk size, etc.), though, we do bill hourly.

If you are still confused, this is probably because you are used to monthly providers that may charge for additional CPU core or additional 1 TB bandwidth for the next month. The reason that monthly providers do this is because they don't expect you to use the full allocation, and if you only use 500 GB additional bandwidth then they save 500 GB on their end. However, in our case, we charge for resources '''as they are being consumed''' instead of in advance, so hourly versus monthly no longer matters, and you only need to pay for what you use.

=== My disk space is smaller than the plan disk ===

Almost all of the templates will automatically resize the partition and filesystem the first time that the virtual machine boots. If you install from ISO, you can also choose the partitioning scheme.

So, if you are having this problem where filesystem doesn't actually get resized, it likely means you are using the CentOS 6 template, which does not support automatic filesystem resizing. You can instead run the following commands to manually resize the partition/filesystem:

<nowiki>
fdisk /dev/vda
> u
(this will switch units to sector; it is important that you use sectors and not cylinders!)
> p
(this will print all of the partitions, we will refer to the data later)
> d 1
(this will display "Selected partition 1" and delete the first partition)
> n
(select "p" for primary partition)
(partition number should be 1, but make sure it matches the number displayed in print command)
(first sector should be 2048, but make sure it matches the "Start" column displayed in print command)
(and set last sector to the default value)
> a
(type "1" to make new first partition bootable)
> w
(this will write the new partitions and exit fdisk)
shutdown -r 0
(connect to VM after it reboots, if it has resized partition but not filesystem then run resize2fs)
</nowiki>

Warning: when creating the new partition, make sure that the first sector matches the sector displayed in print command (typically 2048). The default option that fdisk will provide is incorrect.

=== The VNC connection doesn't work for me ===

This is usually caused by a firewall on your computer, router, or at your ISP; or because of outdated browser software. If you are using the noVNC client, first try switching to another browser and see if it works there.

If it still doesn't connect (e.g. you get "Connection Timeout" error), then you can try to use the VNC tunnel connection method so that you can use your own desktop VNC client instead of noVNC. To do this, go to the Account tab in the top right, scroll down to VNC Connection Method, and change to tunnel. Then, when you click the VNC button, you will be given VNC login details that you can plug into your desktop VNC client to connect to your virtual machine instance.

Note: you may have to subtract 5900 from the port provided by the tunnel in some cases. So for example, if the panel says to connect to 167.114.159.49:6105, and that doesn't work, then also try connecting to 167.114.159.49:205.

=== Can I shutdown my VMs to avoid being billed? ===

You can use the Shelve functionality to deactivate your virtual machine. Once a VM is shelved, you will only be billed for the storage space, at $0.03/GB/mo, and assigned IP addresses, at $1/mo (both fees are charged hourly); the pricing change will be reflected in the billing section of the panel dashboard. You can reactivate the VM at any time by pressing Unshelve from the VM details.

=== Why is my geo-location database showing the IP address in an incorrect location? ===

We set standard Referral Whois (RWhois) records that indicate the exact location of all IP addresses that we operate. If your geo-location database does not show the correct location for our IP addresses, that means that the database provider is not checking our RWhois records. You would need to direct questions regarding the inaccuracy of their database to them. Please do not contact us with any questions about IP geo-location as we do not maintain these databases.

Frequently asked questions

2018-08-10T20:52:56Z

Favyen Bastani: /* My account request was denied */

=== Cannot connect with SSH to newly booted VM ===

The provisioning and booting process may take as long as five minutes in some cases, depending on the specific operating system you are selecting. You can monitor progress over VNC by hitting the VNC Connection button. Once booted, you will be able to authenticate via SSH using the username and password displayed on the virtual machine page (or SSH key if you specified one).

Note that if you selected an image marked "ISO" when provisioning the VM, you will have to install the operating system via VNC. If you simply want a ready-made VM up and running, you should select an image marked "template" instead.

=== I cannot ping my IP address 172.20.8.187 ===

The IP address starting with 172 is the private IP address for your VM. Go to your VM details page and look for the "external IP address".

=== How to purchase the Special XYZ plan? ===

First, check https://dynamic.lunanode.com/info to make sure it is still in stock. If so, you can [https://dynamic.lunanode.com/register register an account] and then go to the Create VM sidebar option to create the VM of your desired special plan. Note that special plans are only available for a limited time.

=== Do you support IPv6? ===

Yes! We support IPv6 in Toronto. Virtual machines are automatically assigned an IPv6 address via SLAAC. User-created virtual networks receive a /64 IPv6 allocation, and virtual machines created on such networks can use any address on the allocated subnet.

=== How to resize my VM? ===

To resize your VM, select the VM and use the Resize utility.

Note that the resize will fail if you attempt to resize a local-storage-backed instance to a plan with a smaller disk size. Follow these steps to resize a VM down:

* Take a snapshot of the VM
* Once the snapshot is ready (you can monitor the progress from the Images tab), go to the Volumes tab and create a volume from the snapshot with the old snapshot size
* Boot a new VM with "Ubuntu 14.04 64-bit" template, and attach the volume to the VM
* Assuming that the volume is attached at /dev/vdc, run <tt>resize2fs /dev/vdc1 10G</tt> (replacing 10G with desired size in gigabytes; aim for as small a size as possible, so that the partition and disk will fit)
* Then, run fdisk /dev/vdc and re-create the partition; make sure the start sector is the same, and also make sure to set the bootable flag:

<nowiki># fdisk /dev/vdc

Command (m for help): p

Disk /dev/vdc: 37.6 GB, 37580963840 bytes
4 heads, 32 sectors/track, 573440 cylinders, total 73400320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d8e94

Device Boot Start End Blocks Id System
/dev/vdc1 * 2048 73400319 36699136 83 Linux

Command (m for help): d 1
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-73400319, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-73400319, default 73400319): 33556479

Command (m for help): a
Partition number (1-4): 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.</nowiki>

Above, to calculate the last sector, you can try multiplying the default last sector by the fraction that you're resizing down; e.g. if resizing from 35 GB to 15 GB, multiply (73400319 / 35 * 14) (we use 14 instead of just 15 since the partition table and other elements take up some space; do make sure that the filesystem has been resized to less than this many GB in the <tt>resize2fs</tt> command earlier).

* Create a new volume with the desired size, and attach it to the same VM
* Use <tt>fdisk /dev/vdd</tt> to create identical partitions on the new volume
* Use <tt>dd if=/dev/vdc1 of=/dev/vdd1 bs=64k</tt> to copy data from the partition on the old volume to the partition on the new volume
* Detach both volumes from the VM, and delete the volume with old size
* Select the volume with new size from the Volumes tab, and convert it to an image
* Boot the new VM from the image

=== Unable to attach volume to my Windows VM ===

Volumes are best used with Linux virtual machines using the virtio driver. If you are using another operating system or ide driver, then you likely will need to shut down the VM before attaching or detaching volumes. You may also need to specify the attachment target as /dev/hdc or /dev/hdd or etc.

=== What is the default username for virtual machines provisioned using the stock templates ===
The administrative username for template-based virtual machines are as the following:
*Ubuntu: ubuntu
*Debian: debian
*CentOS: cloud-user / centos
*Fedora: fedora
*CoreOS: core

=== I cannot login as root! ===

As stated in the "VM provisioned successfully" email, template-based virtual machines are configured to accept connections with the administrative user. The password is displayed on the virtual machine details page. For security reasons, the VM does not accept root login by default.

Once authenticated as the administrative user, you can execute <tt>sudo su</tt> to login as root.

If you wish, you can of course set a root password. First, login as root by authenticating with the administrative user and running <tt>sudo su</tt>. Then, run <tt>passwd</tt> to set a root user password. Finally, edit the SSH configuration:

<nowiki>sed -i 's/.*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
service ssh restart; service sshd restart
</nowiki>

Then logout and you should be able to authenicate via SSH directly as the root user with your newly set password.

Alternatively, you can use a [[Startup scripts|startup script]] so that the root password is set when the VM boots.

Note: use an SSH client like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] to authenticate.

Please note that our services are unmanaged and you are responsible or the security of your VM; if your VM is taken over and used in denial of service attacks, spam, or other activities that violate our [https://dynamic.lunanode.com/terms terms of service], your account may be suspended depending on the circumstances.

=== Is additional bandwidth usage billed hourly? What about CPU usage for flexible plans? ===

Both bandwidth and CPU are billed as '''consumable resources''', i.e., you are charged for the amount that you use. For example, if you use 5 GB bandwidth, then you will be billed $0.003 for each GB, and it does not matter how long it takes you to use that 5 GB. Similarly, for CPU usage, if you use 10 CPU-core-hours (e.g. 5% of a CPU core for 200 hours, or 100% of a CPU core for 10 hours) then you will be billed $0.22, and again it doesn't matter what timespan you use it over.

So, the question of whether we bill "hourly" versus "monthly" doesn't make sense for flexible resources (including additional bandwidth on all plans, as well as bandwidth / CPU for flexible plans). For fixed resources (memory, disk size, etc.), though, we do bill hourly.

If you are still confused, this is probably because you are used to monthly providers that may charge for additional CPU core or additional 1 TB bandwidth for the next month. The reason that monthly providers do this is because they don't expect you to use the full allocation, and if you only use 500 GB additional bandwidth then they save 500 GB on their end. However, in our case, we charge for resources '''as they are being consumed''' instead of in advance, so hourly versus monthly no longer matters, and you only need to pay for what you use.

=== My disk space is smaller than the plan disk ===

Almost all of the templates will automatically resize the partition and filesystem the first time that the virtual machine boots. If you install from ISO, you can also choose the partitioning scheme.

So, if you are having this problem where filesystem doesn't actually get resized, it likely means you are using the CentOS 6 template, which does not support automatic filesystem resizing. You can instead run the following commands to manually resize the partition/filesystem:

<nowiki>
fdisk /dev/vda
> u
(this will switch units to sector; it is important that you use sectors and not cylinders!)
> p
(this will print all of the partitions, we will refer to the data later)
> d 1
(this will display "Selected partition 1" and delete the first partition)
> n
(select "p" for primary partition)
(partition number should be 1, but make sure it matches the number displayed in print command)
(first sector should be 2048, but make sure it matches the "Start" column displayed in print command)
(and set last sector to the default value)
> a
(type "1" to make new first partition bootable)
> w
(this will write the new partitions and exit fdisk)
shutdown -r 0
(connect to VM after it reboots, if it has resized partition but not filesystem then run resize2fs)
</nowiki>

Warning: when creating the new partition, make sure that the first sector matches the sector displayed in print command (typically 2048). The default option that fdisk will provide is incorrect.

=== The VNC connection doesn't work for me ===

This is usually caused by a firewall on your computer, router, or at your ISP; or because of outdated browser software. If you are using the noVNC client, first try switching to another browser and see if it works there.

If it still doesn't connect (e.g. you get "Connection Timeout" error), then you can try to use the VNC tunnel connection method so that you can use your own desktop VNC client instead of noVNC. To do this, go to the Account tab in the top right, scroll down to VNC Connection Method, and change to tunnel. Then, when you click the VNC button, you will be given VNC login details that you can plug into your desktop VNC client to connect to your virtual machine instance.

Note: you may have to subtract 5900 from the port provided by the tunnel in some cases. So for example, if the panel says to connect to 167.114.159.49:6105, and that doesn't work, then also try connecting to 167.114.159.49:205.

=== Can I shutdown my VMs to avoid being billed? ===

You can use the Shelve functionality to deactivate your virtual machine. Once a VM is shelved, you will only be billed for the storage space, at $0.03/GB/mo, and assigned IP addresses, at $1/mo (both fees are charged hourly); the pricing change will be reflected in the billing section of the panel dashboard. You can reactivate the VM at any time by pressing Unshelve from the VM details.

=== Why is my geo-location database showing the IP address in an incorrect location? ===

We set standard Referral Whois (RWhois) records that indicate the exact location of all IP addresses that we operate. If your geo-location database does not show the correct location for our IP addresses, that means that the database provider is not checking our RWhois records. You would need to direct questions regarding the inaccuracy of their database to them. Please do not contact us with any questions about IP geo-location as we do not maintain these databases.

Managed Support

2018-08-10T20:00:11Z

Favyen Bastani:

While our services are unmanaged, we provide managed support at '''$100.00/hour (billed in 15-minute increments, with one-hour minimum)'''. Our experienced staff is able to assist in a diverse set of areas, including server software configuration and optimization (e.g. web/mail/DNS servers, control panels, game servers), penetration testing and security breanch investigation, distributed system setup (e.g. GlusterFS/MooseFS/CephFS, front-end web server redundancy, replicated mail server), and backup implementation and recovery.

You can open a managed ticket on the '''Support tab''', by selecting the "Managed Support" category. After receiving your ticket, we will assess the complexity of your request and reply with a time estimate for the task; upon your confirmation, we will complete the request, and management time will be charged to your account credit.

We are also able to automatically intervene on your server if a service fails -- contact [mailto:sales@lunanode.com sales@lunanode.com] for more information.

== Providing Access ==

For most kinds of managed support, we will need access to your server. The preferred way to do this is to add our SSH key to your authorized keys file, and let us know what user account to authenticate as:

<nowiki>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/YL5kEqOHxWmSAneuhEkD6eEgbXh5ivE2XGQJaKvfWkaZ8n3fkPe/Um54Oaa0isSXKzslEEIvataysrk7QUgfsHfrNd/CayQmy+6xRj8sZjN92gHlA27rhJX007lG9O6VAVXBOtnlqdxbCh/MJkZWhLgJ5suoeNx1DIeUXjE3yw8jYbLBdDDW/zr+ewxJ9nxEtdz3TRnxoRST889ZzImS6Mz/7OxnibWzALyP0LXqM4WBmipdB/eRx1dQnIaWGgN+NTMlf0FGQCFmAT/veS75d+ZO310QdCz1dmOuW07+ECCnkqEmGUecv9Eli0DIw5Qa6w+ggEvaPJTJDEREcZ3r lunanode@lunanode</nowiki>

Or simply:

<nowiki>curl https://lunanode.com/sshkey.txt >> ~/.ssh/authorized_keys</nowiki>

Alternatively, you can provide your password via the ticket, but this is not recommended.

Managed Support

2018-08-10T20:00:00Z

Favyen Bastani:

While our services are unmanaged, we provide managed support at '''$100.00/hour (billed in 15-minute increments, with one-hour minimum)'''. Our experienced staff is able to assist in a diverse set of areas, including server software configuration and optimization (e.g. web/mail/DNS servers, control panels, game servers), penetration testing and security breanch investigation, distributed system setup (e.g. GlusterFS/MooseFS/CephFS, front-end web server redundancy, replicated mail server), and backup implementation and recovery.

You can open a managed ticket on the '''Support tab''', by selecting the "Managed Support" category. After receiving your ticket, we will assess the complexity of your request and reply within thirty minutes with a time estimate for the task; upon your confirmation, we will complete the request, and management time will be charged to your account credit.

We are also able to automatically intervene on your server if a service fails -- contact [mailto:sales@lunanode.com sales@lunanode.com] for more information.

== Providing Access ==

For most kinds of managed support, we will need access to your server. The preferred way to do this is to add our SSH key to your authorized keys file, and let us know what user account to authenticate as:

<nowiki>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC/YL5kEqOHxWmSAneuhEkD6eEgbXh5ivE2XGQJaKvfWkaZ8n3fkPe/Um54Oaa0isSXKzslEEIvataysrk7QUgfsHfrNd/CayQmy+6xRj8sZjN92gHlA27rhJX007lG9O6VAVXBOtnlqdxbCh/MJkZWhLgJ5suoeNx1DIeUXjE3yw8jYbLBdDDW/zr+ewxJ9nxEtdz3TRnxoRST889ZzImS6Mz/7OxnibWzALyP0LXqM4WBmipdB/eRx1dQnIaWGgN+NTMlf0FGQCFmAT/veS75d+ZO310QdCz1dmOuW07+ECCnkqEmGUecv9Eli0DIw5Qa6w+ggEvaPJTJDEREcZ3r lunanode@lunanode</nowiki>

Or simply:

<nowiki>curl https://lunanode.com/sshkey.txt >> ~/.ssh/authorized_keys</nowiki>

Alternatively, you can provide your password via the ticket, but this is not recommended.

Main Page

2018-08-10T19:59:33Z

Favyen Bastani:

Welcome to the [https://lunanode.com/ Luna Node] wiki! You may have been looking for our main [https://dynamic.lunanode.com/info.php Luna Node Dynamic] website.

== Getting started ==
* [https://dynamic.lunanode.com/info.php General information]
* [[Create your first instance]]
* [[Billing]]
* [http://status.lunanode.com/ Network/power status]
* [[Frequently asked questions]]

== Functionality ==

See these pages for details on how to use the core cloud features:

* [[Snapshots]]
* [[Security groups]]
* [[Volumes]]
* [[Startup scripts]]
* [[Floating IP addresses]]
* [[Virtual networks]]

We also have various miscellaneous features and information:

* [[Server monitoring]]
* [[DNS]]
* [[API]]
* [[Managed Support]]
* [[Hardware specifications]]
* [[Application Templates]]
* [[Shelving]]
* [[Rescue Mode]]
* [[Burstable Resources]]
* [[Hosted E-mail]]

== How To ==

* [[ISO Installation]]
* [[Panel authentication|Control panel authentication]]
* [[Reselling]]
* [[Network configuration]]
* [[Volume-backed instance]]

Below are short pages with miscellaneous information.

* [[Increase network throughput]]
* [[Receive encrypted mail]]

Flexible plans

2018-08-10T19:59:25Z

Favyen Bastani: Replaced content with "Flexible plans are no longer supported. All VMs are now somewhat flexible, in the sense that you can pay on-demand for additional CPU performance. See Burstable Resource..."

Flexible plans are no longer supported. All VMs are now somewhat flexible, in the sense that you can pay on-demand for additional CPU performance. See [[Burstable Resources]], "Paying for CPU Performance above the Baseline".

Main Page

2018-08-10T19:58:08Z

Favyen Bastani: /* Functionality */

Welcome to the [https://lunanode.com/ Luna Node] wiki! You may have been looking for our main [https://dynamic.lunanode.com/info.php Luna Node Dynamic] website.

== Getting started ==
* [https://dynamic.lunanode.com/info.php General information]
* [[Create your first instance]]
* [[Billing]]
* [http://status.lunanode.com/ Network/power status]
* [[Frequently asked questions]]

== Functionality ==

See these pages for details on how to use the core cloud features:

* [[Snapshots]]
* [[Security groups]]
* [[Volumes]]
* [[Startup scripts]]
* [[Floating IP addresses]]
* [[Virtual networks]]

We also have various miscellaneous features and information:

* [[Server monitoring]]
* [[DNS]]
* [[API]]
* [[Managed Support]]
* [[Flexible plans]]
* [[Hardware specifications]]
* [[Application Templates]]
* [[Shelving]]
* [[Rescue Mode]]
* [[Burstable Resources]]
* [[Hosted E-mail]]

== How To ==

* [[ISO Installation]]
* [[Panel authentication|Control panel authentication]]
* [[Reselling]]
* [[Network configuration]]
* [[Volume-backed instance]]

Below are short pages with miscellaneous information.

* [[Increase network throughput]]
* [[Receive encrypted mail]]

Hosted E-mail

2018-08-10T19:57:57Z

Favyen Bastani: Created page with "Our hosted e-mail services allow you to easily set up e-mail on your domains; you can send and receive e-mail either via webmail or IMAPS/SMTPS. We support multiple user acco..."

Our hosted e-mail services allow you to easily set up e-mail on your domains; you can send and receive e-mail either via webmail or IMAPS/SMTPS.

We support multiple user accounts, e-mail aliases, DKIM, and more.

We charge $0.2/mo per GB of storage used (rounded up to the nearest GB and billed hourly) and $0.1 per 1,000 e-mails sent. The first 5,000 e-mails each month and the first 1 GB of storage are free, assuming you use at least $3 credit on other services in the current calendar month. Note that e-mails forwarded to external accounts via aliases are counted as e-mails sent.

Hardware specifications

2018-08-10T17:33:09Z

Favyen Bastani: /* Toronto */

The specifications below are for all SSD plans (e.g. s.half, m.1, c.1).

== Toronto ==

We use:

* Dual Xeon E5-2690 v2 CPUs (older hypervisors have Xeon E5-2690 or Xeon E5-2670)
* Hardware RAID
* Pure SSD RAID10 storage array
* 2x10gbps ports, one for VM network and one for the storage cluster

== Montreal/Roubaix ==

We use the same type of hardware in Montreal and Roubaix:

* Dual Xeon E5-2660v3 CPUs
* Hardware RAID
* Pure SSD RAID10 storage array
* 2x10gbps ports, one for VM network and one for the storage cluster
* OVH Anti-DDoS Pro DDoS mitigation system

Hardware specifications

2018-08-10T17:32:48Z

Favyen Bastani: /* Toronto */

The specifications below are for all SSD plans (e.g. s.half, m.1, c.1).

== Toronto ==

We use:

* Dual Xeon E5-2690 v2 or Xeon E5-2690 or Xeon E5-2670 CPUs
* Hardware RAID
* Pure SSD RAID10 storage array
* 2x10gbps ports, one for VM network and one for the storage cluster

== Montreal/Roubaix ==

We use the same type of hardware in Montreal and Roubaix:

* Dual Xeon E5-2660v3 CPUs
* Hardware RAID
* Pure SSD RAID10 storage array
* 2x10gbps ports, one for VM network and one for the storage cluster
* OVH Anti-DDoS Pro DDoS mitigation system

Hardware specifications

2018-08-10T17:31:49Z

Favyen Bastani:

The specifications below are for all SSD plans (e.g. s.half, m.1, c.1).

== Toronto ==

We use:

* Dual Xeon E5-2670 or Xeon E5-2690 v2 CPUs
* Hardware RAID
* Pure SSD RAID10 storage array
* 2x10gbps ports, one for VM network and one for the storage cluster

== Montreal/Roubaix ==

We use the same type of hardware in Montreal and Roubaix:

* Dual Xeon E5-2660v3 CPUs
* Hardware RAID
* Pure SSD RAID10 storage array
* 2x10gbps ports, one for VM network and one for the storage cluster
* OVH Anti-DDoS Pro DDoS mitigation system

Burstable Resources

2018-04-16T15:43:10Z

Favyen Bastani:

In order to maximize affordability and flexibility, Luna Node General-Purpose and Memory-Optimized virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

Compute-Optimized virtual machines are assigned dedicated CPU cores.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 100% CPU utilization for every 1.0 CPU-Points specified in the plan (for example, s.half includes 0.2 CPU-Points, and a baseline performance of 20% CPU utilization)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to their baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core over 30 days on a s.1 VM, which has 0.4 plan cpu-points. Your VM will need an additional 0.6 burst points for every five-minute interval in the month, on top of the 0.4 baseline performance included in the plan. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-02-25T17:21:39Z

Favyen Bastani:

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 100% CPU utilization for every 1.0 CPU-Points specified in the plan (for example, s.half includes 0.2 CPU-Points, and a baseline performance of 20% CPU utilization)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to their baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core over 30 days on a s.1 VM, which has 0.4 plan cpu-points. Your VM will need an additional 0.6 burst points for every five-minute interval in the month, on top of the 0.4 baseline performance included in the plan. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-02-25T17:15:26Z

Favyen Bastani: /* Paying for CPU Performance above the Baseline */

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: based on the CPU-Points specified in the plan
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to their baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core over 30 days on a s.1 VM, which has 0.4 plan cpu-points. Your VM will need an additional 0.6 burst points for every five-minute interval in the month, on top of the 0.4 baseline performance included in the plan. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-02-25T17:10:47Z

Favyen Bastani:

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: based on the CPU-Points specified in the plan
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to their baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives the plan CPU-Points every five minutes.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if an s.half VM (which has 0.2 plan CPU-Points) starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-02-25T17:05:08Z

Favyen Bastani:

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account on the same hypervisor with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until you no longer have any VMs on the same hypervisor with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-16T06:53:02Z

Favyen Bastani: /* Burst Points System */

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until there are no VMs on your account with close to the maximum CPU points. I/O points cannot be "borrowed".

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-16T06:51:34Z

Favyen Bastani: /* Burst Points System */

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Borrowing.''' If a VM runs out of CPU points, and there is another VM on your account with close to the maximum CPU points, then the system will re-allocate points from the second VM to the first. Thus, the first VM will not be throttled until there are no VMs on your account with close to the maximum CPU points.

In some cases, you may want to prevent a VM's CPU points from being re-allocated to other VMs even if its points are close to the maximum. To do so, disable CPU utilization lending from the CPU tab.

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-04T20:37:56Z

Favyen Bastani: /* Burst Points System */

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

'''Monitoring points.''' Charts showing CPU points and I/O points over time can be retrieved from the Graphs tab.

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-04T19:53:36Z

Favyen Bastani: /* Paying for CPU Performance above the Baseline */

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

== Paying for CPU Performance above the Baseline ==

By default, VMs may be throttled once they run out of CPU or I/O burst points.

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-04T19:53:11Z

Favyen Bastani: /* Paying for CPU Performance above the Baseline */

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

== Paying for CPU Performance above the Baseline ==

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account. If the VM's CPU burst point count never reaches zero, then you will not be charged.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-04T19:52:44Z

Favyen Bastani:

In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CPU cores or physical disks. Because most application workloads have both periods of high CPU and I/O utilization and periods of low utilization, this maximizes cost savings -- essentially, '''instead of needing to continuously pay for a particular VM's peak utilization, you need only pay for its average utilization'''.

At a high-level, we assign each VM a baseline CPU and I/O performance. If your VM has periods where its resource utilization is below this baseline, then it collects "points" that it can later use to obtain resource utilization above the baseline.

(Before 3 January 2018, enforcement of excessive resource utilization was performed manually. It is now automatically managed by the Luna Node platform.)

== Burst Points System ==

'''Baseline performance.''' Each virtual machine has a baseline performance:

* CPU: 20% utilization per core (if a VM has two cores, it could use 40% of one core, 30% of one and 10% of the other, etc.)
* Disk I/O: 100 IOPS

'''Burst points.''' The platform keeps track of CPU and disk burst points that each VM has. VMs constantly receive additional burst points corresponding to the baseline performance. They also constantly lose burst points based on actual resource utilization.

* CPU: 1 CPU burst point corresponds to 100% utilization of a core for five minutes. A VM receives 0.2 burst points every five minutes for each core on the VM.
* Disk I/O: 1 I/O burst point corresponds to 100 IOPS sustained over five minutes. A VM receives 1 burst point every five minutes.

For example, if a single-core VM starts with 10 burst points, and then uses 20% of the CPU core for one hour, it will end with 10 burst points. On the other hand, if the VM uses 10% of a core for one hour, it ends with 11.2 burst points (an additional 0.1 points for each five-minute interval), and if it uses 30% of a core for one hour, it ends with 8.8 burst points.

'''Throttling.''' VM resource utilization may be throttled to the baseline performance if it has zero burst points. In some cases, the platform will not throttle the VM, or will throttle it to a level above the baseline performance, if it determines that the system can handle the additional load from the VM.

'''Maximum points.''' There are upper limits on the number of burst points that a VM can accumulate. Once it reaches the limit, the VM burst points will stop increasing:

* CPU: 24 CPU burst points * number of cores (e.g. max of 48 points for a VM with two cores)
* I/O: 60 I/O burst points

== Paying for CPU Performance above the Baseline ==

To avoid CPU throttling, you can opt to pay for CPU performance above the baseline 20%/core performance from the CPU tab.

Pricing is $0.0037 per CPU burst point. If your VM runs out of burst points, instead of throttling the VM, the platform will grant the VM one burst point while assessing the charge to your account.

For example, suppose that you use 50% of each core on a two-core VM over 30 days. Your VM will need an additional 0.3 burst points per core for every five-minute interval in the month, on top of the 0.2 per core that is automatically granted every five minutes. Thus, the VM will use a total of 5184 additional CPU burst points over the 30-day interval, which is equivalent to a $19.18 charge.

== History ==

Before 3 January 2018, we simply had a "fair share usage policy" that stated that CPU and disk I/O are shared, and excessive utilization may result in service suspension. In practice, we would send an e-mail when excessive utilization was detected, and coordinate with the user to either reduce the usage to an acceptable level or upgrade to a larger instance.

We have since deployed an automatic management system that makes this policy much more concrete.

Burstable Resources

2018-01-04T15:57:02Z

Favyen Bastani:

Burstable Resources

2018-01-04T15:56:47Z

Favyen Bastani:

Burstable Resources

2018-01-04T15:56:13Z

Favyen Bastani: /* Burst Points System */

Burstable Resources

2018-01-04T15:54:22Z

Favyen Bastani: /* Burst Points System */

Burstable Resources

2018-01-04T15:53:57Z

Favyen Bastani: /* Burst Points System */

Burstable Resources

2018-01-04T15:53:16Z

Favyen Bastani:

Burstable Resources

2018-01-04T15:52:42Z

Favyen Bastani: /* Burst Points System */

Burstable Resources

2018-01-04T15:45:30Z

Favyen Bastani: Created page with "In order to maximize affordability and flexibility, Luna Node virtual machines are assigned a portion of available CPU resources and disk I/O rather than specific dedicated CP..."

Main Page

2018-01-04T15:24:49Z

Favyen Bastani: /* Functionality */

Welcome to the [https://lunanode.com/ Luna Node] wiki! You may have been looking for our main [https://dynamic.lunanode.com/info.php Luna Node Dynamic] website.

== Getting started ==
* [https://dynamic.lunanode.com/info.php General information]
* [[Create your first instance]]
* [[Billing]]
* [http://status.lunanode.com/ Network/power status]
* [[Frequently asked questions]]

== Functionality ==

See these pages for details on how to use the core cloud features:

* [[Snapshots]]
* [[Security groups]]
* [[Volumes]]
* [[Startup scripts]]
* [[Floating IP addresses]]
* [[Virtual networks]]

We also have various miscellaneous features and information:

* [[Server monitoring]]
* [[DNS]]
* [[API]]
* [[Managed Support]]
* [[Flexible plans]]
* [[Hardware specifications]]
* [[Application Templates]]
* [[Shelving]]
* [[Rescue Mode]]
* [[Burstable Resources]]

== How To ==

* [[ISO Installation]]
* [[Panel authentication|Control panel authentication]]
* [[Reselling]]
* [[Network configuration]]
* [[Volume-backed instance]]

Below are short pages with miscellaneous information.

* [[Increase network throughput]]
* [[Receive encrypted mail]]

Panel authentication

2017-12-06T03:00:32Z

Favyen Bastani: /* Linux */

Luna Node Dynamic supports three panel authentication methods: password, client-side certificate, and two-factor authentication.

* '''Password''': this is your standard login functionality, where you enter your e-mail address and password, and then get access to the panel.
* '''Client-side certificate''': this uses client-side SSL certificates that are signed by the Luna Node Dynamic certificate authority. You register the certificate and your key into your computer, and then the server will be able to authenticate your certificate via SSL.
* '''Two-factor authentication''': verify with a two-factor authentication method. Available methods include e-mail to the account e-mail address, SMS to a specified phone number, and time-based one-time password (TOTP).

== Authentication policies ==

There are several available authentication policies to determine how strict the server will be with logins for your account. These are configurable from the [https://dynamic.lunanode.com/panel/account Account] page in the top right of the panel, under the "Policies" tab.

* '''Password or certificate''': if you enter your password successfully or client-side SSL certificate authentication succeeds, you will have access to the panel.
* '''Password and certificate''': you will need to enter your password, and then also authenticate via SSL certificate in order to gain access.
* '''Password and two-factor authentication''': you will need to enter your password, and then complete two-factor authentication.
* '''Password, and either certificate or two-factor authentication''': after entering your password, you can choose whether to authenticate with a certificate or with two-factor authentication.
* '''Certificate, also password for new devices''': use client-side SSL certificate authentication only by default; however, if you attempt to login from an unrecognized IP address (i.e., one that you've not logged in from before), then you will need to also verify your password.
* '''Password, also two-factor authentication for new devices''': like above, but with password by default and two-factor authentication for unrecognized IP addresses.
* '''Password and certificate, also two-factor authentication for new devices''': you will always need to authenticate with both your password and a certificate; for unrecognized IP addresses, you will additionally need to pass two-factor authentication.

If you choose an authentication policy that involves two-factor authentication, be sure to configure two-factor authentication from the [https://dynamic.lunanode.com/panel/account Account] page under the "Two-factor authentication" tab.

== Setting up client-side SSL certificate ==

Once your certificate is set up, you will be able to login via https://dynamic.lunanode.com/secure/ (or select "Authenticate with client-side certificate" on login screen).

You have two options when setting up a certificate: using your modern browser (won't work with Internet Explorer; Firefox/Chrome both work fine) via the keygen tag, or manually generating and submitting a CSR. The first way is much easier, it should only take you sixty seconds!

Note: we recommend that you set up a master password in your browser if you do not have one already, this will ensure your certificates (as well as any saved passwords) are stored encrypted.

=== Generate certificate via browser ===

Make sure you are using Firefox or Chrome, or a similar non-IE modern browser that supports the keygen tag.

Head to the [https://dynamic.lunanode.com/panel/account?tab=account_auth_csc Account tab] and select Client-side certificates tab. Under "Add certificate via browser", configure any certificate key options that your browser provides, enter a number of days to sign for (between 5 and 730 days), and hit the generate option. Your browser should display a brief dialog about generating a keypair, and then after a bit more time you'll be prompted to add the certificate to your browser.

Once added, you can login via https://dynamic.lunanode.com/secure/.

=== Manually generate a CSR ===

If you decided you want to manually generate a CSR, follow the instructions below.

==== Linux ====

You will need OpenSSL or a similar tool installed in order to do this. These instructions are based on [https://gist.github.com/mtigas/952344 a gist by mtigas found on Github].

First, create a key and a CSR. We use 4096-bit key below for extra security since it doesn't hurt (and also since the guide used it). For the CSR, <b>the organization, organization unit, and common name must be set to your account e-mail address (case sensitive)</b> or else the CSR will be rejected.

<nowiki>openssl genrsa -des3 -out client.key 4096
openssl req -new -key client.key -out client.csr -subj "/O=you@example.com/OU=you@example.com/CN=you@example.com"</nowiki>

Now, copy the contents of client.csr. Go to the Account tab, and under "Client-side certificates", paste the CSR and hit "Add client-side certificate". This will cause the server to verify the CSR and then, if verification succeeds, sign it. If signed successfully, the newly produced certificate will be available. You should copy and paste this into client.crt in the same directory where you made client.key and client.csr. Once client.crt exists, run:

<nowiki>openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12
rm client.crt client.key client.csr</nowiki>

Finally, go to your web browser and import the certificate. In Firefox, this is available from Edit, then Preferences, then Advanced, then Certificates tab. Select "View certificates", go to "Your certificates" tab, and hit import, and then find client.p12.

==== Other operating systems ====

We currently don't have information for other operating systems. UNIX-based OS might work with the Linux instructions. If you get information, do let us know and we can add it here.

Alternatively, you can complete the steps to create client.p12 on any Linux machine, and then copy the resulting file to your machine that has some other OS, and import it to your browser.

API

2017-12-06T02:47:09Z

Favyen Bastani: /* Startup scripts */

The Luna Node Dynamic API enables you to write software to automate VM management. This page details how the API can be accessed. Visit the [https://dynamic.lunanode.com/panel/api API tab] to manage your API keys.

== Overview ==

Each API token consists of an API ID and an API key. Both are needed for authentication of all API commands.

API actions consist of a category label, action label, and a set of parameters. For example, to start a VM, the category label is "vm", action label is "start", and a "vm_id" parameter must be set. [[API#Action_list|See the full API action list.]]

API requests are made over HTTPS. Once the server completes processing of your request, it will return a JSON-encoded response.

== Usage ==

We provide open source (under MIT License) [https://github.com/LunaNode/lndynamic-api PHP and Python libraries] for accessing the Luna Node Dynamic API. These libraries make interaction with the API easier, handling transaction from category, action, and parameters to the HTTPS request, and from the JSON-encoded response to a PHP associative array or Python dictionary. [https://github.com/LunaNode/lndynamic-api Get the libraries here.]

Third party libraries are also available:

* Golang: a [https://github.com/LunaNode/lobster/tree/master/vmi/lunanode Golang client API] is available as part of the Lobster project.
* C#: [https://github.com/rickparrish/lndapi rickparrish/lndapi] is a C# API wrapper.
* PHP: [https://github.com/sdavis1902/lunanode-api-php sdavis1902/lunanode-api-php]
* Ruby: [https://github.com/nomoon/lunanode nomoon/lunanode] Ruby Gem

If you are using another programming language, you can view the API call [[API#Technical_details|technical details]] below. You may also find it easier to implement the [[API#Legacy_API|Legacy API]].

=== Examples ===

List your virtual machines:

<nowiki><?php

require_once('lndynamic.php');
$api_id = 'YOUR API ID';
$api_key = 'YOUR API KEY';
$api = new LNDynamic($api_id, $api_key);
print_r($api->request('vm', 'list'));

?></nowiki>

<nowiki>from lndynamic import LNDynamic
api_id = 'YOUR API ID'
api_key = 'YOUR API KEY'
api = LNDynamic(api_id, api_key)
print api.request('vm', 'list')</nowiki>

Recreate a VM with the same IP:

<nowiki><?php

require_once('lndynamic.php');
$api_id = 'YOUR API ID';
$api_key = 'YOUR API KEY';
$target_vm_name = 'myvm';
$target_image_name = 'Ubuntu 14.04 64-bit (template)';
$api = new LNDynamic($api_id, $api_key);

// find the target virtual machine ID
$vms = $api->request('vm', 'list');
$target_vm_id = false;

foreach($vms['vms'] as $vm) {
if(strcasecmp($vm['name'], $target_vm_name) === 0) {
$target_vm_id = $vm['vm_id'];
break;
}
}

//find the target image ID
$images = $api->request('image', 'list');
$target_image_id = false;

foreach($images['images'] as $image) {
if(strcasecmp($image['name'], $target_image_name) === 0) {
$target_image_id = $image['image_id'];
break;
}
}

if($target_vm_id === false) {
die('No VM found!');
}

if($target_image_id === false) {
die('No image found!');
}

// disassociate the IP address
$info = $api->request('vm', 'info', array('vm_id' => $target_vm_id));
if(empty($info['info']['ip'])) {
die('VM does not have IP!');
}
$api->request('vm', 'floatingip-delete', array('vm_id' => $target_vm_id, 'keep' => 'yes'));
$api->request('vm', 'delete', array('vm_id' => $target_vm_id));
$api->request('vm', 'create', array('hostname' => $info['info']['hostname'], 'plan_id' => $info['extra']['plan_id'], 'image_id' => $target_image_id, 'ip' => $info['info']['ip']));

?></nowiki>

=== Technical details ===

A request can be made given an API ID, API key, category, action, and parameters. The steps are described below. See the code of [https://github.com/LunaNode/lndynamic-api provided API libraries] for more details.

* Create request array by taking parameters and adding "api_id" => API ID and "api_partialkey" => first 64 characters of API key.
* JSON-encode the request array to get a '''raw request message'''.
* The '''nonce''' is the current UTC time in seconds since epoch (in PHP, <code>$nonce = time();</code>).
* The handler path is "{category}/{action}/"
* The target URL is https://dynamic.lunanode.com/api/{handler_path}
* Calculate the signature as SHA512-HMAC("{handler path}|{raw request message}|{nonce}"), using the API key as the HMAC key; here, we are signing the string formed from concatenating handler path, raw request message, and nonce delimited by pipe (|) characters
* Submit POST request to target URL with these form keys:
** '''req''': the raw request message
** '''signature''': the hex-digest output of the SHA512-HMAC
** '''nonce''': the nonce value
* The server's response will be a JSON-encoded associative array.

=== Legacy API ===

The legacy API uses simple GET and POST requests for each API action. All API actions are submitted via https://dynamic.lunanode.com/api

For example, to get the info for a virtual machine with hostname "hostname.example.tld", you can use the following API actions (find the ID for the hostname, then get the info from the ID):

<nowiki>https://dynamic.lunanode.com/api?api_id=YOUR_API_ID&api_key=YOUR_API_KEY&category=vm&action=list
https://dynamic.lunanode.com/api?api_id=YOUR_API_ID&api_key=YOUR_API_KEY&category=vm&action=info&vm_id=FOUND_VM_ID</nowiki>

The legacy API isn't necessarily less secure than the newer API, as either way all API actions are encrypted under HTTPS; however, the new API does offer greater protection against timing attacks and hides the API key even if an attacker were able to successfully forge an SSL certificate. So, we encourage usage of the new API where it is not inconvenient, but we plan to maintain the legacy API indefinitely.

== Action list ==

This list serves as a reference for available API actions. See [[API Detail]] for additional details for some API operations.

=== Virtual machine ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|vm
|start
|vm_id
|None
|-
|vm
|stop
|vm_id
|None
|-
|vm
|reboot
|vm_id
|None
|-
|vm
|diskswap
|vm_id
|None
|-
|vm
|info
|vm_id
|None
|-
|vm
|delete
|vm_id
|None
|-
|vm
|reimage
|vm_id, image_id
|None
|-
|vm
|resize
|vm_id, plan_id
|None
|-
|vm
|rescue
|vm_id
|None
|-
|vm
|vnc
|vm_id
|None
|-
|vm
|floatingip-add
|vm_id
|ip (string unattached floating IP address on your account), private_ip (string internal IP on VM)
|-
|vm
|floatingip-delete
|vm_id
|ip (string floating IP attached to VM), keep ('yes' to keep floating IP on account; default 'no')
|-
|vm
|iplist
|vm_id
|None
|-
|vm
|ip-add
|vm_id
|ip (string unallocated IP in virtual network)
|-
|vm
|ip-delete
|vm_id, ip
|None
|-
|vm
|securitygroup-add
|vm_id, group_id
|None
|-
|vm
|securitygroup-remove
|vm_id, group_id
|None
|-
|vm
|create
|hostname, plan_id, image_id
|region (default 'toronto'), ip (a floating IP on your account), net_id, securitygroups, scripts, volume_id, volume_virtio, key_id, set_password, affinity_group
|-
|vm
|snapshot
|vm_id, name (e.g. 'mysnapshot')
|None
|-
|vm
|list
|None
|None
|-
|vm
|shelve
|vm_id
|None
|-
|vm
|unshelve
|vm_id
|None
|-
|vm
|rename
|vm_id, hostname
|None
|}

Note: for create command, net_id is a network ID number, securitygroups is a comma-separated list of security group ID numbers, scripts is a comma-separated list of script ID numbers, volume_id is the ID number of an unattached volume that the new VM should be booted from (if volume_id is set, image_id is not required), and affinity_group is an affinity group UUID. Also, if volume_id is set, then the driver is ide if volume_virtio is not set, or virtio of volume_virtio is set (value of volume_virtio is ignored). Finally, key_id is an [https://dynamic.lunanode.com/panel/key SSH keypair ID], and set_password can be set if you want the system to add a startup script to set a randomly generated password (this is ignored if key_id is set; also, the system will set password by default for official templates).

=== DNS ===

API calls relating to DNS are listed below (see next section for Legacy DNS).

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|dns2
|zone-list
|None
|None
|-
|dns2
|zone-add
|name (e.g. 'example.com'), ttl
|None
|-
|dns2
|zone-remove
|zone_id
|None
|-
|dns2
|record-list
|zone_id
|None
|-
|dns2
|record-add
|zone_id, name, data, ttl, type
|policy, weight, region, regiongroup, country, continent, global, latitude, longitude, aux, monitor_id, orig_record_id
|-
|dns2
|record-remove
|zone_id, record_id
|None
|}

Here are details for parameters to the '''record-add''' action:

* '''name''': e.g. 'blah' or 'blah.example.com.' for 'blah.example.com.'
* '''data''': the record contents, e.g. '1.2.3.4' for an A record or 'other.example.org.' for a CNAME/MX record
* '''ttl''': time-to-live, e.g. 3600
* '''type''': one of 'A', 'AAAA', 'CNAME', 'ALIAS', 'MX', 'NS', 'TXT', 'SPF', 'SRV'
* '''policy (optional)''': geo-targeting policy, 'none' for no geo-targeting, 'latlong' to route to record with closest latitude/longitude to the user's location, and 'region' for hierarchical region-based routing
* '''weight (optional)''': the record weight (this is used for load balancing or non-round-robin DNS failover)
* '''region, regiongroup, country, continent, global (optional)''': parameters for hierarchical region-based routing, see the UI for details (set global to 'no' to disable for global group)
* '''latitude, longitude (optional)''': latitude/longitude for 'latlong' policy
* '''aux (optional)''': priority for certain record types, such as MX and SRV
* '''monitor_id (optional)''': the ID of a monitor check (see monitor.check-list action), this record will be disabled if the check fails
* '''orig_record_id (optional)''': update an existing record with the specified ID instead of creating a new record

=== Legacy DNS ===

API calls relating to Legacy DNS are listed below. Valid DNS record types are 'A', 'AAAA', 'CNAME', 'HINFO', 'MX', 'NAPTR', 'NS', 'PTR', 'RP', 'SRV', and 'TXT'.

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|dns
|list
|None
|None
|-
|dns
|set
|ip, hostname
|None
|-
|dns
|zone-list
|None
|None
|-
|dns
|zone-add
|origin (e.g., 'example.tld.')
|ttl
|-
|dns
|zone-remove
|zone_id
|None
|-
|dns
|record-list
|zone_id
|None
|-
|dns
|record-add
|zone_id, name (e.g., 'www'), data (e.g., '1.2.3.4'), ttl, type
|None
|-
|dns
|record-remove
|record_id
|None
|-
|dns
|dyn-list
|None
|None
|-
|dns
|dyn-add
|name, ip
|None
|-
|dns
|dyn-update
|dyn_id, name, ip
|None
|-
|dns
|dyn-remove
|dyn_id
|None
|}

=== Image ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|image
|list
|None
|region (will show images across all regions by default)
|-
|image
|delete
|image_id
|None
|-
|image
|details
|image_id
|None
|-
|image
|replicate
|image_id, region
|None
|-
|image
|fetch
|region, name, location, format ('iso' or 'qcow2')
|virtio
|-
|image
|retrieve
|image_id
|None
|-
|image
|rename
|image_id, name
|None
|}

image.fetch fetches an image from an external source. image.retrieve sends the contents of an existing image as the response body.

=== Volume ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|volume
|list
|region
|None
|-
|volume
|create
|region, label (e.g. 'myvolume'), size (in GB)
|image, snapshot_id
|-
|volume
|delete
|region, volume_id
|None
|-
|volume
|attach
|region, volume_id, vm_id, target (e.g. 'auto' or '/dev/vdc')
|None
|-
|volume
|detach
|region, volume_id
|None
|-
|volume
|info
|region, volume_id
|None
|-
|volume
|extend
|region, volume_id, size (in GB)
|None
|-
|volume
|snapshot-create
|region, volume_id, label
|None
|-
|volume
|snapshot-delete
|region, snapshot_id
|None
|-
|volume
|snapshot-list
|region
|None
|-
|volume
|snapshot-replicate
|region, snapshot_id, image_name (e.g. 'myimage'), dst_region (e.g. 'toronto')
|None
|-
|volume
|rename
|volume_id, name
|None
|}

For volume creation, if image parameter (which should be an image ID) and snapshot_id parameter are not set, then an empty volume will be created. If both are set, an error will be returned.

=== Floating IP ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|floating
|list
|None
|None
|-
|floating
|add
|region
|None
|-
|floating
|delete
|region, ip
|None
|}

=== Virtual Network ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|network
|list
|None
|region
|-
|network
|create
|region, name, subnet (e.g. '192.168.30' for 192.168.30.0/24), dns (e.g. '8.8.8.8,8.8.4.4')
|None
|-
|network
|delete
|region, net_id
|None
|}

=== Load Balancer ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|lb
|list
|region
|net_id
|-
|lb
|create
|region, net_id, name, method ('ROUND_ROBIN', 'LEAST_CONNECTIONS', or 'SOURCE_IP'), protocol ('HTTP', 'HTTPS', or 'TCP'), connection_limit (-1 for unlimited), port
|None
|-
|lb
|delete
|region, lb_id
|None
|-
|lb
|info
|region, lb_id
|None
|-
|lb
|member_add
|region, lb_id, ip, port
|None
|-
|lb
|member_remove
|region, lb_id, member_id (see lb/info output)
|None
|-
|lb
|associate
|region, lb_id, ip
|None
|}

=== Plan and region ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|plan
|list
|None
|None
|-
|region
|list
|None
|None
|}

=== Server monitoring ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|monitor
|check-list
|None
|None
|-
|monitor
|check-types
|None
|None
|-
|monitor
|check-add
|name, type, fail_count, success_count, check_interval, (also any parameters needed from check-types)
|None
|-
|monitor
|check-remove
|check_id
|None
|-
|monitor
|contact-list
|None
|None
|-
|monitor
|contact-add
|None
|None
|-
|monitor
|contact-remove
|type ('email', 'sms_twilio', or 'http'), rel (e-mail address, phone number, or URL)
|None
|-
|monitor
|alert-list
|check_id
|None
|-
|monitor
|alert-add
|check_id, contact_id
|None
|-
|monitor
|alert-remove
|alert_id
|None
|}

=== Security groups ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|securitygroup
|list
|None
|None
|-
|securitygroup
|create
|region, name
|None
|-
|securitygroup
|delete
|region, group_id
|None
|-
|securitygroup
|rename
|region, group_id, name
|None
|-
|securitygroup
|rule-list
|region, group_id
|None
|-
|securitygroup
|rule-insert
|region, group_id, direction ('ingress' or 'egress'), type (4 or 6), protocol ('*', 'tcp', 'udp', or 'icmp'), remote_type ('cidr' or 'group'), remote_value (CIDR or group ID)
|port_min, port_max, label
|-
|securitygroup
|rule-delete
|region, group_id, rule_id
|None
|}

=== Startup scripts ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|script
|list
|None
|None
|-
|script
|get
|script_id
|None
|-
|script
|create
|name, content
|None
|-
|script
|update
|script_id, name, content
|None
|-
|script
|delete
|script_id
|None
|}

=== Billing ===

You can check your credit balance from the API.

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|billing
|credit
|None
|None
|}

=== E-mail ===

{| class="wikitable"
! Category
! Action
! Required parameters
! Optional parameters
|-
|email
|usage
|None
|None
|-
|email
|domain-list
|None
|None
|-
|email
|domain-add
|name
|None
|-
|email
|domain-remove
|domain_id
|None
|-
|email
|domain-dkim-set
|domain_id, selector, private_key
|None
|-
|email
|domain-dkim-unset
|domain_id
|None
|-
|email
|user-list
|domain_id
|None
|-
|email
|user-add
|domain_id, username, password
|None
|-
|email
|user-set-password
|domain_id, user_id, password
|None
|-
|email
|user-remove
|domain_id, user_id
|None
|-
|email
|alias-list
|domain_id
|None
|-
|email
|alias-add
|domain_id, name, target
|None
|-
|email
|alias-remove
|domain_id, alias_id
|None
|}

Server monitoring

2017-11-21T16:42:27Z

Favyen Bastani: /* Monitoring locations */

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)
* 165.227.88.20 / 2604:a880:400:d0::926:f001 (New York)

Server monitoring

2017-11-21T16:42:22Z

Favyen Bastani: /* Monitoring locations */

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)
* 165.227.88.20 / 2604:a880:400:d0::926:f001 (New York)

Note: struck through monitoring servers will be disabled on 20 November 2017.

Server monitoring

2017-11-16T19:11:09Z

Favyen Bastani: /* Monitoring locations */

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* <s>192.184.93.183 / 2604:180:1::53b2:98d7 (Seattle)</s>
* <s>107.191.108.175 / 2604:180:2::3860:73c0 (New York)</s>
* <s>108.61.211.102 / 2001:19f0:6c00:8162:5054:ff:fe4f:c32a (Germany)</s>
* <s>5.135.236.84 / 2001:41d0:a:6e42::3 (France)</s>
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)
* 165.227.88.20 / 2604:a880:400:d0::926:f001 (New York)

Note: struck through monitoring servers will be disabled on 20 November 2017.

Server monitoring

2017-11-02T21:20:37Z

Favyen Bastani: /* Monitoring locations */

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* <s>192.184.93.183 / 2604:180:1::53b2:98d7 (Seattle)</s>
* <s>107.191.108.175 / 2604:180:2::3860:73c0 (New York)</s>
* <s>108.61.211.102 / 2001:19f0:6c00:8162:5054:ff:fe4f:c32a (Germany)</s>
* <s>5.135.236.84 / 2001:41d0:a:6e42::3 (France)</s>
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)
* 165.227.88.20 / 2604:a880:400:d0::926:f001 (New York)

Note: struck through monitoring servers will be disabled on 9 November 2017.

Server monitoring

2017-11-02T21:20:05Z

Favyen Bastani: /* Monitoring locations */

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* <s>192.184.93.183 / 2604:180:1::53b2:98d7 (Seattle)</s>
* <s>107.191.108.175 / 2604:180:2::3860:73c0 (New York)</s>
* <s>108.61.211.102 / 2001:19f0:6c00:8162:5054:ff:fe4f:c32a (Germany)</s>
* <s>5.135.236.84 / 2001:41d0:a:6e42::3 (France)</s>
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)
* 165.227.88.20 / 2604:a880:400:d0::926:f001 (New York)

Server monitoring

2017-11-02T21:18:56Z

Favyen Bastani:

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* <s>192.184.93.183 / 2604:180:1::53b2:98d7 (Seattle)</s>
* <s>107.191.108.175 / 2604:180:2::3860:73c0 (New York)</s>
* <s>108.61.211.102 / 2001:19f0:6c00:8162:5054:ff:fe4f:c32a (Germany)</s>
* <s>5.135.236.84 / 2001:41d0:a:6e42::3 (France)</s>
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)

Server monitoring

2017-11-02T20:00:31Z

Favyen Bastani: /* Monitoring locations */

Luna Node Dynamic includes [https://dynamic.lunanode.com/panel/monitor server uptime monitoring]. From the panel, you can create various types of checks including HTTP OK, SSL expiration, and ICMP ping. Then, create contacts through e-mail, web hook, SMS, or phone call (note that SMS/voice notifications are charged at the [https://www.twilio.com/sms/pricing/us#outbound-pricing Twilio rate], rounded up to the nearest cent). And finally associate your checks with a subset of contacts.

Select [https://dynamic.lunanode.com/panel/monitor Monitoring] in the sidebar to manage your server monitoring.

== Checks ==

The following checks are supported. The instructions should be self-explanatory, open a ticket if you encounter issues.

* HTTP page contains substring (http_contains): GET the target URL, and ensure that the page contents includes a given string.
* HTTP status OK (http_ok): GET the target URL and confirm status code is 200 OK.
* HTTP status code check (http_status): GET the target URL and confirm status code matches the given expected value.
* SSL expiration check (ssl_expire): connect via SSL and ensure certificate isn't going to expire soon.
* Ping (ping): do three ICMP pings to target and confirm that we get at least one ping back.
* TCP connection test (tcp_connect): connect to given host and port with timeout.

== Contacts ==

You can add contacts with e-mail, web hook, SMS, or phone call.

For web hook contacts, enter the target URL, and the system will perform a POST request on the URL with the check details in the POST fields.

== Alerts ==

Alerts is simply an association between a check and a contact. These are created by selecting a check after you create some from the Checks list, and then selecting a contact from dropdown and hitting Associate button.

The web hook alert will perform a POST request on the configured URL with these parameters (which will be form encoded):

* check_id: the ID of the check whose status changed
* name: check name
* type: check type
* data: check parameters
* status: either "online" or "offline", depending on whether the check came up or went down
* message: a description of the reason for the status change

== Monitoring locations ==

Servers are monitored from these IP addresses:

* 172.81.176.99 / 2602:ffb6:2:0:f816:3eff:fe17:8ff7 (Toronto)
* {{strikethrough|192.184.93.183 / 2604:180:1::53b2:98d7 (Seattle)}}
* {{strikethrough|107.191.108.175 / 2604:180:2::3860:73c0 (New York)}}
* {{strikethrough|108.61.211.102 / 2001:19f0:6c00:8162:5054:ff:fe4f:c32a (Germany)}}
* {{strikethrough|5.135.236.84 / 2001:41d0:a:6e42::3 (France)}}
* 158.69.228.239 / 2607:5300:60:9bef::2 (Montreal)
* 178.33.60.64 / 2001:41d0:2:cb40::2 (Roubaix)

Frequently asked questions

2017-09-06T17:58:05Z

Favyen Bastani: /* I cannot login as root! */

=== Cannot connect with SSH to newly booted VM ===

The provisioning and booting process may take as long as five minutes in some cases, depending on the specific operating system you are selecting. You can monitor progress over VNC by hitting the VNC Connection button. Once booted, you will be able to authenticate via SSH using the username and password displayed on the virtual machine page (or SSH key if you specified one).

Note that if you selected an image marked "ISO" when provisioning the VM, you will have to install the operating system via VNC. If you simply want a ready-made VM up and running, you should select an image marked "template" instead.

=== I cannot ping my IP address 172.20.8.187 ===

The IP address starting with 172 is the private IP address for your VM. Go to your VM details page and look for the "external IP address".

=== How to purchase the Special XYZ plan? ===

First, check https://dynamic.lunanode.com/info to make sure it is still in stock. If so, you can [https://dynamic.lunanode.com/register register an account] and then go to the Create VM sidebar option to create the VM of your desired special plan. Note that special plans are only available for a limited time.

=== Do you support IPv6? ===

Yes! We support IPv6 in Toronto. Virtual machines are automatically assigned an IPv6 address via SLAAC. User-created virtual networks receive a /64 IPv6 allocation, and virtual machines created on such networks can use any address on the allocated subnet.

=== My account request was denied ===

We do not accept new account registrations from proxies, hosting services, or other non-residential/business IP addresses. Please contact support@lunanode.com if you do not know why your account request was denied.

=== How to resize my VM? ===

To resize your VM, select the VM and use the Resize utility.

Note that the resize will fail if you attempt to resize a local-storage-backed instance to a plan with a smaller disk size. Follow these steps to resize a VM down:

* Take a snapshot of the VM
* Once the snapshot is ready (you can monitor the progress from the Images tab), go to the Volumes tab and create a volume from the snapshot with the old snapshot size
* Boot a new VM with "Ubuntu 14.04 64-bit" template, and attach the volume to the VM
* Assuming that the volume is attached at /dev/vdc, run <tt>resize2fs /dev/vdc1 10G</tt> (replacing 10G with desired size in gigabytes; aim for as small a size as possible, so that the partition and disk will fit)
* Then, run fdisk /dev/vdc and re-create the partition; make sure the start sector is the same, and also make sure to set the bootable flag:

<nowiki># fdisk /dev/vdc

Command (m for help): p

Disk /dev/vdc: 37.6 GB, 37580963840 bytes
4 heads, 32 sectors/track, 573440 cylinders, total 73400320 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d8e94

Device Boot Start End Blocks Id System
/dev/vdc1 * 2048 73400319 36699136 83 Linux

Command (m for help): d 1
Selected partition 1

Command (m for help): n
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-73400319, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-73400319, default 73400319): 33556479

Command (m for help): a
Partition number (1-4): 1

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.</nowiki>

Above, to calculate the last sector, you can try multiplying the default last sector by the fraction that you're resizing down; e.g. if resizing from 35 GB to 15 GB, multiply (73400319 / 35 * 14) (we use 14 instead of just 15 since the partition table and other elements take up some space; do make sure that the filesystem has been resized to less than this many GB in the <tt>resize2fs</tt> command earlier).

* Create a new volume with the desired size, and attach it to the same VM
* Use <tt>fdisk /dev/vdd</tt> to create identical partitions on the new volume
* Use <tt>dd if=/dev/vdc1 of=/dev/vdd1 bs=64k</tt> to copy data from the partition on the old volume to the partition on the new volume
* Detach both volumes from the VM, and delete the volume with old size
* Select the volume with new size from the Volumes tab, and convert it to an image
* Boot the new VM from the image

=== Unable to attach volume to my Windows VM ===

Volumes are best used with Linux virtual machines using the virtio driver. If you are using another operating system or ide driver, then you likely will need to shut down the VM before attaching or detaching volumes. You may also need to specify the attachment target as /dev/hdc or /dev/hdd or etc.

=== What is the default username for virtual machines provisioned using the stock templates ===
The administrative username for template-based virtual machines are as the following:
*Ubuntu: ubuntu
*Debian: debian
*CentOS: cloud-user / centos
*Fedora: fedora
*CoreOS: core

=== I cannot login as root! ===

As stated in the "VM provisioned successfully" email, template-based virtual machines are configured to accept connections with the administrative user. The password is displayed on the virtual machine details page. For security reasons, the VM does not accept root login by default.

Once authenticated as the administrative user, you can execute <tt>sudo su</tt> to login as root.

If you wish, you can of course set a root password. First, login as root by authenticating with the administrative user and running <tt>sudo su</tt>. Then, run <tt>passwd</tt> to set a root user password. Finally, edit the SSH configuration:

<nowiki>sed -i 's/.*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
service ssh restart; service sshd restart
</nowiki>

Then logout and you should be able to authenicate via SSH directly as the root user with your newly set password.

Alternatively, you can use a [[Startup scripts|startup script]] so that the root password is set when the VM boots.

Note: use an SSH client like [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] to authenticate.

Please note that our services are unmanaged and you are responsible or the security of your VM; if your VM is taken over and used in denial of service attacks, spam, or other activities that violate our [https://dynamic.lunanode.com/terms terms of service], your account may be suspended depending on the circumstances.

=== Is additional bandwidth usage billed hourly? What about CPU usage for flexible plans? ===

Both bandwidth and CPU are billed as '''consumable resources''', i.e., you are charged for the amount that you use. For example, if you use 5 GB bandwidth, then you will be billed $0.003 for each GB, and it does not matter how long it takes you to use that 5 GB. Similarly, for CPU usage, if you use 10 CPU-core-hours (e.g. 5% of a CPU core for 200 hours, or 100% of a CPU core for 10 hours) then you will be billed $0.22, and again it doesn't matter what timespan you use it over.

So, the question of whether we bill "hourly" versus "monthly" doesn't make sense for flexible resources (including additional bandwidth on all plans, as well as bandwidth / CPU for flexible plans). For fixed resources (memory, disk size, etc.), though, we do bill hourly.

If you are still confused, this is probably because you are used to monthly providers that may charge for additional CPU core or additional 1 TB bandwidth for the next month. The reason that monthly providers do this is because they don't expect you to use the full allocation, and if you only use 500 GB additional bandwidth then they save 500 GB on their end. However, in our case, we charge for resources '''as they are being consumed''' instead of in advance, so hourly versus monthly no longer matters, and you only need to pay for what you use.

=== My disk space is smaller than the plan disk ===

Almost all of the templates will automatically resize the partition and filesystem the first time that the virtual machine boots. If you install from ISO, you can also choose the partitioning scheme.

So, if you are having this problem where filesystem doesn't actually get resized, it likely means you are using the CentOS 6 template, which does not support automatic filesystem resizing. You can instead run the following commands to manually resize the partition/filesystem:

<nowiki>
fdisk /dev/vda
> u
(this will switch units to sector; it is important that you use sectors and not cylinders!)
> p
(this will print all of the partitions, we will refer to the data later)
> d 1
(this will display "Selected partition 1" and delete the first partition)
> n
(select "p" for primary partition)
(partition number should be 1, but make sure it matches the number displayed in print command)
(first sector should be 2048, but make sure it matches the "Start" column displayed in print command)
(and set last sector to the default value)
> a
(type "1" to make new first partition bootable)
> w
(this will write the new partitions and exit fdisk)
shutdown -r 0
(connect to VM after it reboots, if it has resized partition but not filesystem then run resize2fs)
</nowiki>

Warning: when creating the new partition, make sure that the first sector matches the sector displayed in print command (typically 2048). The default option that fdisk will provide is incorrect.

=== The VNC connection doesn't work for me ===

This is usually caused by a firewall on your computer, router, or at your ISP; or because of outdated browser software. If you are using the noVNC client, first try switching to another browser and see if it works there.

If it still doesn't connect (e.g. you get "Connection Timeout" error), then you can try to use the VNC tunnel connection method so that you can use your own desktop VNC client instead of noVNC. To do this, go to the Account tab in the top right, scroll down to VNC Connection Method, and change to tunnel. Then, when you click the VNC button, you will be given VNC login details that you can plug into your desktop VNC client to connect to your virtual machine instance.

Note: you may have to subtract 5900 from the port provided by the tunnel in some cases. So for example, if the panel says to connect to 167.114.159.49:6105, and that doesn't work, then also try connecting to 167.114.159.49:205.

=== Can I shutdown my VMs to avoid being billed? ===

You can use the Shelve functionality to deactivate your virtual machine. Once a VM is shelved, you will only be billed for the storage space, at $0.03/GB/mo, and assigned IP addresses, at $1/mo (both fees are charged hourly); the pricing change will be reflected in the billing section of the panel dashboard. You can reactivate the VM at any time by pressing Unshelve from the VM details.

=== Why is my geo-location database showing the IP address in an incorrect location? ===

We set standard Referral Whois (RWhois) records that indicate the exact location of all IP addresses that we operate. If your geo-location database does not show the correct location for our IP addresses, that means that the database provider is not checking our RWhois records. You would need to direct questions regarding the inaccuracy of their database to them. Please do not contact us with any questions about IP geo-location as we do not maintain these databases.