Option to downgrade a server in Features and Ideas

edited April 2014 in Features and Ideas
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.
«1

Comments

  • I would like this too. It's useful for if you're expecting a burst of traffic or something for a small amount of time.
  • Yes, but the disk size changes and we have no capability to shrink a volume at this time.
  • edited April 2014
    There really needs to be a "+1" button. lol

    @DaveA - You could always allow shrinking as long as the free space is lower than the plan they want to downgrade to.
  • edited May 2014
    @DaveA
    http://libguestfs.org/virt-resize.1.html
    Why not use Virt resize for KVM, As your using KVM base VPS?
  • Or simply buy resources you will may need, and upgrade or downgrade based upon your needs.
  • +1 or allow for upgrading of cpu/ram without resizing disk, to make a planned future downgrade easier.
  • +1 for CPU/RAM upgrade/downgrade and seperate HDD upgrade function.
  • edited June 2014
    An idea would be to have upgrade/downgrade where upon upgrading you can select to keep your disk size or increase it with the plan, but warned if you upgrade the diskspace with the plan you will not be able to downgrade, but if you choose to keep your diskspace you will be able to downgrade. Or something along those lines if that makes sense.

    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.
  • Upgrading is easy, downgrading is always hard. One viable option alternative is to add the extra space a second virtual hard drive on the server that can be removed if downgrade occurs. I don't know what logic they would need to implement that however in an automation platform but I am sure it could be done, possibly even to upsell a 'keep the disk space' on a downgrade later.
  • edited July 2014
    I think there is the business side to be considered. First one could upgrade just to temporarily increase the data transfer for a couple of bucks and then downgrade. Second the provider needs some predictability in the usage of the resources of a node and shouldn't simply increase and decrease VM resources without a corresponding slot available in that node (or the other nodes in the region) because increasing one resource usually impacts the usage of all other resources. I think the model in use is good and clients should plan better their requirements instead asking for pseudo-elastic solutions however implementing reserved IPs and load balancing is a must for that cases you need to recreate the VM due unexpected/unanticipated/unforeseen resources usage.
  • +1 Very important for traffic spikes.
  • edited August 2014
    I have to agree with 'Netpioneer' here.

    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!
  • edited October 2014
    If the server you are sitting on doesn't have the resources to perform an upgrade, you are NOT allowed to upgrade.

    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.
  • edited October 2014
    I realise they block upgrades if the server is full. I wasn't clear in my post. When I said "allocation of resources to avoid oversubscribing" I should have said "allocation of resources to avoid new services being blocked to avoid oversubscribing"

    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 ]
  • edited October 2014
    Some providers group instances types by server. Hypothetically you have a number of physical servers hosting only t1, others only t2, ...., others only tn. If a customer wants to upgrade/downgrade an instance to ti the provider just migrate it to a ti pool server. As added benefit this approach is (arguably) said to give power users some isolation from developers and newbies and helps to reduce DDoS surface improving the service for that customers paying the more expensive instances. Yeah it is a kind of first-class vs second-class netizen, but it works for some popular providers that have a lot of nodes. :-)
  • @Netpioneer Oooooh, I didn't think of that.

    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!)
  • I think it's been mentioned before, but the main issue here is that it's very difficult to shrink a servers disk, without the risk of data loss. Given that we allow users to upload their own operating systems, we have a wide variety of different partition layouts and formats.

    At the moment, this just isn't technically feasible in any way that doesn't put customers data at risk.
  • Good point actually. Without being able to predict the OS installed, it would be impossible - I could be using a home-brewed filesystem cooked up one stormy night in my basement...
  • Hi, maybe You should do it in diffrent way, by giving the same disk size in all standard plans, like 25GB and additional option to upgrade it (and then lost possibility to downgrade)?
  • I wanted to note that a good admin does not need Vultr to impliment disk resizing as long as you have console access. We just login via the console and dd the image over ssh to a workstation someplace, mount the server image as a loop device, resize the partition as needed (smaller than the target), deploy a new machine via the console, login in recovery mode from the console and dd the image back to the machine via ssh.

    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.
  • "This is critical on the large storage servers that Vultr offers. ". ---- for clarification.. This is critical because Vultr does not allow backups or snapshots of a " large storage" instance.
Sign In or Register to comment.