@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 >.>
@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
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.
https://lowendspirit.com/uploads/editor/gi/ippw0lcmqowk.png
@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.