LAXA017 had a slightly different configuration than others, so it's not playing well with the network changes and causing heavy packet loss to nearby servers LAXA018 and LAXA019 as well. Having them attach KVM and should be corrected relatively painlessly after that.
It is possible for it to be complicated further if the reason for it being different than the others is something I recall correctly, in which case this node may need a motherboard swap or at the very least further attempts at BMC re-flash. In my brain though that was either LAXA027 or LAXA017, so we'll know in about half an hour.
@host4cheap said:
Is there any ETC for DALZ004/DALZ007 (Network status says - waiting for equipment release.)
It's all waiting on one guy at Flexential that's apparently the only person that can deal with the problem, and he's so far decided that he doesn't very much like doing anything about it.
@cornercase said:
So I guess my SJCZ005 was moved to LAXA007 however currently shows up with no OS installed. Should I be expecting a backup to load in here?
I don't believe that should have happened. Make a ticket so I can check.
MY MISTAKE! It was originally at DENZ001 not SJC.
Still curious if there will be a backup restore coming.
@cornercase said:
So I guess my SJCZ005 was moved to LAXA007 however currently shows up with no OS installed. Should I be expecting a backup to load in here?
I don't believe that should have happened. Make a ticket so I can check.
MY MISTAKE! It was originally at DENZ001 not SJC.
Still curious if there will be a backup restore coming.
Power down, and power back up. I'd need to know how exactly it shows with no OS installed to answer you further after that.
@cornercase said:
So I guess my SJCZ005 was moved to LAXA007 however currently shows up with no OS installed. Should I be expecting a backup to load in here?
I don't believe that should have happened. Make a ticket so I can check.
MY MISTAKE! It was originally at DENZ001 not SJC.
Still curious if there will be a backup restore coming.
Power down, and power back up. I'd need to know how exactly it shows with no OS installed to answer you further after that.
@cornercase said:
So I guess my SJCZ005 was moved to LAXA007 however currently shows up with no OS installed. Should I be expecting a backup to load in here?
I don't believe that should have happened. Make a ticket so I can check.
MY MISTAKE! It was originally at DENZ001 not SJC.
Still curious if there will be a backup restore coming.
Power down, and power back up. I'd need to know how exactly it shows with no OS installed to answer you further after that.
Done and no change. Ticket submitted.
Thanks
You had an old ISO mounted. We've been having lot of people not checking this, a lot and we've already added it to the reset button. I was going to tell you to use the reset button initially but told you the power down and power on specifically to make sure I could ask you this next series of questions.
How can we improve this further to where you do not miss that? When you initially saw it was offline, you just used the power on button instead, right? Or rather, when you were told to power it down, and then power it on, which is intentionally the wrong way of doing it, did you notice the message:
The virtual server has been booted successfully. If that did not work, make sure to unmount any ISO.
Or were you just doing all this through the full control panel?
@VirMach said:
How can we improve this further to where you do not miss that? When you initially saw it was offline, you just used the power on button instead, right? Or rather, when you were told to power it down, and then power it on, which is intentionally the wrong way of doing it, did you notice the message:
The virtual server has been booted successfully. If that did not work, make sure to unmount any ISO.
Or were you just doing all this through the full control panel?
I didn't pay attention to that message because there shouldn't be an ISO mounted. I have booted and rebooted this VM in the past (since I first set it up) and there has never been any issue with an ISO (either because one wasn't mounted or it wasn't first in the boot order). Maybe change the message to indicate that the boot order and/or presence of an ISO may have changed without the customer's intervention.
@VirMach said:
How can we improve this further to where you do not miss that? When you initially saw it was offline, you just used the power on button instead, right? Or rather, when you were told to power it down, and then power it on, which is intentionally the wrong way of doing it, did you notice the message:
The virtual server has been booted successfully. If that did not work, make sure to unmount any ISO.
Or were you just doing all this through the full control panel?
I didn't pay attention to that message because there shouldn't be an ISO mounted. I have booted and rebooted this VM in the past (since I first set it up) and there has never been any issue with an ISO (either because one wasn't mounted or it wasn't first in the boot order). Maybe change the message to indicate that the boot order and/or presence of an ISO may have changed without the customer's intervention.
ANYWAY: There is still no OS present...???
Installed OS: None Detected
None detected means none detected, not none.
It means the system doesn't know what's on there. This is most common when an ISO is mounted to install the OS, or an ISO was mounted but never used and SolusVM lost track of the original operating system name before the ISO mount. I've added more tooltips everywhere to improve explanations.
You had an ISO mounted from a long long time ago, and it doesn't exist anymore so it was trying to mount it still on reboot, you probably would not have noticed that previously if the service has been online since then or if the old ISO still existed on DENZ001 but not on LAXA007.
I do see this is on "hard disk only" for boot order, but I don't think that matters, this is based on SolusVM's code, not logic.
Are the new IP's for LAX that got made available today not routing yet?
45.15.143.1 seems to hit 10.254.0.7 IP when tracerouting (which is strange, I didn't think you could see a 10.x.x.x on the public Internet)
@VirMach said:
It means the system doesn't know what's on there. This is most common when an ISO is mounted to install the OS, or an ISO was mounted but never used and SolusVM lost track of the original operating system name before the ISO mount. I've added more tooltips everywhere to improve explanations.
You had an ISO mounted from a long long time ago, and it doesn't exist anymore so it was trying to mount it still on reboot, you probably would not have noticed that previously if the service has been online since then or if the old ISO still existed on DENZ001 but not on LAXA007.
I do see this is on "hard disk only" for boot order, but I don't think that matters, this is based on SolusVM's code, not logic.
Got it! I made it to a place where I could VNC in and it appears the IP (which is still the IP from DENZ001) is not being routed.
So is this expected and we are now just waiting for new IP addresses?
@cornercase said: So is this expected and we are now just waiting for new IP addresses?
Correct, I honestly don't know why it's not done yet, but I'm not the team member working on it. I may have to take over, we'll see.
@erk said:
Are the new IP's for LAX that got made available today not routing yet?
45.15.143.1 seems to hit 10.254.0.7 IP when tracerouting (which is strange, I didn't think you could see a 10.x.x.x on the public Internet)
Seattle --> LAX pushed further, likely going in a few hours. I had to spend a good amount of time on the packet loss issue and SolusVM API going slowly on the changes, and still need to wrap up other locations. LAX is almost out of the way though and that's the bulk of the changes. IP changes may have an intermission where I finally take the equipment down, we'll see how it goes.
Good news:
Flexential has finally responded and sent the form to begin getting equipment back out of Dallas and Denver, but it seems like they might still drag out the rest of the process.
Sabey is sending equipment to San Jose from Seattle.
Additional IPv4 leased, since we used Seattle's reserved IPv4 for the new cabinet in LAX and are doing both transfers still.
i have a vps at DENZ001 before, yesterday i found that it changed to LAXA007 now, But the ip is not be changed, still the same as the DENZ001 before, and i tested that this ip is empty route, is this normal?
@gritty I'm in the same boat with you. I expect that they are waiting for IP blocks to start routing before assigning them to our VMs on LAXA007. Should happen soon™ Of course maybe Qi forgot all about us, maybe.
It's 23rd today, I thought we could use new blocks from IPXO instead of the 47.87 one starting yesterday.
Found 2 IPs, 47.87.x.x and 89.33.x.x
Changed Main IP from 47 to 89 from Solus, and clicked reconfigure network. Boom, lost all connectivity.
Am I doing something wrong?
@tuc said:
Yet not seeing any new IPs as of now. Am I out of the boat?
IIRC you are on LAXA031, I also am on the node. Have a new IPv4, switched over early, does not route. So you are not behind at all.
I don't think they are up to LAXA031 yet. Status page shows LAXA004, LAXA005, LAXA006, LAXA007 are confirmed ready.
Still here, not exactly going well in terms of how long it's taking for various reasons, mainly more weird SolusVM changes they did in the background on whatever version. Same update that caused problems with migrations seem to cause something similar for IP changes, but only when it gets switched to the main IP address too fast.
Getting close to done for LAX1, as in it's been "done" in terms of the actual routing for a while, just working on the part where it switches main IP and removes the old one.
In any case I'm going to shift focus to other locations now so people can at least do the change, and there are definitely still some routing issues we have to wait on the DC for in some locations for some blocks because RPKI wasn't 100% ready for some when we requested them and I don't think they were revisited.
Taking servers down to LAX unfortunately getting pushed back again, but I'm simultaneously working on LAX2Z019 right now and trying to take it down with the batch, as well as NYCB027 so we can close out those other issues together, so hopefully it's worth the extra wait. Since it's the weekend now everything else logistics-wise should be easier, we don't have a ton of people using the elevators here, my car won't be blocked in, and less traffic the way I'm going.
Oh unfortunate side note, I did snap my glasses in half and I can't find the superglue, lots of squinting but I do need to figure that one out.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
I already migrated one of my servers to new IP address because my uptime notification notified me so. I have one more server that it isn't migrated yet cuz' I need to point the DNS of the server to the new IP first. Can I temporarily "run" two IP addresses to the single machine for now until the DNS changes fully propagates?
@ricANNArdo said:
I already migrated one of my servers to new IP address because my uptime notification notified me so. I have one more server that it isn't migrated yet cuz' I need to point the DNS of the server to the new IP first. Can I temporarily "run" two IP addresses to the single machine for now until the DNS changes fully propagates?
Both the old and the new will be available to use for the rest of the week, but this is completely based on whether or not SolusVM made any other changes to prevent that from happening, which is possible.
You'd have to go in manually though and add in your old IP address., since once it's technically done it would otherwise be removed from SolusVM. If you do have issues and you need the old one added back in an emergency situations, we could force it back in but I don't know how busy we'll be with everything else to be able to process the request.
after be migrated from DEN001 to LAXA007, SolusVM panel shows that the ip still the same as DEN001 before(66.59.xxxxxx), and not receive any new ip of la, the panel shows the number of ipv4 is 1, it just only 66.59.xxxx
i checked that the 66.59.xxxxx is empty route now, that means my LAXA007 vps can't be used, even it can be boot normally and view by vnc, but it doesn't have any network because there is no new IP.
is this normal? do I need to open a ticket to request for your help? @VirMach
@tuc said:
Yet not seeing any new IPs as of now. Am I out of the boat?
IIRC you are on LAXA031, I also am on the node. Have a new IPv4, switched over early, does not route. So you are not behind at all.
I don't think they are up to LAXA031 yet. Status page shows LAXA004, LAXA005, LAXA006, LAXA007 are confirmed ready.
I am on this. Only new IP is listed in the panel (no old IP). Neither new IP nor old IP work. Result: no connectivity.
Tampa is done, I don't think the routing's correct on Hivelocity's end. Still need to look into it further.
LAX2 is done and it seems like routing is correct. We had them do it wrong the last time for this location so I think they probably put a note there so they wouldn't do it like that again.
Chicago2 is waiting on Hivelocity, they set this up in a strange way, probably delayed to Monday.
Chicago1 & Miami, waiting on QuadraNet. Routing should be fine, it's related to the switches.
Looking into these, I also noticed a lot of strange issues, networking related, that are only happening with Hivelocity, all three locations. These existed before the any of the changes. We tried speaking to them about it a couple weeks ago and they just basically refused to help out and just said our switch is broken or misconfigured (they configured it for us.) This was for Chicago, where the network engineer basically definitely pretended like he checked their end, except if he actually did he'd see it was actually set up on their witch and not ours, so at least for that location he basically said "it's a problem with the switch" but it's... their switch doing the gateways.> @tetech said:
@tuc said:
Yet not seeing any new IPs as of now. Am I out of the boat?
IIRC you are on LAXA031, I also am on the node. Have a new IPv4, switched over early, does not route. So you are not behind at all.
I don't think they are up to LAXA031 yet. Status page shows LAXA004, LAXA005, LAXA006, LAXA007 are confirmed ready.
I am on this. Only new IP is listed in the panel (no old IP). Neither new IP nor old IP work. Result: no connectivity.
Looking into it, could be needing a restart server-side.
(edit) Nope, my fault here. Although the old ones should still be working, the new ones shouldn't have been changed yet. Going back to double checking this location now that the others are out of the way or waiting on DC.
@tuc said:
Yet not seeing any new IPs as of now. Am I out of the boat?
IIRC you are on LAXA031, I also am on the node. Have a new IPv4, switched over early, does not route. So you are not behind at all.
I don't think they are up to LAXA031 yet. Status page shows LAXA004, LAXA005, LAXA006, LAXA007 are confirmed ready.
I am on this. Only new IP is listed in the panel (no old IP). Neither new IP nor old IP work. Result: no connectivity.
Confirmed fixed. My VM on LAXA031 is working now with the new IP, yes it only shows the new IP, not the old one, but the new one works now.
Note: I am using a 255.255.255.128 subnet with the gateway as xx.xx.xx.129
Edit:
@gritty said: after be migrated from DEN001 to LAXA007, SolusVM panel shows that the ip still the same as DEN001
Confirmed. My VM that was in Denver and now is on LAXA007 has only one IPv4 and it is still the one from Denver and does not work.
@vgood said: now
09:54
Saturday, September 23, 2023
Eastern Time (ET)
Yep, my VM on LAX2Z019 still times out in the panel. I expect that VirMach is a little behind on this projected resolution time due to fixing new IP related issues. Let's give him a little while longer to resolve this issue.
This VM does have both the new and the old IP addresses, so that is some progress.
@tuc said:
Yet not seeing any new IPs as of now. Am I out of the boat?
IIRC you are on LAXA031, I also am on the node. Have a new IPv4, switched over early, does not route. So you are not behind at all.
I don't think they are up to LAXA031 yet. Status page shows LAXA004, LAXA005, LAXA006, LAXA007 are confirmed ready.
I am on this. Only new IP is listed in the panel (no old IP). Neither new IP nor old IP work. Result: no connectivity.
My VM on LAXA031 is working now with the new IP, yes it only shows the new IP, not the old one, but the new one works now.
Note: I am using a 255.255.255.128 subnet with the gateway as xx.xx.xx.129
@tenpera said: so migration from Seattle to LA is not happening?
We'd be so lucky!
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural. It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
SolusVM is getting so frustrating to use that I actually started working on our own control panel. It's about 0.7% done.
But yeah, the changes went from probably taking an hour on the older version to 36 hours ETA on this new one, and even then with a bunch of problems. If we do it at the same rate we used to do them just fine, it'll crash the node basically. From... changing an IP address to the main IP address. I don't know, nothing making sense anymore with them.
Oh and by making API calls for the changes, now it's causing SolusVM to miss other API calls. Really wonderful.
✅ Tampa has been completed but has routing issues, we are waiting on the datacenter. Do not switch to new IPv4 yet.
Probably should have read that before switching but welp, it's an idler, so it gonna idle even moar!
Btw. VirMach not sure if "✅" works with "routing isssues, do not switch" :P
Yeah I thought about that but I didn't feel like finding a halfway between X and checkmark emoji, plus the ticket's already in for them to fix it and then I'd have to constantly check to make sure I don't forget to update the page when it's done.
Are you not able to manually add back in your old address? If you're not let me know because it means SolusVM did push an update breaking that. To be fair to them though in this case they would actually be making an improvement, technically. It's just that for something like 8 years they didn't do anything about that. I could see why it ends up overloading the nodes and taking so long now if they did actually add in a script outside of the database that goes in and every time the main IP is changed or additional IP is removed it probably does something wise like regenerating the entire list of restrictions for all IP addresses.
@tbnuser said:
My server on RYZE.LAX-A022.VMS dropped off the internet and I had to reconfigure the network with the new IP to get it to work again.
That's not good. It does look like possibly SolusVM now fully restricts you from being able to use the old address if it's just soft removed on SolusVM. I really do think it's the situation I stated above in that case, where it's literally regenerating all the specific restrictions to avoid IPv4 stealing after every change now, something it didn't used to do.
The problem is if we don't strip away the old address then we'd have to reconfigure everyone again at the end, plus most of them have been processed. I'll see if we can shift strategy and not remove the old address for any remaining changes, and just reconfigure at the end for all but that could get messier. I'll look into it further and see how we communicated everything to see what'd end up being better in this scenario.
Okay, we're going to stop doing the automatic changes. We'll just let people change it themselves, and then proceed with automatic changes on the 29th. I've skimmed through the message in the same way anyone would read a wall of text and it definitely sounds like it would be changing on the 29th. We'll just update the page with when each node is available to change, and won't change the main IPv4 until that day.
I'm going to focus on trying to reconfigure any that were hanged and put a notice where people can contact us for their old address if desired in this case, because another 30 hours of adding the old IPv4 back and trying to make sure people get the exact old address without it breaking anything else sounds risky for no reason.
Sometimes I always wonder why unfortunate things happen to good people. Although VirMach is doing a business here, but a lot of times I feel like it is a charity, things just broke randomly and VirMach still tried his best to keep things afloat.
When VirMach migrate away from CC, a lot of people say VirMach probably cannot survive with those insane deals (come on, $0.95/yr with IPv4? That cannot even cover the cost of IP), but yet they did. Now when DediPath encountered issue, VirMach still managed to resolve it so quickly and everything seems to be smooth on my side as a user.
Sure, there are times where support can be slow or poor, but based on my ~6-7 years of usage I don't really encounter major hiccups. Even with all the inflation, as far as I know VirMach never increased recurring price of any services. (Keep in mind the pricing are rock-bottom, literally unsustainable)
Thanks VirMach, just want to show my appreciation here after following probably thousand pages of forum posts (OGF/LES), hope that one day everything can back to normal and we can see VirMach 10th anniversary deals
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
Comments
LAXA017 had a slightly different configuration than others, so it's not playing well with the network changes and causing heavy packet loss to nearby servers LAXA018 and LAXA019 as well. Having them attach KVM and should be corrected relatively painlessly after that.
It is possible for it to be complicated further if the reason for it being different than the others is something I recall correctly, in which case this node may need a motherboard swap or at the very least further attempts at BMC re-flash. In my brain though that was either LAXA027 or LAXA017, so we'll know in about half an hour.
Is there any ETC for DALZ004/DALZ007 (Network status says - waiting for equipment release.)
It's all waiting on one guy at Flexential that's apparently the only person that can deal with the problem, and he's so far decided that he doesn't very much like doing anything about it.
MY MISTAKE! It was originally at DENZ001 not SJC.
Still curious if there will be a backup restore coming.
Power down, and power back up. I'd need to know how exactly it shows with no OS installed to answer you further after that.
Done and no change. Ticket submitted.
Thanks
You had an old ISO mounted. We've been having lot of people not checking this, a lot and we've already added it to the reset button. I was going to tell you to use the reset button initially but told you the power down and power on specifically to make sure I could ask you this next series of questions.
How can we improve this further to where you do not miss that? When you initially saw it was offline, you just used the power on button instead, right? Or rather, when you were told to power it down, and then power it on, which is intentionally the wrong way of doing it, did you notice the message:
Or were you just doing all this through the full control panel?
I didn't pay attention to that message because there shouldn't be an ISO mounted. I have booted and rebooted this VM in the past (since I first set it up) and there has never been any issue with an ISO (either because one wasn't mounted or it wasn't first in the boot order). Maybe change the message to indicate that the boot order and/or presence of an ISO may have changed without the customer's intervention.
ANYWAY: There is still no OS present...???
None detected means none detected, not none.
It means the system doesn't know what's on there. This is most common when an ISO is mounted to install the OS, or an ISO was mounted but never used and SolusVM lost track of the original operating system name before the ISO mount. I've added more tooltips everywhere to improve explanations.
You had an ISO mounted from a long long time ago, and it doesn't exist anymore so it was trying to mount it still on reboot, you probably would not have noticed that previously if the service has been online since then or if the old ISO still existed on DENZ001 but not on LAXA007.
I do see this is on "hard disk only" for boot order, but I don't think that matters, this is based on SolusVM's code, not logic.
Are the new IP's for LAX that got made available today not routing yet?
45.15.143.1 seems to hit 10.254.0.7 IP when tracerouting (which is strange, I didn't think you could see a 10.x.x.x on the public Internet)
Got it! I made it to a place where I could VNC in and it appears the IP (which is still the IP from DENZ001) is not being routed.
So is this expected and we are now just waiting for new IP addresses?
Correct, I honestly don't know why it's not done yet, but I'm not the team member working on it. I may have to take over, we'll see.
Check network status page for updates.
When doing that make sure you remember you're on LAX2, not LAX.
Seattle --> LAX pushed further, likely going in a few hours. I had to spend a good amount of time on the packet loss issue and SolusVM API going slowly on the changes, and still need to wrap up other locations. LAX is almost out of the way though and that's the bulk of the changes. IP changes may have an intermission where I finally take the equipment down, we'll see how it goes.
Good news:
Is it possible to request 1 Dallas VM to be moved to LAX or upcoming OKC instead of NYC
i have a vps at DENZ001 before, yesterday i found that it changed to LAXA007 now, But the ip is not be changed, still the same as the DENZ001 before, and i tested that this ip is empty route, is this normal?
@gritty I'm in the same boat with you. I expect that they are waiting for IP blocks to start routing before assigning them to our VMs on LAXA007. Should happen soon™ Of course maybe Qi forgot all about us, maybe.
Make the same wish.
@FrankZ thanks for letting me know that I am not alone😂
maybe it must be patient enough to use Virmach service
It's 23rd today, I thought we could use new blocks from IPXO instead of the 47.87 one starting yesterday.
Found 2 IPs, 47.87.x.x and 89.33.x.x
Changed Main IP from 47 to 89 from Solus, and clicked reconfigure network. Boom, lost all connectivity.
Am I doing something wrong?
Had to revert back to 47 for it to work again.
Edit: Looks like it's not announced yet? 🤔
https://bgp.tools/prefix/89.33.192.0/24
Edit2: Node is RYZE.CHI-Z027.VMS
The Ultimate Speedtest Script | Get Instant Alerts on new LES/LET deals | Cheap VPS Deals | VirMach Flash Sales Notifier
FREE KVM VPS - FreeVPS.org | FREE LXC VPS - MicroLXC
Yet not seeing any new IPs as of now. Am I out of the boat?
Virmach Deals
@VirMach Don't code when you are asleep
Virmach Deals
IIRC you are on LAXA031, I also am on the node. Have a new IPv4, switched over early, does not route. So you are not behind at all.
I don't think they are up to LAXA031 yet. Status page shows LAXA004, LAXA005, LAXA006, LAXA007 are confirmed ready.
Just reporting what I found:
Everything else working fine, thanks VirMach for keeping them running fine
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.
the new IPs are from IPXO?
I bench YABS 24/7/365 unless it's a leap year.
Still here, not exactly going well in terms of how long it's taking for various reasons, mainly more weird SolusVM changes they did in the background on whatever version. Same update that caused problems with migrations seem to cause something similar for IP changes, but only when it gets switched to the main IP address too fast.
Getting close to done for LAX1, as in it's been "done" in terms of the actual routing for a while, just working on the part where it switches main IP and removes the old one.
In any case I'm going to shift focus to other locations now so people can at least do the change, and there are definitely still some routing issues we have to wait on the DC for in some locations for some blocks because RPKI wasn't 100% ready for some when we requested them and I don't think they were revisited.
Taking servers down to LAX unfortunately getting pushed back again, but I'm simultaneously working on LAX2Z019 right now and trying to take it down with the batch, as well as NYCB027 so we can close out those other issues together, so hopefully it's worth the extra wait. Since it's the weekend now everything else logistics-wise should be easier, we don't have a ton of people using the elevators here, my car won't be blocked in, and less traffic the way I'm going.
Oh unfortunate side note, I did snap my glasses in half and I can't find the superglue, lots of squinting but I do need to figure that one out.
^ Bound to be some Gaffer tape someplace! "There I fixed it!"
(ref. https://failblog.cheezburger.com/thereifixedit )
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
now
09:54
Saturday, September 23, 2023
Eastern Time (ET)
I already migrated one of my servers to new IP address because my uptime notification notified me so. I have one more server that it isn't migrated yet cuz' I need to point the DNS of the server to the new IP first. Can I temporarily "run" two IP addresses to the single machine for now until the DNS changes fully propagates?
You probably saw me somewhere...
Both the old and the new will be available to use for the rest of the week, but this is completely based on whether or not SolusVM made any other changes to prevent that from happening, which is possible.
You'd have to go in manually though and add in your old IP address., since once it's technically done it would otherwise be removed from SolusVM. If you do have issues and you need the old one added back in an emergency situations, we could force it back in but I don't know how busy we'll be with everything else to be able to process the request.
LAX2 should be done now, keep in mind there's still a looooooooooong queue for the auto change to main IP but you can do this yourself.
Note -- this hasn't yet been fully tested though, there might be routing issues.
after be migrated from DEN001 to LAXA007, SolusVM panel shows that the ip still the same as DEN001 before(66.59.xxxxxx), and not receive any new ip of la, the panel shows the number of ipv4 is 1, it just only 66.59.xxxx
i checked that the 66.59.xxxxx is empty route now, that means my LAXA007 vps can't be used, even it can be boot normally and view by vnc, but it doesn't have any network because there is no new IP.
is this normal? do I need to open a ticket to request for your help? @VirMach
I am on this. Only new IP is listed in the panel (no old IP). Neither new IP nor old IP work. Result: no connectivity.
Tampa is done, I don't think the routing's correct on Hivelocity's end. Still need to look into it further.
LAX2 is done and it seems like routing is correct. We had them do it wrong the last time for this location so I think they probably put a note there so they wouldn't do it like that again.
Chicago2 is waiting on Hivelocity, they set this up in a strange way, probably delayed to Monday.
Chicago1 & Miami, waiting on QuadraNet. Routing should be fine, it's related to the switches.
Looking into these, I also noticed a lot of strange issues, networking related, that are only happening with Hivelocity, all three locations. These existed before the any of the changes. We tried speaking to them about it a couple weeks ago and they just basically refused to help out and just said our switch is broken or misconfigured (they configured it for us.) This was for Chicago, where the network engineer basically definitely pretended like he checked their end, except if he actually did he'd see it was actually set up on their witch and not ours, so at least for that location he basically said "it's a problem with the switch" but it's... their switch doing the gateways.> @tetech said:
Looking into it, could be needing a restart server-side.
(edit) Nope, my fault here. Although the old ones should still be working, the new ones shouldn't have been changed yet. Going back to double checking this location now that the others are out of the way or waiting on DC.
Fixed.
Confirmed fixed. My VM on LAXA031 is working now with the new IP, yes it only shows the new IP, not the old one, but the new one works now.
Note: I am using a 255.255.255.128 subnet with the gateway as xx.xx.xx.129
Edit:
Confirmed. My VM that was in Denver and now is on LAXA007 has only one IPv4 and it is still the one from Denver and does not work.
Yep, my VM on LAX2Z019 still times out in the panel. I expect that VirMach is a little behind on this projected resolution time due to fixing new IP related issues. Let's give him a little while longer to resolve this issue.
This VM does have both the new and the old IP addresses, so that is some progress.
That's terrible, I love it keep going
The Yeti has left the building.
so migration from Seattle to LA is not happening?
I added a few other issues to my comment to make you feel better, dog face.
Confirmed fixed. Thanks.
We'd be so lucky!
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Some VPS in LAX not getting new IP yet
Virmach Deals
SolusVM is getting so frustrating to use that I actually started working on our own control panel. It's about 0.7% done.
But yeah, the changes went from probably taking an hour on the older version to 36 hours ETA on this new one, and even then with a bunch of problems. If we do it at the same rate we used to do them just fine, it'll crash the node basically. From... changing an IP address to the main IP address. I don't know, nothing making sense anymore with them.
Oh and by making API calls for the changes, now it's causing SolusVM to miss other API calls. Really wonderful.
Probably should have read that before switching but welp, it's an idler, so it gonna idle even moar!
Btw. VirMach not sure if "✅" works with "routing isssues, do not switch" :P
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
Yeah I thought about that but I didn't feel like finding a halfway between X and checkmark emoji, plus the ticket's already in for them to fix it and then I'd have to constantly check to make sure I don't forget to update the page when it's done.
Are you not able to manually add back in your old address? If you're not let me know because it means SolusVM did push an update breaking that. To be fair to them though in this case they would actually be making an improvement, technically. It's just that for something like 8 years they didn't do anything about that. I could see why it ends up overloading the nodes and taking so long now if they did actually add in a script outside of the database that goes in and every time the main IP is changed or additional IP is removed it probably does something wise like regenerating the entire list of restrictions for all IP addresses.
My server on RYZE.LAX-A022.VMS dropped off the internet and I had to reconfigure the network with the new IP to get it to work again.
Virtfuuuuuuuusion
I bench YABS 24/7/365 unless it's a leap year.
Doesn't really have an API.
OMG that is absolutely horrifying. Makes me wet and leaves me wanting. Keep going, don't stop now for the love of Peter!
The Yeti has left the building.
That's not good. It does look like possibly SolusVM now fully restricts you from being able to use the old address if it's just soft removed on SolusVM. I really do think it's the situation I stated above in that case, where it's literally regenerating all the specific restrictions to avoid IPv4 stealing after every change now, something it didn't used to do.
The problem is if we don't strip away the old address then we'd have to reconfigure everyone again at the end, plus most of them have been processed. I'll see if we can shift strategy and not remove the old address for any remaining changes, and just reconfigure at the end for all but that could get messier. I'll look into it further and see how we communicated everything to see what'd end up being better in this scenario.
Okay, we're going to stop doing the automatic changes. We'll just let people change it themselves, and then proceed with automatic changes on the 29th. I've skimmed through the message in the same way anyone would read a wall of text and it definitely sounds like it would be changing on the 29th. We'll just update the page with when each node is available to change, and won't change the main IPv4 until that day.
I'm going to focus on trying to reconfigure any that were hanged and put a notice where people can contact us for their old address if desired in this case, because another 30 hours of adding the old IPv4 back and trying to make sure people get the exact old address without it breaking anything else sounds risky for no reason.
Sometimes I always wonder why unfortunate things happen to good people. Although VirMach is doing a business here, but a lot of times I feel like it is a charity, things just broke randomly and VirMach still tried his best to keep things afloat.
When VirMach migrate away from CC, a lot of people say VirMach probably cannot survive with those insane deals (come on, $0.95/yr with IPv4? That cannot even cover the cost of IP), but yet they did. Now when DediPath encountered issue, VirMach still managed to resolve it so quickly and everything seems to be smooth on my side as a user.
Sure, there are times where support can be slow or poor, but based on my ~6-7 years of usage I don't really encounter major hiccups. Even with all the inflation, as far as I know VirMach never increased recurring price of any services. (Keep in mind the pricing are rock-bottom, literally unsustainable)
Thanks VirMach, just want to show my appreciation here after following probably thousand pages of forum posts (OGF/LES), hope that one day everything can back to normal and we can see VirMach 10th anniversary deals
食之无味 弃之可惜 - Too arduous to relish, too wasteful to discard.