Your service xxxxx is scheduled for an IP address change on 6:30PM PDT on 05/08/26 .
Current IP: xxx.xxx.xxx.xxx
Your new IP: xxx.xxx.xxx.xxx
The new IP should be available to use on 7:00PM PDT on 05/08/26 and the old IP will be removed 6:00PM PDT on 05/08/26
So, does that mean it will be offline for up to an hour?
@VirMach seems to have launched a paid migration service, charging $3 per migration, but until there is an official announcement, I’m not sure if it’s worth trying.
I’d like to migrate my current SJC instance to Tokyo, and I hope the team will waive the migration fee (data transfer isn’t necessary).
I look forward to VirMach officially announcing the details of this feature.
PS：The reason I haven’t tried it is that the page displays the message: ‘Add credit before submitting this request.’
However, the minimum top-up amount is $20, and it doesn’t seem necessary to top up $20 in advance for a transaction worth just $3. I would suggest adding an option to pay via direct billing, as this would seem more acceptable.
@tulipyun said: But it seems that the restoration work at SJC has come to a standstill.
I'm just reaching here, but if VirMach's plan was to move most of those Nodes to Los Angeles it would be logical to revamp the LAX network first before adding more servers.
@FAT32 said: Somehow I noticed IP changing so I am logging in and nice to see @VirMach is still around.
I came back and then he came back. Who would have thought that would happen.
Things seem to be going a better direction at VirMach lately.
Migration update: Showed "queued", then took $3 from my balance, then showed 'Moving' (migrating to Node TYO0027 which is down), then went back to showing "queued".
Can somebody that has an OKC VM please check their next billing date and let me know if you see any thing different ?
Hoagie time !!
Migration update: Still shows "queued".
I'd recommend waiting a bit before using this new feature.
@FrankZ said: Migration update: Still shows "queued".
I'd recommend waiting a bit before using this new feature.
I saw your request in the system. It's due to human error, not the tool in this case. I put TYOC027 out of maintenance mode to test/get it ready for something I'm working on, and I forgot to put it back in maintenance mode. The system should have obviously caught it though, it didn't because of a new feature I recently stacked onto it to have its own logic in picking a node that's focused on placing you on the most "optimal" node (which is TYOC027, because it's pretty empty thanks to being down for so long.)
EDIT -- Just to be clear the logic does make sure it doesn't pick a node in maintenance mode, it just wasn't in maintenance mode. So actually the same error would have happened on any existing third party system, but ours also has ping checks so I'll just make sure it uses that too in the node check logic.
Somehow I noticed IP changing so I am logging in and nice to see @VirMach is still around
Hello!
Just to keep you updated, we now have a fancy new system for IP changes, but we're still VirMach so it means that didn't prevent it from being a total headache/mess.
@tulipyun said: But it seems that the restoration work at SJC has come to a standstill.
I'm just reaching here, but if VirMach's plan was to move most of those Nodes to Los Angeles it would be logical to revamp the LAX network first before adding more servers.
There was a network revamp in the works, the LAX region has a hex that hasn't been lifted yet. There have been like maybe 6 total switches that have failed in weird ways, and every replacement I take in seems to be picked out of the trash pile. We've gotten lucky every time though and made it work with loose strings and duct tape so it's never caused a major outage, it just means the location has never reached what it requires.
QPS helped us out more recently to do some final software updates I was afraid of doing on my own, plus some configuration changes, and that seems to have stabilized it. The reasoning you presented was definitely considered and what led to San Jose to LAX taking longer than it did (or a convenient "excuse.") The other was the upcoming IP renumbering being delayed, they were supposed to happen a couple weeks after the San Jose recovery.
@FrankZ said: P.S. I would not try to migrate my SJC while it's off line. I expect that might cause problems.
Sounds like another bug. Now that I think of it, you probably shouldn't migrate a terminated service either because I definitely forgot we still technically keep track of those in the system and there could definitely currently be cases where it lets you do it.
@tulipyun said: @VirMach seems to have launched a paid migration service, charging $3 per migration, but until there is an official announcement, I’m not sure if it’s worth trying.
I’d like to migrate my current SJC instance to Tokyo, and I hope the team will waive the migration fee (data transfer isn’t necessary).
I look forward to VirMach officially announcing the details of this feature.
PS：The reason I haven’t tried it is that the page displays the message: ‘Add credit before submitting this request.’
However, the minimum top-up amount is $20, and it doesn’t seem necessary to top up $20 in advance for a transaction worth just $3. I would suggest adding an option to pay via direct billing, as this would seem more acceptable.
Migration fee waivers are in the works. I'll just touch on it here now instead of keeping the drum roll going for the announcement. The system was specifically remade in this way to use credits and the minimum deposit amount is deliberate. We could also (and would) just provide it as a free feature, but the same reasoning is preventing us from doing both and that's abuse.
Later on as we work in our "loyalty" system, and other anti-fraud/anti-abuse measures, there will be some changes that will allow certain customers to migrate for free in some ways.
Your service xxxxx is scheduled for an IP address change on 6:30PM PDT on 05/08/26 .
Current IP: xxx.xxx.xxx.xxx
Your new IP: xxx.xxx.xxx.xxx
The new IP should be available to use on 7:00PM PDT on 05/08/26 and the old IP will be removed 6:00PM PDT on 05/08/26
So, does that mean it will be offline for up to an hour?
It means we should rewrite the message and change some defaults in the system. These batches aren't really using the system how it was originally intended, which is things happening on certain days. We scrunched it into a day which has been causing some problems and communications haven't been sent out as I wanted. Hopefully it'll be more clear and smooth for the NYC changes.
@FrankZ said: Just in case you might want to know the system did not create a billing invoice for the migration. It did deduct the $3 from my balance as expected.
I'm conflicted on whether I want to add an invoice for better reference. I just see all the ways it could end up making the process run into issues. It's definitely "intended" right now for it to be credits, except I don't like how it's not represented neatly. I'm sure I'll figure out how to rework an old idea/code into filling our use case.
@FrankZ said: Hi @VirMach
I'm always happy to test things out when ever you need a guinea pig.
Your VM really doesn't want to move because it just hit a SolusVM bug. I saw it a couple times, it's a lot rare than before but not gone. And I haven't decided what to do about it yet or what I can do. When this API came out and over the years, I absolutely did not want to use it but now we have so I guess I'll try to think about it some more. Worst case scenario we have our own over-complicated system that can maybe partially take over.
This is the issue, it just stops updating the progress:
Progress updated last time 09.05.26, 01:36 (51 minute(s) ago)
It doesn't actually stop transferring. So it could mean the progress update freezing means something went horribly wrong, but in most cases what went wrong is that it lost the progress.
I guess it just needs to throw an error on our end in some way even though no API, maybe open a ticket and have me handle them manually. just pushed yours through, if the data is corrupted let me know, it looks weird right now but I can't have a look right now. Maybe you've discovered a third bug.
Yes it was, but I reinstalled from template, and now VM is working fine.
I'm just playing around with the new cool functions, please don't let me distract you.
Seems like the network on my server on LAX1Z014, while received a DHCP response, can not ping to the internet. I already saw the server status but it is only on LAX1Z013, LAX1Z015 and LAX1Z016.
Migration fee waivers sound awesome for those of us that already have stuff in LAX.
I only needed SJ because I go there every year or two. Would sure love to be able to have a Virmach server in Tokyo again.
@ricANNArdo said:
Seems like the network on my server on LAX1Z014, while received a DHCP response, can not ping to the internet. I already saw the server status but it is only on LAX1Z013, LAX1Z015 and LAX1Z016.
A lot of stuff is going on with some of the LAX renumbering, it's not how I wanted, but the good news is that the system has them all tracked. I've had to work on improving the system to deal with really specific scenarios and the code didn't go all that well in all cases. One of the major improvements is linking the migration system to the IP change system in a more meaningful way.
LAX1Z014 is one of these, and it's waiting on a few more bug fixes. I've been working on it all night, so hopefully it should receive an emergency migration and IP change very soon.
That was not the original intention, that's why it's an "emergency" now (the system won't label it as such) since it's gone past the original scheduled timeline. What was supposed to happen was you received a notification of IP changing and it requiring migration in this case.
One of the complications was that the system was originally built to support the migrations in a certain way that would not work well for LAX1Z014 and LAX1Z015. Oh and LAX1Z019 is also one of these migration-type renumbering, it's partially complete, almost done -- this one faced a different issue and used the original system (the node it was migrating to ran into API issues and created a mess due to how it had to be batched.)
@theloafingone said:
Migration fee waivers sound awesome for those of us that already have stuff in LAX.
I only needed SJ because I go there every year or two. Would sure love to be able to have a Virmach server in Tokyo again.
I'm trying my best to push this through as I'm excited about it and I want to avoid delaying it forever. It's just going to likely end up completing after (1) San Jose servers are done finding a new home and (2) renumbering is done. I've been getting better at cramming in "non-critical" tasks though so we'll see how it goes.
Yes it was, but I reinstalled from template, and now VM is working fine.
I'm just playing around with the new cool functions, please don't let me distract you.
It's a good distraction because of the LAX1Z014 thing I just went over, it uses the same system and I was already working on that at the time. Nice to have a "something went wrong" case presented to me before it happens on the next bulk migration.
The system directly grants a $3 credit to VPSs that have been offline for an extended period, allowing users to choose between migrating or continuing to wait for them to be fixed.
(Personal opinion only)
However, the three VPSs on the ATLZ032 node are still not working properly even after their expiration dates have been extended by three months... If I had the choice, I might choose to migrate.
If you wish to control the costs associated with migrating VPS instances to Tokyo, you can increase the migration fee for that specific destination. Offer offline users a free migration opportunity (but Tokyo cannot be selected).
Comments
Other way around. I woke up at 5:30am today...
It looks great. Is the promotion event coming back this year?
IP changes
More ip changes
Preference would be to move my dead San Jose server to somewhere other than Tokyo
Hey Joe! Haven't seen you in years.
"It's a hard life- to be a stick insect." - Karl Pilkington
So, does that mean it will be offline for up to an hour?
@VirMach seems to have launched a paid migration service, charging $3 per migration, but until there is an official announcement, I’m not sure if it’s worth trying.
I’d like to migrate my current SJC instance to Tokyo, and I hope the team will waive the migration fee (data transfer isn’t necessary).
I look forward to VirMach officially announcing the details of this feature.
PS：The reason I haven’t tried it is that the page displays the message: ‘Add credit before submitting this request.’
However, the minimum top-up amount is $20, and it doesn’t seem necessary to top up $20 in advance for a transaction worth just $3. I would suggest adding an option to pay via direct billing, as this would seem more acceptable.
No worries. I check it out and move one then let you know if it works out as expected.
P.S. I would not try to migrate my SJC while it's off line. I expect that might cause problems.
P.S.S Hi @JoeMerit.
Yes, I agree.
But it seems that the restoration work at SJC has come to a standstill.
things might improve in 2027.
I bench YABS 24/7/365 unless it's a leap year.
I'm just reaching here, but if VirMach's plan was to move most of those Nodes to Los Angeles it would be logical to revamp the LAX network first before adding more servers.
HELLO
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
Somehow I noticed IP changing so I am logging in and nice to see @VirMach is still around
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
I came back and then he came back. Who would have thought that would happen.
Things seem to be going a better direction at VirMach lately.
Migration update: Showed "queued", then took $3 from my balance, then showed 'Moving' (migrating to Node TYO0027 which is down), then went back to showing "queued".
Can somebody that has an OKC VM please check their next billing date and let me know if you see any thing different ?
Hoagie time !!
Migration update: Still shows "queued".
I'd recommend waiting a bit before using this new feature.
I saw your request in the system. It's due to human error, not the tool in this case. I put TYOC027 out of maintenance mode to test/get it ready for something I'm working on, and I forgot to put it back in maintenance mode. The system should have obviously caught it though, it didn't because of a new feature I recently stacked onto it to have its own logic in picking a node that's focused on placing you on the most "optimal" node (which is TYOC027, because it's pretty empty thanks to being down for so long.)
EDIT -- Just to be clear the logic does make sure it doesn't pick a node in maintenance mode, it just wasn't in maintenance mode. So actually the same error would have happened on any existing third party system, but ours also has ping checks so I'll just make sure it uses that too in the node check logic.
Hi @VirMach
I'm always happy to test things out when ever you need a guinea pig.
regards,
Just in case you might want to know the system did not create a billing invoice for the migration. It did deduct the $3 from my balance as expected.
Hello!
Just to keep you updated, we now have a fancy new system for IP changes, but we're still VirMach so it means that didn't prevent it from being a total headache/mess.
There was a network revamp in the works, the LAX region has a hex that hasn't been lifted yet. There have been like maybe 6 total switches that have failed in weird ways, and every replacement I take in seems to be picked out of the trash pile. We've gotten lucky every time though and made it work with loose strings and duct tape so it's never caused a major outage, it just means the location has never reached what it requires.
QPS helped us out more recently to do some final software updates I was afraid of doing on my own, plus some configuration changes, and that seems to have stabilized it. The reasoning you presented was definitely considered and what led to San Jose to LAX taking longer than it did (or a convenient "excuse.") The other was the upcoming IP renumbering being delayed, they were supposed to happen a couple weeks after the San Jose recovery.
Definitely by 2028. Let's round up to 2030.
Sounds like another bug. Now that I think of it, you probably shouldn't migrate a terminated service either because I definitely forgot we still technically keep track of those in the system and there could definitely currently be cases where it lets you do it.
Migration fee waivers are in the works. I'll just touch on it here now instead of keeping the drum roll going for the announcement. The system was specifically remade in this way to use credits and the minimum deposit amount is deliberate. We could also (and would) just provide it as a free feature, but the same reasoning is preventing us from doing both and that's abuse.
Later on as we work in our "loyalty" system, and other anti-fraud/anti-abuse measures, there will be some changes that will allow certain customers to migrate for free in some ways.
It means we should rewrite the message and change some defaults in the system. These batches aren't really using the system how it was originally intended, which is things happening on certain days. We scrunched it into a day which has been causing some problems and communications haven't been sent out as I wanted. Hopefully it'll be more clear and smooth for the NYC changes.
Virtfusion and EPYC when?
I bench YABS 24/7/365 unless it's a leap year.
I'm conflicted on whether I want to add an invoice for better reference. I just see all the ways it could end up making the process run into issues. It's definitely "intended" right now for it to be credits, except I don't like how it's not represented neatly. I'm sure I'll figure out how to rework an old idea/code into filling our use case.
Your VM really doesn't want to move because it just hit a SolusVM bug. I saw it a couple times, it's a lot rare than before but not gone. And I haven't decided what to do about it yet or what I can do. When this API came out and over the years, I absolutely did not want to use it but now we have so I guess I'll try to think about it some more. Worst case scenario we have our own over-complicated system that can maybe partially take over.
This is the issue, it just stops updating the progress:
It doesn't actually stop transferring. So it could mean the progress update freezing means something went horribly wrong, but in most cases what went wrong is that it lost the progress.
I guess it just needs to throw an error on our end in some way even though no API, maybe open a ticket and have me handle them manually. just pushed yours through, if the data is corrupted let me know, it looks weird right now but I can't have a look right now. Maybe you've discovered a third bug.
Yes it was, but I reinstalled from template, and now VM is working fine.
I'm just playing around with the new cool functions, please don't let me distract you.
Seems like the network on my server on LAX1Z014, while received a DHCP response, can not ping to the internet. I already saw the server status but it is only on LAX1Z013, LAX1Z015 and LAX1Z016.
You probably saw me somewhere...
Migration fee waivers sound awesome for those of us that already have stuff in LAX.
I only needed SJ because I go there every year or two. Would sure love to be able to have a Virmach server in Tokyo again.
A lot of stuff is going on with some of the LAX renumbering, it's not how I wanted, but the good news is that the system has them all tracked. I've had to work on improving the system to deal with really specific scenarios and the code didn't go all that well in all cases. One of the major improvements is linking the migration system to the IP change system in a more meaningful way.
LAX1Z014 is one of these, and it's waiting on a few more bug fixes. I've been working on it all night, so hopefully it should receive an emergency migration and IP change very soon.
That was not the original intention, that's why it's an "emergency" now (the system won't label it as such) since it's gone past the original scheduled timeline. What was supposed to happen was you received a notification of IP changing and it requiring migration in this case.
One of the complications was that the system was originally built to support the migrations in a certain way that would not work well for LAX1Z014 and LAX1Z015. Oh and LAX1Z019 is also one of these migration-type renumbering, it's partially complete, almost done -- this one faced a different issue and used the original system (the node it was migrating to ran into API issues and created a mess due to how it had to be batched.)
I'm trying my best to push this through as I'm excited about it and I want to avoid delaying it forever. It's just going to likely end up completing after (1) San Jose servers are done finding a new home and (2) renumbering is done. I've been getting better at cramming in "non-critical" tasks though so we'll see how it goes.
It's a good distraction because of the LAX1Z014 thing I just went over, it uses the same system and I was already working on that at the time. Nice to have a "something went wrong" case presented to me before it happens on the next bulk migration.
The system directly grants a $3 credit to VPSs that have been offline for an extended period, allowing users to choose between migrating or continuing to wait for them to be fixed.
(Personal opinion only)
However, the three VPSs on the ATLZ032 node are still not working properly even after their expiration dates have been extended by three months... If I had the choice, I might choose to migrate.
If you wish to control the costs associated with migrating VPS instances to Tokyo, you can increase the migration fee for that specific destination. Offer offline users a free migration opportunity (but Tokyo cannot be selected).
@VirMach, would you re-activate my 30 vms? Ticket #835569
Any news on TYOC038?
my VPS was pointed to a new IP yesterday, unfortunately the new IP is unreacheble. so my working VPS is relocated to a non working one.
edit: "Last node SJCZ018"