Migrate Between Server Flavors

Scaling Your Server

If you outgrow your server and need additional resources, the recommended approach is to scale horizontally by cloning your servers and placing them behind a load balancer. In most cases, horizontal scaling offers advantages over vertical scaling because your existing servers remain online and continue serving traffic while new instances are added. By contrast, vertical scaling typically requires taking a server offline while resizing it to a larger flavor.

However, horizontal scaling may not be suitable for every workload, or you may prefer not to use it.

Standard and General Purpose servers use local disks as their default boot device. As a result, moving to a flavor that boots from a block storage volume—such as Compute or Memory—can be less straightforward than a standard resize operation.

Limitations

Cloud images created from large servers don’t allow you to take an image and create a bootable Block Storage volume. If you took the image from a cloud server with a root disk, or if the image has a min_disk parameter larger than 127 GB, you can’t create a volume from that image. If you have a 4GB Standard, an 8GB General Purpose server, or anything larger, you fall into this category.

The problem is that the component used to attach images to cloud servers, qemu-img, can’t handle files 127 GB or larger. If you try to attach a too-large image through the API, you get an HTTP 412 invalid image error.

Moving to Another Flavor

If your Standard or General Purpose server is small enough, you should be able to take an image of your server and create a bootable volume that you can use to boot Compute or Memory flavor servers. To learn more, see Boot a server from a Cloud Block Storage volume.

However, if your server falls under the category listed in the preceding Limitations section, you need to perform a manual cloud-to-cloud migration of the server's data to move to the other flavor. To learn more, see Cloud-to-cloud migration.