Skip to main content
IMHCloud Logo
Back to support home

Resizing OpenStack Instances: When and How

Compute

Introduction

Resizing an OpenStack instance (virtual machine) lets you change its resources by moving it to a different flavor. This gives you vertical scaling without rebuilding your entire server. You can increase CPU, RAM, and disk capacity to handle growing workloads, or decrease resources when your requirements change.

This guide walks you through planning a resize operation, understanding downtime implications, and using the confirm or revert options after the resize completes.

When to Resize an Instance

Resizing is the right choice when your application needs different resources but you want to keep the same instance, data, and configuration.

Common scenarios for resizing:

  • Your instance consistently runs out of memory under normal load
  • CPU usage is frequently maxed out, impacting performance
  • You provisioned too many resources and want to reduce costs
  • A seasonal workload requires temporarily higher capacity
  • You need to increase root disk space without attaching volumes

When resizing might not be the best option:

  • You need horizontal scaling (add more instances behind a load balancer instead)
  • Your instance requires specialized hardware not available in other flavors
  • You need zero downtime (resize operations stop the instance)
  • Storage growth can be handled with attached volumes instead

Understanding Flavors and Resize Limitations

A flavor defines the resource template for your instance: vCPUs, RAM, and root disk size. When you resize, you migrate to a different flavor.

Critical limitations to understand:

  • Root disk size cannot shrink. You can only resize to a flavor with equal or larger disk capacity. If your current flavor has 50GB and you try to resize to one with 30GB, the operation will fail.
  • Ephemeral disk constraints. If your flavor uses ephemeral storage, the resize behavior depends on your OpenStack configuration. Some clouds preserve ephemeral data, others wipe it.
  • Availability zones. Not all flavors are available in all zones. If you need a specific flavor, verify it is available in your instance's current zone before attempting the resize.
  • Stopped instances. Some OpenStack deployments only allow resizing stopped instances. Check your environment's requirements.

Planning Your Resize

Before initiating a resize, gather the necessary information and prepare your instance.

Pre-resize checklist:

  1. Identify the target flavor: Use openstack flavor list to see available options. Note the flavor ID or name you plan to resize to.
  2. Check resource requirements: Verify the new flavor meets your needs. Compare vCPUs, RAM, and root disk to your current configuration.
  3. Verify flavor availability: Confirm the target flavor is available in your instance's availability zone.
  4. Review disk constraints: Ensure the new root disk size is equal to or larger than your current size.
  5. Schedule downtime: Your instance will be stopped during the resize. Plan for application downtime and notify users if necessary.
  6. Back up critical data: Take a snapshot or backup before resizing, especially if you use ephemeral storage.

How to Resize an Instance in Horizon Dashboard

Resizing through the Horizon dashboard provides a visual interface for changing instance flavors. This method is ideal if you're less familiar with command-line tools.

Step 1: Navigate to Your Instance

  1. Log into the OpenStack Horizon dashboard
  2. Navigate to Project > Compute > Instances
  3. Locate the instance you want to resize in the instances list

Step 2: Initiate the Resize

  1. Click the dropdown arrow on the right side of the instance row
  2. Select Resize Instance from the actions menu
  3. In the resize dialog, you'll see:
  • Current flavor details (vCPUs, RAM, disk)
  • A dropdown list of available flavors
  1. Select your target flavor from the New Flavor dropdown
  2. Review the new resource allocation displayed
  3. Click Resize to start the operation
screenshot-of-resize-instance-modal.png

What happens during this step:

  • OpenStack stops your instance
  • Creates a snapshot of the current state
  • Migrates the instance to a new host with the target flavor resources
  • Starts the instance in a "verify resize" state

Step 3: Monitor the Resize Progress

  1. The instance status column will show Resize/Migrating
  2. The page refreshes automatically, or you can manually refresh
  3. Wait for the status to change to Verify Resize
  4. This indicates the migration is complete
verify-instance-just-resized.png

Expected downtime:

  • Small instances (less than 20GB disk): 2 to 10 minutes
  • Larger instances (50GB+ disk): 10 to 30 minutes
  • Very large instances (200GB+ disk): 30+ minutes

Step 4: Verify the Resize

  1. Once the status shows Verify Resize, connect to your instance
  2. Use the Console tab to access the instance, or SSH if you have network access
  3. Verify the new resources:
  • Check available RAM: free -h
  • Check vCPU count: nproc
  • Check disk space: df -h
  1. Test your application to ensure it functions correctly with the new resources

Step 5: Confirm or Revert the Resize

After testing, you must confirm or revert the resize.

To Confirm the Resize (if everything works correctly):

  1. Click the dropdown arrow for the instance
  2. Select Confirm Resize/Migrate
  3. The instance status returns to Active
  4. The resize is now permanent and cannot be reverted

To Revert the Resize (if you encounter issues):

  1. Click the dropdown arrow for the instance
  2. Select Revert Resize/Migrate
  3. OpenStack migrates the instance back to its original flavor
  4. The instance returns to Active status with the original resources

Important: Any data written or changes made while in Verify Resize status will be lost when you revert. Treat the verify phase as temporary until you confirm.

How to Resize an Instance Using OpenStack CLI

For users comfortable with command-line tools, the OpenStack CLI provides scriptable resize operations suitable for automation.

Step 1: List Available Flavors

First, identify the target flavor you want to resize to:

1openstack flavor list

This displays all available flavors with their specifications. Note the flavor name or ID you plan to use.

Step 2: Initiate the Resize

Start the resize operation with the target flavor:

1openstack server resize --flavor FLAVOR_NAME_OR_ID INSTANCE_NAME_OR_ID

Example:

1openstack server resize --flavor m1.large my-web-server

What happens during this step:

  • OpenStack stops your instance
  • Creates a snapshot of the current state
  • Migrates the instance to a new host with the target flavor resources
  • Starts the instance in a "verify resize" state

Step 3: Monitor the Resize Progress

Check the instance status to monitor progress:

1openstack server show INSTANCE_NAME_OR_ID -c status

The status will progress through these stages:

  • RESIZE - Migration in progress
  • VERIFY_RESIZE - Migration complete, ready for verification

Expected downtime:

  • Small instances (less than 20GB disk): 2 to 10 minutes
  • Larger instances (50GB+ disk): 10 to 30 minutes
  • Very large instances (200GB+ disk): 30+ minutes

Step 4: Verify the Resize

Once the status shows VERIFY_RESIZE, connect to your instance and test:

  1. Connect to the instance: SSH into your instance
  2. Check resource allocation:
1   free -h      # Verify RAM
2   nproc        # Check vCPUs
3   df -h        # Confirm disk space
  1. Test application functionality: Start your services and verify they operate normally
  2. Monitor performance: Check that the new resources meet your expectations

Step 5: Confirm the Resize

If the new flavor works as expected, confirm the resize to finalize the change:

1openstack server resize confirm INSTANCE_NAME_OR_ID

What happens:

  • The original instance data on the old host is deleted
  • The resize becomes permanent
  • The instance returns to ACTIVE status
  • You cannot revert after confirming

Step 6: Revert the Resize (Alternative)

If you encounter issues or the new flavor does not meet your needs, revert to the original flavor:

1openstack server resize revert INSTANCE_NAME_OR_ID

What happens:

  • OpenStack migrates the instance back to its original flavor and host
  • All changes made during the verify phase are discarded
  • The instance returns to its pre-resize state
  • Once complete, the status returns to ACTIVE

Important: Any data written or changes made while in VERIFY_RESIZE state will be lost when you revert. Treat the verify phase as temporary until you confirm.

Auto-Confirmation Timeout

Some OpenStack environments have an auto-confirm timer. If you do not confirm or revert within a set period (typically 24 hours), the system automatically confirms the resize.

To avoid unexpected confirmations:

  • Verify and confirm or revert as soon as testing is complete
  • Check your cloud provider's documentation for auto-confirm policies
  • Set a reminder if you need extended testing time

Common Resize Issues and Troubleshooting

Issue: Resize fails immediately

  • Cause: Target flavor has smaller root disk than current flavor
  • Solution: Choose a flavor with equal or larger root disk size

Issue: Instance does not start after resize

  • Cause: Application misconfiguration or incompatibility with new resources
  • Solution: Revert the resize and investigate application requirements before trying again

Issue: Resize stuck in "RESIZE" status

  • Cause: Network issues, host capacity limits, or cloud infrastructure problems
  • Solution: Contact your cloud provider support to investigate

Issue: Performance worse after resize

  • Cause: New flavor may use different CPU architecture or have shared resources
  • Solution: Review flavor specifications and test with different flavor options

Best Practices for Resizing Instances

  • Test in staging first: If possible, resize a staging or development instance before production to identify potential issues.
  • Monitor resource usage before resizing: Use monitoring tools to confirm you actually need more (or fewer) resources.
  • Use maintenance windows: Schedule resizes during low-traffic periods to minimize user impact.
  • Document your flavor choices: Keep records of why you chose specific flavors to inform future decisions.
  • Consider horizontal scaling: For web applications, adding more instances behind a load balancer often provides better performance and availability than vertical scaling.

Summary

Resizing OpenStack instances provides flexible vertical scaling to match your changing resource needs. The process involves stopping the instance, migrating it to a new flavor, verifying the change, and then confirming or reverting the resize.

Key points to remember:

  • Plan for downtime during the resize operation
  • Verify the new flavor meets disk size requirements
  • Test thoroughly in VERIFY_RESIZE state before confirming
  • Always have a backup before resizing critical instances
  • Understand that confirming makes the change permanent

If you encounter issues during a resize operation or need help choosing the right flavor for your workload, contact InMotion Cloud support for assistance.