VC2 Scaling down a VPS

I see in the control panel this comment: : Downgrading is currently not supported. Shrinking the hard disk is not possible without risking data loss.

I understand that disk size prevents changing to a lower plan. However, there are times (in fact I had one last week) in which I needed more CPU cores for a period of high use. I did not want to scale up to a higher plan because then I would be "stuck" at the higher plan (without the ability to scale down).

It would be nice if we could choose a higher plan without having the need to have the higher disk. That way, we could scale up (get the higher ram + cpu) and then scale down when needed. By keeping the disk the same size, the downgrade feature should work.

Perhaps I could have snap-shoted the lower disk-sized VPS, and then install that snap shot on a new instance of a higher VPS, but that new instance would not have the same IP address, which is something I need to keep somewhat stable.



  • Of course you can now get IP addresses linked to your account rather than your instance, so that would have sorted that problem, but still, those IP addresses come at a premium, and doing a snapshot up, then down, and restoring the new data would be a right old pain in the arse!

    So, I think you have a good idea there - if the only issue is the technical issue of disk size, then as you say, why not have an option to upgrade but leaving the disk as it is? (To save complications, it could be a checkbox and still be on the same tariff/cost as if you had changed disk size)
  • Jamie, thanks for your note. I hope they are able to pull off a feature like this.

    I envision the following when upgrading, with a option like the following: "do you want to keep your diskspace the same size? (this will allow you to scale back down to this tier if you want to later, but you will be limited to the disk at the lower level"

    Thus, the user can scale as large as the user wants, and then sale down to the original size at will.

    As it stands, Vultr does not have a good "scale on demand" feature like AWS and others. This is fine, so long as they don't want to compete in this space.

    I am not envisioning that this will be crazy automated, but will allow admins to scale up temporarily and then revert to their original plan. In my case, last week I would have grabbed a 16 core VPS for a few days so that my app would have run smooth in a presentation to lots of people who were using the CPU intensive app at the same time.
  • Thanks.

    Yeah, that sounds good to me.

    I don't know if the current scheme is considered a hook to keep people on a higher tariff, but like you said, instead of upgrading, you ended up not upgrading at all, and again, as you say, it won't be something people turn on and off for short periods, after all, a reboot is required!

    An even simpler solution, though (as a hackish short term measure) would be to simply allow a downgrade, chopping off the excess allocated disk space.

    Of course this would require loads of warnings that people need to know what they are doing, but - correct me if I'm wrong - assuming you don't adjust any of the partitioning structure, the new space will be entirely ignored anyway. (If you use GPT, the new disk will probably moan about no backup GPT on the last sector, and if that's fixed, then the primary and backup GPT headers will be recalculated, so best to run the temporary bigger disk without 'fixing' it.)

    Sorry, went off on a tangent there... TL;DR an increased size disk should be shrinkable if no modifications are made to the partitioning information.

    Still, I prefer your idea.. Less hacky, and probably safer!
  • I think this feature request will be ignored by the staff, given that there has been no comment on it... that is fine, Vultr needs to pick and choose their efforts.

    That being said, I was looking at the docs of their digital competitor, and it seems as though they too do not have easy scale down. They suggest a complex rsync to a lower sided VPS. (perhaps they have the feature now though). So perhaps it is more complex than I thought.

    I guess reserved IPs are the way to go here, along with some bouncing between different sized VPSs.
  • edited September 2017
    Well, scaling down would be difficult if you actually resized your partitons to fit the new disk, because the host has no clue what operating system / filesystem you use.

    If you don't fiddle with the partitioning information, then you should be ok, but this could be risky.. Some systems, for instance, may automatically reconfigure the partitions on discovering they are on a bigger disk..

    So, whilst it's possible, there are possible 'gotchas' that mean it probably is easier from the support side of things to just say "not possible". I can understand that.

    HOWEVER, your suggestion - don't actually increases the disk size - would work fine, and would be the most ideal method anyway for when you temporarily want to beef up services, without having to arse around with disk configuring. There's no technical reason why that couldn't be implemented.
  • >>HOWEVER, your suggestion - don't actually increases the disk size - would work fine, and would be the most ideal method anyway for when you temporarily want to beef up services, without having to arse around with disk configuring. There's no technical reason why that couldn't be implemented.

    Agreed, but for now, my work flow will be the following:

    1. reserve ip of main VPS
    2. Take snapshot of main VPS at its stable size
    3. Upgrade main VPS to a powerhouse
    3a. Use big VPS for a few days.
    4. provision a new VPS from the smaller snapshot.
    5. When done, copy any modified files (database changes, new static files, etc) from big main vps to the newly created small VPS
    6. set reserved ip to point to the newly created small VPS
    7. destroy the big VPS.
    8. pull my hair out, have a few beers.
  • Yep, I can't see any other way under the current situation (though I would have hit point 8 much sooner!)

    You're still paying more for the reserved IP though :-(
  • Months already, and yet no official response from Vultr?
  • Years have come by, and it seems this thread is still hanging. Easy scale up and down, where are you?

This discussion has been closed.