Resize
======

As your requirements grow, you can resize your slices at any time to handle the additional needs.
Things to keep in mind for resizes:

#. Taking a :doc:`snapshot <snapshots>` beforehand is *strongly recommended*.  This way, you have 
   an additional failsafe in case anything goes wrong.  

#. If the existing host does not have the capacity for the new size, it will need to migrate 
   the slice to a new host.  This will require some downtime as it will need to copy your disk 
   to the new host.  The amount of time required will vary; plan for about 1 minute for every 2GB 
   of disk used on your slice.  You can see how much disk is used with the ``df -h`` command. 

#. Any volumes must be detached from a slice prior to resize (you can re-attach them once complete).

CPU + RAM Only
  This type of resize does not grow your disk.  Thus, you can reverse it.  It is good for when you 
  need more processing power.  Since the billing is hourly, you can scale up a slice for awhile during 
  expected increased loads, and scale it back with only a reboot.

.. Tip::
   CPU+ RAM Only resizes can be reversed.

CPU + RAM + DISK
  This type of resize will grow CPU/RAM and also your Disk.  It cannot be reversed.  

.. Warning::
   Disk resizes are permanent; they cannot be reversed.

Once ready, select a plan and click :guilabel:`Resize`.  Your slice will be powered down and begin
the resize build.  The longest part of a resize is typically the ``prepare`` stage, which is when 
it copies your existing disk to a new host.  A progress bar is displayed throughout, to give an idea 
how long to completion.

For billing purposes, the new resized slice will get a new slice ID reflecting the new plan, while 
the previous slice ID will show as deleted under the previous plan.