Option to downgrade a server
The option to downgrade a server.
For example, if we no longer require 8 GB of ram we are able to downgrade back to 4 GB without having to delete and create a brand new server again.
For example, if we no longer require 8 GB of ram we are able to downgrade back to 4 GB without having to delete and create a brand new server again.
This discussion has been closed.
Comments
@DaveA - You could always allow shrinking as long as the free space is lower than the plan they want to downgrade to.
http://libguestfs.org/virt-resize.1.html
Why not use Virt resize for KVM, As your using KVM base VPS?
I'd be more than happy to pay the full amount and keep the original disk size if it meant I was able to downgrade at a later time. Or choose to upgrade it if I had no plans of downgrading.
But as for the feasibility, a similar provider also doing 'cloud' KVM servers - Binary Lane seem to support downgrading plans/diskspace so it seems very possible.
With these proposals in place, proper management and allocation of resources to avoid oversubscribing would not be possible unless a server is left with a considerable spare pool of resources to be used in such an event, which would obviously raise running costs, which ultimately will have to be passed on to customers.
Be wary of places that offer such a thing - they either aren't managing their resources cost-effectively, or they aren't serious about provision and oversubscribing protection!
For instance, the VM I have in Sydney is not allowed to upgrade, because the host it's sitting on is full. There is no oversubscribing, regardless of upgrade/downgrade. It's not a matter of a spare pool of resources. It's first come, first serve. If I want to get a bigger VM, there's nothing stopping me from redeploying an image to get a new host.
Edit:
As a sidenote, I am thankful beyond belief that there is no silly "predictive' resource management, and that every host is simply a hard limit. If some twat decided to do a huge upgrade on the host I'm on and threw out the performance/timings of my VM at sydney, I'd be fuming.
This is VM management done right. vultr is seriously amazing, and the way they manage resources is absolutely perfect.
In other words, they'd need to commit to more resources to be sure they wouldn't refuse new customers.
I get your point that the resources available are just as fluid as if you instead temporarily create a new instance, but in my opinion, the ability to create/kill instances on an hourly basis is a 'perk' and it would seriously mess with Vultrs resource stability if everyone created/killed instances regularly as part of their normal operations.
Fortunately, this wouldn't be practical, but increasing/decreasing a single instance would be - if we all ran scripts which automatically increased/decreased our resource allocations as required, then were would Vultrs provisioning be? They'd either have to overcompensste on resources, or accept that some upgrades/new users will be refused due to capacity issues.
I could see how it would be fair to allow a server to be downgraded if it was a more permanent move, but letting customers up/downgrade on an hourly basis, as a policy to manage costs would be disasterous for everyone else.
How about if (say) a downgrade dan only be performed when the host has been on the current plan at least a week, say?
[ Yes, I know this discussion is hypothetical if Vultr have no plans to ever add this option either-way ]
If moving instances between physical hosts isn't too resource intensive, I suppose that would be doable - though it would then mean you have more hosts to keep spare capacity on...
Still, it would keep me separate from the lower-class plebs :-) (or more likely, the higher class power-users away from me!)
At the moment, this just isn't technically feasible in any way that doesn't put customers data at risk.
Vultr allows snapshots (which is amazingly generous of them - and the reason we use Vultr over almost any other provider) but it's not uncommon for us to login to the console, dd an image via ssh to a backup server somewhere and destroy the machine. If we happen to need a machine back in the future then we just restore the image. This is critical on the large storage servers that Vultr offers. Nothing annoys me more than a customer coming back a week later saying they are ready to pay their bill and need their server back online.