When creating an instance, it is easy to misjudge what resources it will require. It is also often the case that after creating a VM, its intended uses will evolve, demanding a different amount of resources to before. This article considers your options for resizing a Nectar instance.

Before proceeding with any of these instructions you should make sure your instance and data are backed up. You can refer to the documentation for ways to do this:

Direct resize using Dashboard

In the dashboard, go to the Project -> Compute -> Instances tab. At the end of the row for your instance there is a drop down menu for choosing instance actions. Select Resize Instance:


That will open a dialog in which you can select a new flavor for the instance:

Although all possible flavors are listed, in fact some choices may be invalid and you will get an error if you choose them. There are two rules you need to remember when choosing a new flavor:

  1. The new flavor's Root Disk GB must be at least as big as that of the current flavor.
  2. The new flavor's Ephemeral Disk GB must be at least as big as that of the current flavor.

If either of these conditions are not satisfied, the resize will fail.

The following diagram shows which transitions are possible:

You can resize from the current flavor to any other flavor that can be reached by following a path of arrows. So, m2.tiny can be resized to any other flavor, since a path of arrows can be found from m2.tiny to any other flavor. On the other hand, m2.medium cannot be resized to m1.medium, or vice-versa, because no path of arrows exists from one to the other.

The flavors within each orange box are equivalent to each other, for the purposes of resizing. They might have very different numbers of CPUs and GB of memory, but they have the same Root Disk and Ephemeral Disk sizes.

So, any instance with a t3 flavor can be resized to any other t3 flavor, or to (and from) m2.xsmall. Likewise, all the c3, m3, and r3 flavors are interchangeable with each other, and also with m2.small and m2.medium (which are also resizeable to each other).

After you resize, you will be asked for confirmation, as shown in the following screenshot:

Remember to click the Confirm Resize/Migrate button in order to complete the process.

Direct resize using Command Line

You can also use the OpenStack command line tools to resize your instances. If you're not familiar with the OpenStack command line you can get started using our documentation at https://support.ehelp.edu.au/support/solutions/articles/6000075747-api

Use the following command to perform a resize:

nova resize --poll <instance> <new-flavor>

You can use either the instance name or instance ID for <instance>.

The same rules apply as for resizing through the dashboard; you may refer to the above diagram to seek valid entries for <new-flavor>.

Resizing from the command line also requires confirmation, like in the dashboard approach above. In fact, you can use the dashboard to confirm a resize that was started from the command line; conversely, you can use the command line to confirm a resize initiated from the dashboard.

To proceed with confirmation:

nova resize-confirm <instance>

On the other hand, if you have changed your mind, you can discard the resize and retain the instance in its current flavor like so:

nova resize-revert <instance>

An alternative approach

Resizing instances through the dashboard is simple enough and should hopefully cover most scenarios in which a resize is required. However, it might not be flexible enough for every possible scenario. In that case you can employ a similar method to migrating instances between availability zones, which is documented at https://support.ehelp.edu.au/support/solutions/articles/6000191165-migrating-instances-between-availability-zones

For simple scenarios, this is just a matter of snapshotting the instance and launching a new instance from the snapshot. However, various factors could make it more complicated. You should work through the migration guide and contact the Nectar helpdesk if you have any questions or concerns. (In particular, be careful with any data you have on Ephemeral Storage, since it will need to be backed up manually. Ephemeral storage is not captured in instance snapshots.)

If you do decide to employ this migration-like method for performing a resize, there are still some scenarios that we don't currently support. In particular, if you try to resize to a smaller flavor, it may simply prove to be impossible, and we do not offer it as an option we support.

Another point to note is that if you are only after more space on the VM, and don't specifically need more memory or processors, you should consider applying for volume storage. Please see our documentation for a survey of the available storage options and how to apply: https://support.ehelp.edu.au/support/solutions/articles/6000055382-introduction-to-cloud-storage

Possible problems/gotchas

Error: No valid host was found

Even if you choose a valid flavor to resize to, you might get an error that no valid host was found. This usually happens because your instance is in an Availability Zone where resources are near capacity, and none of the hosts (i.e. servers running instances) are currently able to accommodate an instance with the chosen flavor.

In this case, if you really need the resize to take place, you can contact the Nectar helpdesk, and it might be possible to move some other instances around to create some room for you. This requires agreement from the Node hosting your instance. It might simply be impossible to create the room you need.

Increasing Ephemeral Storage does not increase filesystem size

There is a known problem that when resizing an instance with Ephemeral Storage to a flavor with more Ephemeral Storage, the filesystem on the Ephemeral Storage device does not also resize.

To automate resizing the filesystem would greatly increase the complexity of resizing, with the risk of introducing bugs that will cause data loss. To avoid having an automated process cause data loss, it is up to users to manually resize the filesystem after increasing the size of the Ephemeral Storage device attached to their instance.

If you have just performed a resize and want to verify that you are affected by this problem, there are two commands you can use: lsblk and df -h.

The lsblk command will list the available storage devices, along with their size. After a resize, you should see that your Ephemeral Storage device has the correct size for the new flavor you chose.

The df -h command shows any filesystems currently mounted, along with their sizes. So long as your Ephemeral Storage is mounted, you will see that the filesystem is still the same the same size as before the resize.

If you want to take advantage of the full amount of Ephemeral Storage available in your instance, you will need to increase the filesystem size manually. We have existing documentation that covers the process required at https://support.ehelp.edu.au/support/solutions/articles/6000185794-increasing-a-volume-size

Although that documentation is intended for Volume Storage, the instructions about resizing filesystems can easily be adapted to work with Ephemeral Storage.

Resizing from flavor without ephemeral storage to flavor with ephemeral storage

If you start with an instance without ephemeral storage and resize it to a flavor that does have ephemeral storage, the instance won't be automatically configured to begin using the extra storage. In Linux, storage configuration is handled through the file /etc/fstab. It is unsurprising that an instance resize will not modify this (or any other) existing files.

To begin working with ephemeral storage (including modifying fstab) please see our documentation dealing with this topic:

Note that in any case, Ephemeral Storage is scheduled for deprecation. Our recommendation is to avoid Ephemeral Storage in favour of Volume Storage.