@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).
@julensm said:
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
If you previously made manual changes to your VM's network the config network button may not fix the issue, but I'd give it a try first. What Node are we talking about here ?
EDIT: If I understand you correctly, you are saying that you had a working VM on SJCZ018 yesterday ?
Where is it located now, Los Angeles or Tokyo ?
Last thing I have is from 2025-12-18 00:00:00:
We are currently experiencing an incident affecting several nodes in the SJC location. Our team is investigating the situation. Affected nodes include: SJCZ001, SJCZ002, SJCZ003, SJCZ004, SJCZ005B, SJCZ006, SJCZ007, SJCZ008, SJCZ009, SJCZ010, SJCZ011, SJCZ012, SJCZ013, SJCZ014, SJCZ018, SJCZ019, SJCZ020.
@tenpera said: @VirMach, would you re-activate my 30 vms? Ticket #835569
You still have 30 active VMs ? Color me surprised.
Or are you wanting VirMach to reactivate 30 previously canceled VMs ?
@FrankZ said: VirMach to reactivate 30 previously canceled VMs
I'm going to go out on a limb here and suggest that you close that ticket to reactivate your 30 previously cancelled VMs because I don't expect that will happen. Of course if you ignore my suggestion, which you are more than welcome to do, and VirMach does reactivate your 30 previously canceled VMs, please let us know as I have 5 or so VMs that I cancelled in the past that I would like to get back again.
I went to see if it was possible for an SJC VPS to be migrated to OKC (For when the SJC VPS comes back online), but it seems like that's not an option, I think that might be because OKC is still in beta. Personally, I'd rather have it in OKC, since I'm good on west coast VPS for now.
It's also nice seeing Virmach back, posting updates and such.
@VirMach My VPS is located at the LAXA016 node. I previously received a notification stating that a new IP address had been assigned to me; however, I am currently unable to connect to the VPS using this new IP, nor can I connect using the old one.
@LinuxWinMAC said: @VirMach My VPS is located at the LAXA016 node. I previously received a notification stating that a new IP address had been assigned to me; however, I am currently unable to connect to the VPS using this new IP, nor can I connect using the old one.
For my VPS in LAX I had to VNC in and modify the /etc/network/interfaces file to change eth0 to ens3 to get it to work.
You can check if your interface was changed with this update by comparing the /etc/network/interfaces file with something like 'ip link'.
@FrankZ, I didn't cancel any, they're auto-cancelled due to non-payment during services were off. I didn't feel any justification paying for non-working services.
@tenpera said: @FrankZ, I didn't cancel any, they're auto-cancelled due to non-payment during services were off. I didn't feel any justification paying for non-working services.
Although I wish you the best with your quest, I'm 50/50 on if there is much of a difference between not paying and cancelling . I had one that I decided not to renew because it was down for a while that was on TYOC027. The one I had on TYOC007 I did renew even though it was down for a while. VirMach extended the next due date to compensate for the down time of the VM on TYOC007 when it came back up. Keep us informed about how this goes for you, I for one would be interested to know the final outcome.
Just so you guys with new IPs having network issues in LAX don't feel alone ..... I have a VM on LAXA022 that just got an IP change and I am having a hard time getting the networking working. Everything looks good via VNC but I can't even ping the gateway.
EDIT: network on my VM on LAXA022 is working fine now. I did not do anything.
I've got a VPS that was originally in Denver, now the panel says it's on LAXA024. (Probably moved a long time ago.) It doesn't seem to have gotten any new IP assigned, the panel and the VM inside has the same IP configured … But it says: Multiple issues — 4 related events cluster Scheduled
Opened 2026-05-06 14:10:13
This is a grouped incident covering 4 related issues. Expand for per-event details.
I'm not sure how to expand the issues from there, though … The host is up, I can login through the console. But inside the VM I can't ping default gateway. If the system tries network autoconfig, I'm pretty sure it will fail, as it thinks the VM runs Debian, while it's actually running OpenBSD …
On the network status page I found this affecting my node there:
Ongoing scheduled maintenance at LAX #787
… But it's listed as resolved … 🤷♂️😅
@flips said:
I've got a VPS that was originally in Denver, now the panel says it's on LAXA024. (Probably moved a long time ago.) It doesn't seem to have gotten any new IP assigned, the panel and the VM inside has the same IP configured … But it says: Multiple issues — 4 related events cluster Scheduled
Opened 2026-05-06 14:10:13
This is a grouped incident covering 4 related issues. Expand for per-event details.
I'm not sure how to expand the issues from there, though … The host is up, I can login through the console. But inside the VM I can't ping default gateway. If the system tries network autoconfig, I'm pretty sure it will fail, as it thinks the VM runs Debian, while it's actually running OpenBSD …
On the network status page I found this affecting my node there:
Ongoing scheduled maintenance at LAX #787
… But it's listed as resolved … 🤷♂️😅
The automatic network issue are not perfect right now when it comes to things flying around. I haven't focused on fixing that right now. In your case though, it being "resolved" is correct. Just your specific VM is not, which would potentially show up in the future, I just haven't hooked up individual/partial outages as automatic in the system yet.
There was a bug on this and/or human error that caused some to be skipped over. I'm still cleaning everything up now.
@LinuxWinMAC said: @VirMach My VPS is located at the LAXA016 node. I previously received a notification stating that a new IP address had been assigned to me; however, I am currently unable to connect to the VPS using this new IP, nor can I connect using the old one.
For my VPS in LAX I had to VNC in and modify the /etc/network/interfaces file to change eth0 to ens3 to get it to work.
You can check if your interface was changed with this update by comparing the /etc/network/interfaces file with something like 'ip link'.
I configured it using the method you suggested, but it still isn't working. Nevertheless, thank you for your help.
I configured it using the method you suggested, but it still isn't working. Nevertheless, thank you for your help.
Just sharing some data points for reference based on my HetrixTools monitoring.
LAX1Z016 - Scheduled: 06:30 PM (05/08 PDT), Actual Downtime: 11:35 PM (05/08) - 02:02 AM (05/09) PDT
LAXZ0016 - Scheduled: 04:15 PM (05/09 PDT), Actual Downtime: 05:26 PM (05/09) - 12:39 AM (05/10) PDT
Separately, my VPS on CHIZ030 has been offline for about 4 hours now, but I hope that time will resolve the issue.
Now, since the downtime was longer than expected, I must open a ticket to request service credits. For roughly 7.5 hours, on a pro-rated basis... would it be $0.007? Oh my, it seems VirMach's support will be buried under requests for $0.01 credits.
@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.
Update: It seems like the server got moved out of the node, but still no connectivity AND gateway does not ping anymore. I guess more waiting is needed for now.
we got progress! the migrate function would let me do a free migration on my dead San Jose VPS, but I can't pick a destination location. I like the direction of that because once I can pick a new location I'm moving it. Looking at NYC/Chicago.
@VirMach My service failed to start after I moved the server location. Please check it. Ticket #162419. Thank you.
Another service under the same account, which I tried to move to Amsterdam, also failed, even though the server location fee has already been deducted.
@VirMach said: There was a bug on this and/or human error that caused some to be skipped over. I'm still cleaning everything up now.
I guess you'll let me know if I need to do anything … I haven't figured out anything more meaningful to test/try, other than power off and on, and pinging default gateway IPv4 … (Getting "Host is down" …)
@JoeMerit said:
we got progress! the migrate function would let me do a free migration on my dead San Jose VPS, but I can't pick a destination location. I like the direction of that because once I can pick a new location I'm moving it. Looking at NYC/Chicago.
Is this under "Modify Service > Migrate"? My SJC VM still shows credit is needed.
I've got four VMs and only one is online. ATL, NYC, and SJC all been inoperable for days or months in the case of SJC. It would be nice for me to be able to migrate at least one of these somewhere else.
@JoeMerit said:
we got progress! the migrate function would let me do a free migration on my dead San Jose VPS, but I can't pick a destination location. I like the direction of that because once I can pick a new location I'm moving it. Looking at NYC/Chicago.
Is this under "Modify Service > Migrate"? My SJC VM still shows credit is needed.
I've got four VMs and only one is online. ATL, NYC, and SJC all been inoperable for days or months in the case of SJC. It would be nice for me to be able to migrate at least one of these somewhere else.
Yes, I can't do anything though. Dropdown box of destinations is still empty.
Just my two cents.....
For those of you thinking about migrating an offline VM. I expect if you try to do this you may cause yourself more problems and the VM will be down even longer. I say this because migration infers moving a disk image from one node to another. If the disk image that you are migrating from is not available your not going to get your data moved. The empty drop down box may be because VirMach was smart enough to write a check into the migration widget that checks to see if the "from" disk image is available before allowing a "to" to be selected.
@tototo said: Separately, my VPS on CHIZ030 has been offline for about 4 hours now, but I hope that time will resolve the issue.
I decided to postpone Chicago changes, but forgot that I coordinated the date with the datacenter. Quickly caught and asked them to re-announce but likely
@Aaron6 said: @VirMach My service failed to start after I moved the server location. Please check it. Ticket #162419. Thank you.
Another service under the same account, which I tried to move to Amsterdam, also failed, even though the server location fee has already been deducted.
This is due to a SVM bug. There's a few things that they never fixed even after I handed them the easy solution, then there are other things that they broke, and "fixed" but didn't fix it in a way where it actually fixes it retroactively. This is one of those, it's related to the VNC feature.
I'm going to see if we can finally add our own auto debug and fix for some of these things or the automatic migrations are probably going to start getting annoying pretty quickly.
There's actually two bugs related to VNC that cause most the problems, and disabling VNC is technically a good way to check for them, but last I remember they do not have API for it. So maybe I should try to squeeze a message in somewhere that goes over the process as a temporarily solution in these cases.
This specific bug can be fixed by changing your VNC password, of course there's no way for you to know that. The good news is for future migrations we can definitely patch this one since there's API for changing VNC password, so if it doesn't come online after a migration we can try to catch it and do that as an additional step.
@JoeMerit said:
we got progress! the migrate function would let me do a free migration on my dead San Jose VPS, but I can't pick a destination location. I like the direction of that because once I can pick a new location I'm moving it. Looking at NYC/Chicago.
Is this under "Modify Service > Migrate"? My SJC VM still shows credit is needed.
I've got four VMs and only one is online. ATL, NYC, and SJC all been inoperable for days or months in the case of SJC. It would be nice for me to be able to migrate at least one of these somewhere else.
@JoeMerit said:
we got progress! the migrate function would let me do a free migration on my dead San Jose VPS, but I can't pick a destination location. I like the direction of that because once I can pick a new location I'm moving it. Looking at NYC/Chicago.
Unfortunately unless I'm forgetting some feature I added, this sounds like a bug. You shouldn't be able to migrate your dead San Jose VPS. Don't worry though there is some actual progress going on to allow you guys to do that (as well as to, you know, make sure I finish San Jose migrations so you actually have a functional service in this case.)
I believe what you described stems from a weird SVM bug. Well the bug is interesting because it's like a "reverse bug" maybe, if you could call it that. Basically what usually happens when a node is down is everything malfunctions spectacularly so we're used to that happening. If a node is down, but the IP address is pinging, even if the IP is no longer the IP address of the server, it doesn't just break everything as it usually would. That means the breaking/lagging everything out feature/bug was actually added in for only cases where an IP... pings? Anyway since some of our stuff relies on what SolusVM says, and since we're used to their API behaving how it does, it means in this case it doesn't behave that way and therefore could throw things off on our end.
So what's probably happening is that means we tell it to check if SolusVM APi responds, if it doesn't it means it's down, if it does, it's up. Except it's down, but SolusVM doesn't "not" respond or whatever version of that.
The actual "migrate from dead server" feature won't be using the SVM migration API, it's actually something I already coded out a long time ago, it's just being reworked right now.
@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.
Update: It seems like the server got moved out of the node, but still no connectivity AND gateway does not ping anymore. I guess more waiting is needed for now.
Good chance for all the remaining issues to be resolved today. Most have them been worked through, a few servers giving me issues in terms of being finicky with migrations and such.
I have no idea if this was not implemented (yet?) or is still not.
I just realized I have a automagic ticket new IP service migration from... 4 weeks ago, but no e-mail sent, nothing in WHMCS e-mail history, just a silent ticket.
Ticket number #378615 if e-mails should be there [aka implemented] and for some reason you want to investigate 4 weeks old thing LOL
Also: where is a button to put website in normal/bright/white mode? It's dark by default and I can't figure out where it's stored. Cleared page data and it's daaaaaark.
EDIT: okey, it follows (or it's Chrome) settings feature >.>
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
@VirMach I see that the service migrated to Japan is now online, but the original IP address hasn't been removed. Another service migrated to Amsterdam is still offline; the migration failed. Please help me resolve this issue, thank you.
You can find my account through the previously opened ticket #162419.
@VirMach said:
If a node is down, but the IP address is pinging, even if the IP is no longer the IP address of the server, it doesn't just break everything as it usually would. That means the breaking/lagging everything out feature/bug was actually added in for only cases where an IP... pings? Anyway since some of our stuff relies on what SolusVM says, and since we're used to their API behaving how it does, it means in this case it doesn't behave that way and therefore could throw things off on our end.
It is true that, under the current circumstances, the results of the online probe based on the ICMP protocol are in fact incorrect. If you click ‘Run diagnostics’ in the control panel, you will receive results that do not correspond to the actual situation at all:
“Probing connectivity for service #689815 on node SJCZ012…— main IP up, node up, WHMCS status: Active”
In reality, as these IP addresses are already in use by other providers, they can indeed be pinged on the internet; however, this is completely at odds with the actual status of the service.
I seem to be encountering much the same issue as @flips .
The server (LAX1Z013) is online—I can access it via VNC—but in reality, it is unable to establish any external network connectivity.
In the "Network Status" section, the relevant issue (#1222) is currently marked as "Resolved."
I tried running "Fix Internet/Configure," but it had no effect.
I saw some of your comments above where you mentioned, "I'm still cleaning everything up now." Does that mean the only option for the moment is to wait for you to implement a fix?
I know you have a lot of tasks to handle, one by one.. However, I just wanted to let you know that this server is currently still in a non-functional state.
I seem to be encountering much the same issue as @flips .
The server (LAX1Z013) is online—I can access it via VNC—but in reality, it is unable to establish any external network connectivity.
In the "Network Status" section, the relevant issue (#1222) is currently marked as "Resolved."
I tried running "Fix Internet/Configure," but it had no effect.
I saw some of your comments above where you mentioned, "I'm still cleaning everything up now." Does that mean the only option for the moment is to wait for you to implement a fix?
I know you have a lot of tasks to handle, one by one.. However, I just wanted to let you know that this server is currently still in a non-functional state.
Well. I just found the server's IP is changed to a new one and it is working now. seem back "real online" 7 hours ago.
@LinuxWinMAC said:
The connectivity issue following the IP update has been resolved.
How was it resolved? The IP after my migration is still the same as before, it hasn't changed at all. Now I can't use my server. @VirMach
I manually changed the IP address and gateway to the new ones; aside from that, I don't think I modified anything else. It wasn't working initially, but—after some unknown changes occurred in the interim—it is currently working.
Comments
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"
If you previously made manual changes to your VM's network the config network button may not fix the issue, but I'd give it a try first.
What Node are we talking about here ?
EDIT: If I understand you correctly, you are saying that you had a working VM on SJCZ018 yesterday ?
Where is it located now, Los Angeles or Tokyo ?
Last thing I have is from 2025-12-18 00:00:00:
You still have 30 active VMs ? Color me surprised.
Or are you wanting VirMach to reactivate 30 previously canceled VMs ?
I'm going to go out on a limb here and suggest that you close that ticket to reactivate your 30 previously cancelled VMs because I don't expect that will happen. Of course if you ignore my suggestion, which you are more than welcome to do, and VirMach does reactivate your 30 previously canceled VMs, please let us know as I have 5 or so VMs that I cancelled in the past that I would like to get back again.
The migration feature seems cool.
I went to see if it was possible for an SJC VPS to be migrated to OKC (For when the SJC VPS comes back online), but it seems like that's not an option, I think that might be because OKC is still in beta. Personally, I'd rather have it in OKC, since I'm good on west coast VPS for now.
It's also nice seeing Virmach back, posting updates and such.
@VirMach My VPS is located at the LAXA016 node. I previously received a notification stating that a new IP address had been assigned to me; however, I am currently unable to connect to the VPS using this new IP, nor can I connect using the old one.
For my VPS in LAX I had to VNC in and modify the /etc/network/interfaces file to change eth0 to ens3 to get it to work.
You can check if your interface was changed with this update by comparing the /etc/network/interfaces file with something like 'ip link'.
@FrankZ, I didn't cancel any, they're auto-cancelled due to non-payment during services were off. I didn't feel any justification paying for non-working services.
Although I wish you the best with your quest, I'm 50/50 on if there is much of a difference between not paying and cancelling . I had one that I decided not to renew because it was down for a while that was on TYOC027. The one I had on TYOC007 I did renew even though it was down for a while. VirMach extended the next due date to compensate for the down time of the VM on TYOC007 when it came back up. Keep us informed about how this goes for you, I for one would be interested to know the final outcome.
Just so you guys with new IPs having network issues in LAX don't feel alone .....
I have a VM on LAXA022 that just got an IP change and I am having a hard time getting the networking working. Everything looks good via VNC but I can't even ping the gateway.
EDIT: network on my VM on LAXA022 is working fine now. I did not do anything.
I've got a VPS that was originally in Denver, now the panel says it's on LAXA024. (Probably moved a long time ago.) It doesn't seem to have gotten any new IP assigned, the panel and the VM inside has the same IP configured … But it says:
Multiple issues — 4 related events cluster Scheduled
Opened 2026-05-06 14:10:13
This is a grouped incident covering 4 related issues. Expand for per-event details.
I'm not sure how to expand the issues from there, though … The host is up, I can login through the console. But inside the VM I can't ping default gateway. If the system tries network autoconfig, I'm pretty sure it will fail, as it thinks the VM runs Debian, while it's actually running OpenBSD …
On the network status page I found this affecting my node there:
Ongoing scheduled maintenance at LAX #787
… But it's listed as resolved … 🤷♂️😅
The automatic network issue are not perfect right now when it comes to things flying around. I haven't focused on fixing that right now. In your case though, it being "resolved" is correct. Just your specific VM is not, which would potentially show up in the future, I just haven't hooked up individual/partial outages as automatic in the system yet.
There was a bug on this and/or human error that caused some to be skipped over. I'm still cleaning everything up now.
I configured it using the method you suggested, but it still isn't working. Nevertheless, thank you for your help.
Just sharing some data points for reference based on my HetrixTools monitoring.
LAX1Z016 - Scheduled: 06:30 PM (05/08 PDT), Actual Downtime: 11:35 PM (05/08) - 02:02 AM (05/09) PDT
LAXZ0016 - Scheduled: 04:15 PM (05/09 PDT), Actual Downtime: 05:26 PM (05/09) - 12:39 AM (05/10) PDT
Separately, my VPS on CHIZ030 has been offline for about 4 hours now, but I hope that time will resolve the issue.
Now, since the downtime was longer than expected, I must open a ticket to request service credits. For roughly 7.5 hours, on a pro-rated basis... would it be $0.007? Oh my, it seems VirMach's support will be buried under requests for $0.01 credits.
Update: It seems like the server got moved out of the node, but still no connectivity AND gateway does not ping anymore. I guess more waiting is needed for now.
You probably saw me somewhere...
we got progress! the migrate function would let me do a free migration on my dead San Jose VPS, but I can't pick a destination location. I like the direction of that because once I can pick a new location I'm moving it. Looking at NYC/Chicago.
@VirMach After the server migration, no new IP address was assigned. Please resolve this as soon as possible. Thank you.
@VirMach, Any news on TYOC038?
@VirMach My service failed to start after I moved the server location. Please check it. Ticket #162419. Thank you.
Another service under the same account, which I tried to move to Amsterdam, also failed, even though the server location fee has already been deducted.
Is this under "Modify Service > Migrate"? My SJC VM still shows credit is needed.
I've got four VMs and only one is online. ATL, NYC, and SJC all been inoperable for days or months in the case of SJC. It would be nice for me to be able to migrate at least one of these somewhere else.
Yes, I can't do anything though. Dropdown box of destinations is still empty.
Just my two cents.....
For those of you thinking about migrating an offline VM. I expect if you try to do this you may cause yourself more problems and the VM will be down even longer. I say this because migration infers moving a disk image from one node to another. If the disk image that you are migrating from is not available your not going to get your data moved. The empty drop down box may be because VirMach was smart enough to write a check into the migration widget that checks to see if the "from" disk image is available before allowing a "to" to be selected.
I decided to postpone Chicago changes, but forgot that I coordinated the date with the datacenter. Quickly caught and asked them to re-announce but likely
This is due to a SVM bug. There's a few things that they never fixed even after I handed them the easy solution, then there are other things that they broke, and "fixed" but didn't fix it in a way where it actually fixes it retroactively. This is one of those, it's related to the VNC feature.
I'm going to see if we can finally add our own auto debug and fix for some of these things or the automatic migrations are probably going to start getting annoying pretty quickly.
There's actually two bugs related to VNC that cause most the problems, and disabling VNC is technically a good way to check for them, but last I remember they do not have API for it. So maybe I should try to squeeze a message in somewhere that goes over the process as a temporarily solution in these cases.
This specific bug can be fixed by changing your VNC password, of course there's no way for you to know that. The good news is for future migrations we can definitely patch this one since there's API for changing VNC password, so if it doesn't come online after a migration we can try to catch it and do that as an additional step.
Unfortunately unless I'm forgetting some feature I added, this sounds like a bug. You shouldn't be able to migrate your dead San Jose VPS. Don't worry though there is some actual progress going on to allow you guys to do that (as well as to, you know, make sure I finish San Jose migrations so you actually have a functional service in this case.)
I believe what you described stems from a weird SVM bug. Well the bug is interesting because it's like a "reverse bug" maybe, if you could call it that. Basically what usually happens when a node is down is everything malfunctions spectacularly so we're used to that happening. If a node is down, but the IP address is pinging, even if the IP is no longer the IP address of the server, it doesn't just break everything as it usually would. That means the breaking/lagging everything out feature/bug was actually added in for only cases where an IP... pings? Anyway since some of our stuff relies on what SolusVM says, and since we're used to their API behaving how it does, it means in this case it doesn't behave that way and therefore could throw things off on our end.
So what's probably happening is that means we tell it to check if SolusVM APi responds, if it doesn't it means it's down, if it does, it's up. Except it's down, but SolusVM doesn't "not" respond or whatever version of that.
The actual "migrate from dead server" feature won't be using the SVM migration API, it's actually something I already coded out a long time ago, it's just being reworked right now.
Good chance for all the remaining issues to be resolved today. Most have them been worked through, a few servers giving me issues in terms of being finicky with migrations and such.
I have no idea if this was not implemented (yet?) or is still not.
I just realized I have a automagic ticket new IP service migration from... 4 weeks ago, but no e-mail sent, nothing in WHMCS e-mail history, just a silent ticket.
Ticket number #378615 if e-mails should be there [aka implemented] and for some reason you want to investigate 4 weeks old thing LOL
Also: where is a button to put website in normal/bright/white mode? It's dark by default and I can't figure out where it's stored. Cleared page data and it's daaaaaark.
EDIT: okey, it follows (or it's Chrome) settings feature >.>
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
@VirMach I see that the service migrated to Japan is now online, but the original IP address hasn't been removed. Another service migrated to Amsterdam is still offline; the migration failed. Please help me resolve this issue, thank you.
You can find my account through the previously opened ticket #162419.
The connectivity issue following the IP update has been resolved.
It is true that, under the current circumstances, the results of the online probe based on the ICMP protocol are in fact incorrect. If you click ‘Run diagnostics’ in the control panel, you will receive results that do not correspond to the actual situation at all:
“Probing connectivity for service #689815 on node SJCZ012…— main IP up, node up, WHMCS status: Active”
In reality, as these IP addresses are already in use by other providers, they can indeed be pinged on the internet; however, this is completely at odds with the actual status of the service.
How was it resolved? The IP after my migration is still the same as before, it hasn't changed at all. Now I can't use my server. @VirMach
@VirMach Long time no see!
I seem to be encountering much the same issue as @flips .
I saw some of your comments above where you mentioned, "I'm still cleaning everything up now." Does that mean the only option for the moment is to wait for you to implement a fix?
I know you have a lot of tasks to handle, one by one.. However, I just wanted to let you know that this server is currently still in a non-functional state.
Well. I just found the server's IP is changed to a new one and it is working now. seem back "real online" 7 hours ago.
I manually changed the IP address and gateway to the new ones; aside from that, I don't think I modified anything else. It wasn't working initially, but—after some unknown changes occurred in the interim—it is currently working.