Gauging interest in new feature.

[KuJoe]

Since we're expanding to a few locations I figured something like this might be interesting for those who want to move their VPS around. Thoughts?



I was thinking of putting some limitations on it like X number of migrations per day/week/month.

 

[Nett]

Interesting! So what would happen to DNS? Will you leave the previous VPS online for another 48 hours or...?

 

[sv01]

awesome, we still get same IP after migration? and how to know if another DC is available or full?

 

[KuJoe]

Interesting! So what would happen to DNS? Will you leave the previous VPS online for another 48 hours or...?

 
We don't manage DNS. This is up to the client to manage.

awesome, we still get same IP after migration? and how to know if another DC is available or full?

Nope, new IP since each location has different subnets. We have built in checks for that so if it's on the list it's available.

 

[splitice]

If it works well then that's great, its one of the features that makes providers like DigitalOcean so great.

Just be sure to test, test, test with different configurations (I've managed to break the one at DO a few times).

Certainly limit the migrations if the disk and network wear is a concern.

 

[peterw]

If your customers are hopping between the locations and are able to get new ips at every hop this feature will cause trouble.

 

[fisle]

Perhaps limit the option for old, long term customers to reduce abuse?

 

[KuJoe]

Here are the limitations I've come up with to prevent abuse (not set in stone):

• Limit 1 migration per day per VPS.
• Limit 3 free migrations per month per VPS.

If a client needs to migrate their VPS beyond the 3 free migrations per month, they can purchase an additional 3 migrations for $3 (still with the 1 migration per day limit).

And for those concerned about spamming using this method, we have a very low threshold that will automatically suspend a VPS that sends too many e-mails on all of our OpenVZ nodes (so low that spammers stop buying our OpenVZ VPSs now, which is really nice although we had to put a lot of restrictions on our KVM VPSs).

 

[tchen]

I think this makes sense considering your USP.  Beats bothering you all day with simple move requests.

 

[KuJoe]

I think this makes sense considering your USP.  Beats bothering you all day with simple move requests.

We figured this would be good for when we open a new location and we usually get a handful of requests to migrate to the new location. Recently though people haven't even been opening tickets, they just cancel one VPS and order a new one but since we don't offer refunds they end up losing money on the cancelled VPS so this way they don't need to spend anything extra to switch locations.

 

[willie]

Cool idea!

 

[D. Strout]

How long will the migration process take? I know it likely will depend on disk utilization, but can you give us any idea?

 

[Packety]

This look like a really good feature! Hope more Companies will consider this.

 

[DomainBop]

I was thinking of putting some limitations on it like X number of migrations per day/week/month.

KiwiVM (BandwagonHost/VPSBlast/iT7) has a self-migration feature.  They don't impose any limitations on the number of migrations or frequency of migrations but they do use Nodewatch (developed by them) for general abuse curbing on their nodes.

 

[raindog308]

This will really help me keep ahead of the feds when I'm on the run.

But seriously...

I assume the BW for the move comes out of the user's monthly allowance?

 

[KuJoe]

How long will the migration process take? I know it likely will depend on disk utilization, but can you give us any idea?

It's really based on how large the VPS is and the connection speed. We've been discussing throttling the network speed to prevent bandwidth overages since their is no throttling outside of the VPSs and some of our clients have 30+ VPSs that could make a dent in our 95% percent if they wanted to.

Additionally, migrations will be similar to how our self backups are done so there will be a queue that's worked via a cronjob so that will add some time depending on the size of the queue.

On average I'm estimating 15-30 minutes but this is just a guess without any actual testing. We'll know more this weekend.

KiwiVM (BandwagonHost/VPSBlast/iT7) has a self-migration feature.  They don't impose any limitations on the number of migrations or frequency of migrations but they do use Nodewatch (developed by them) for general abuse curbing on their nodes.

The abuse we're concerned about is bandwidth abuse. We don't have unmetered 1Gbps uplinks so for us we have to be cautious how much bandwidth we let clients use because the $2/month VPSs don't cover bandwidth overages. Right now we throttle VPS port speeds for most of our locations but a VPS migration is done outside of the VPS so they can rack up some overages if they freely migrated 10+ VPSs every chance they got.

This will really help me keep ahead of the feds when I'm on the run.

But seriously...

I assume the BW for the move comes out of the user's monthly allowance?

Originally we were going to eat the bandwidth costs but now that I'm looking over the size of some of our larger clients I may just take the size of the VPS's disk space and add it to the monthly bandwidth usage to impose a limit on how often clients with larger VPSs can migrate each month. The majority of our clients have less than 50GB of disk space (and the majority of them are only using less than 5GB of space) but we do have some clients who have much large drives (i.e. our backup clients) so I want to take that into account now instead of down the road when we add more backup servers.

 

[drmike]

I like the idea KuJoe.

Ideally you extend it to migrate from one server to another in your location too...

It happens, and I hate when it does that I end up on a busy node and sit there suffering.   Self-help to migrate to another server = great.

Downtime during the migration, right?

 

[KuJoe]

I like the idea KuJoe.

Ideally you extend it to migrate from one server to another in your location too...

It happens, and I hate when it does that I end up on a busy node and sit there suffering.   Self-help to migrate to another server = great.

Downtime during the migration, right?

The dropdown menu will list any available nodes including the nodes in the same location as your current one.

Migration will require a reboot of the VPS and the control panel will be locked out to prevent any changes during the migration but you can still SSH into the VPS during the migration.

 

[Everyday]

Very cool. Is this for all vps or just openvz?

 

[KuJoe]

Just OpenVZ, our control panel (Wyvern) is strictly OpenVZ only.