@NerdUno said:
Some of these Virmach folks need to find a new line of work. I've been doing this for over 30 years, and I've never seen critical service outages anywhere close to what Virmach is reporting IN REAL TIME AGAIN. Our server which weathered the last fiasco wasn't quite so lucky this time around. Here's a tip: SAVE YOUR MONEY AND GO ELSEWHERE!
SEAZ009 is offline for 2-3 days and being worked on.
SEAZ010 is offline for 1-2 days and waiting on datacenter.
Nothing else is offline. Some nodes have partial issues but already addressed. Out of all the times you could've made this comment right now is the least "critical" and I'm assuming it just means you were recently affected on one of these nodes.
After it's back online and you're able to get your data off, create a ticket provide the ticket # here after clicking cancel and I'll provide you a refund so you can follow your own advice, save your money and go elsewhere.
I'm on SEAZ002, have opened a ticket, and networking is dead as a doornail.
@NerdUno said:
I'm on SEAZ002, have opened a ticket, and networking is dead as a doornail.
SEAZ002 isn't even down. There's 2% of VMs offline but that's a normal amount as some people power down their services to that level when they're not using it. Disks are all healthy. Uptime 81 days. CPU is at 25% or so. Active memory usage around 50% and someone is bursting I/O right now over the last 30 minutes but otherwise low usage there too. Load is at 8-10 which is low.
I see one ticket about SEAZ002 so I'll assume it's yours. For some reason SolusVM assigned the IP incorrectly here so when anti-IP stealing and ARP attack feature was turned on it broke your connection. I'm handling the ticket now.
@Jab said: [ and there is no new IP in panel and/or ticket for NYCB035 and NYCB036 (Dedipath), but there is IP for NYCB014 (PSINet/Cogent) - but this I will assume it's on purpose.
and nothing for DENZ001 too, but I think you mentioned this a later batch]
These aren't changing.
@Jab said: I wanted to comment again that I have no ticket for FFME01 IP migration, but I have for FFME02 and FFME04... but I see secondary IP added to WHMCS, but no ticket, at all.
@DanSummer said: @VirMach DALZ008 seems to be having some problem (not booting).
Routing issue. Trying to look into it and see what we can do, same with QN LAX. Already reported to the DCs as well. I don't know what specifically happened outside of the IRR issue but it looks like a lot of routes have problems since the day we discovered it, including even some routing from our office in LA.
Hopefully it can be escalated to the appropriate carriers. DALZ008 seems to have problems to NYC, Virginia, Turkey, Saudi Arabia, and most of China.
We were able to get some people off but it went offline pretty quickly. I've already requested the DC try to bring it back up and monitoring so we can continue the emergency migrations.
Always interesting when people come in full of energy and ready to shit on Virmach for what they think the issue was... But don't have the energy after to even apologize or thank them for working on their issue which was not as they portrayed it.
Must be that 30+ years of "experience" making them so very tired that they need to go take a nap.
LAX QN is back to normal. I've investigated this and it 100% looks like internet backbone issue. Some carrier in between LAX and Dallas and earlier LAX and LAX was having issues.
It went from Charter LAX --> QN and INAP having speed issues, to some issues between Cloudflare LAX and OVH Virginia, and a few others in between such as INAP NJ having issues to varying degrees. DALZ008 to SolusVM couldn't reach eachother at all, but they can finally reach eachother now with no changes on our end, except they still refuse to connect and DALZ008 is having its previous issues as well.
I'll look into it further but it seems like we just have to wait until the carriers involved figure it out. Seems like we were the only ones to notice early on as OVH just posted a vague network issue tonight and then quickly removed it.
Great,
My vps is finally out of SJCZ005 node after two months down.
@VirMach said:
We were able to get some people off but it went offline pretty quickly. I've already requested the DC try to bring it back up and monitoring so we can continue the emergency migrations.
If there's any sense, it'll be unavailable for the foreseeable. Try Chicago instead; on 2nd thoughts don't!
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).
@yoursunny said:
It's two days before the IP change.
New IP subnet is not yet announced in BGP.
I predict the IP change will be delayed.
Switch configuration for most locations has been completed. The IP addresses were finally assigned to us and are getting announced. There's a small chance some locations may have to be delayed to Friday but I think we're finally in a position where I can say that any major delay has been avoided.
Phoenix has been fully completed and just waiting for the official switch-over on Thursday (or you can do it early.)
I'll keep the network status page updated throughout the day.
@Daevien said:
Always interesting when people come in full of energy and ready to shit on Virmach for what they think the issue was... But don't have the energy after to even apologize or thank them for working on their issue which was not as they portrayed it.
Must be that 30+ years of "experience" making them so very tired that they need to go take a nap.
Actually, @Daevien, the issue was exactly as I described. All network connectivity was down FOR DAYS. I fully appreciate that isn't that long in Virmach time, but it's intolerable in most businesses including mine. By @VirMach's own admission, the misconfiguration was solely the result of actions taken by them which blew the networking out of the water. @VirMach clearly had no clue there was even a problem until I opened a ticket which went into the pit with a thousand other open tickets. Only when I later complained about it here did the matter get addressed. And I'm supposed to apologize because they restored service that I'm paying for?? You may recall that the Soup Nazi got away with bad behavior because the soup was good. Wish I could say the same for Virmach.
@yoursunny said:
It's two days before the IP change.
New IP subnet is not yet announced in BGP.
I predict the IP change will be delayed.
Switch configuration for most locations has been completed. The IP addresses were finally assigned to us and are getting announced. There's a small chance some locations may have to be delayed to Friday but I think we're finally in a position where I can say that any major delay has been avoided.
Phoenix has been fully completed and just waiting for the official switch-over on Thursday (or you can do it early.)
I'll keep the network status page updated throughout the day.
That's good news; is Chicago on the "small chance of delay" list, or should I start obsessively hitting F5 on the network status page? :-)
@NerdUno said: Actually, @Daevien, the issue was exactly as I described. All network connectivity was down FOR DAYS. I fully appreciate that isn't that long in Virmach time, but it's intolerable in most businesses including mine. By @VirMach's own admission, the misconfiguration was solely the result of actions taken by them which blew the networking out of the water. @VirMach clearly had no clue there was even a problem until I opened a ticket which went into the pit with a thousand other open tickets. Only when I later complained about it here did the matter get addressed. And I'm supposed to apologize because they restored service that I'm paying for?? You may recall that the Soup Nazi got away with bad behavior because the soup was good. Wish I could say the same for Virmach.
There's a difference between coming here, immediately telling us to find a new line of work, mentioning you've been doing "this" for 30 years, mentioning critical service outages, while implying that your VPS on a server not included in any outages is part of them, coming here just to tell everyone else to follow advice that you clearly yourself were not interested in, and coming here to report the actual issue you were facing which is that your clearly "online" service was having connectivity issues and your priority ticket had gone unanswered for 18 hours.
So congratulations, you did get it addressed a few hours sooner.
@NerdUno said: By @VirMach's own admission, the misconfiguration was solely the result of actions taken by them which blew the networking out of the water.
I'll write it out again as you've misinterpreted. This was due to a bug in the third party software we use, that is not open source, and for some reason the industry-standard for a decade when it comes to affordable virtual servers. I'm sure you can twist our words to make it seem like it's somehow in the end our fault.
@NerdUno said: @VirMach clearly had no clue there was even a problem until I opened a ticket which went into the pit with a thousand other open tickets
But yes this is a case where it would have been difficult for us to identify it quickly on our own without a ticket being created. Your ticket didn't go into a pit of a thousand other tickets, we have the numbers down, and it was actually in the top 20 tickets view and we would have gotten to it most likely a few hours after your comment.
@NerdUno said: Only when I later complained about it here did the matter get addressed. And I'm supposed to apologize because they restored service that I'm paying for?? You may recall that the Soup Nazi got away with bad behavior because the soup was good. Wish I could say the same for Virmach.
Once again congratulations. By making false claims, you grabbed my attention and were able to skip a few tickets in line and put yourself ahead of others. All that was necessary was my genuine concern that anything you initially said was possibly true and thus unknown by us, and affecting everyone on your node, so you got me to investigate it in an inefficient manner.
The best part of this is that you stated that you believed we were having many catastrophic failures, and did not take that as an opportunity to perhaps empathize. Instead you saw that as us, according to you, were have the HIGHEST number of catastrophic issues you've EVER seen, and even then, you could not justify waiting more than 18 hours for your ticket to be answered before coming here to exaggerate the situation and only care about yourself. In your own words, this was something you've never seen before yet you expected us to be able to still get back to you for your individual issue, while everything else is on fire, to assist you and you only first.
Hey, at least you're revealing your true motives. It doesn't seem like your goal was to help anyone else by getting them to avoid us, it was to get your service online. Which is fine.
@NerdUno said: Here's a tip: SAVE YOUR MONEY AND GO ELSEWHERE!
I still highly recommend you contact us based on your own advice as someone who has been doing "this" for 30 years. I am offering you a full refund. It's obviously your choice to make, but remember that it was offered. I'll even go through in this case and refund any store credits involved in the purchase, so that's money back to your card/PayPal.
Based on your continued comments you clearly do not trust our abilities so I do not understand under any circumstances why you'd want to continue with us when I'm offering you a policy exception refund in this case.
@yoursunny said:
It's two days before the IP change.
New IP subnet is not yet announced in BGP.
I predict the IP change will be delayed.
Switch configuration for most locations has been completed. The IP addresses were finally assigned to us and are getting announced. There's a small chance some locations may have to be delayed to Friday but I think we're finally in a position where I can say that any major delay has been avoided.
Phoenix has been fully completed and just waiting for the official switch-over on Thursday (or you can do it early.)
I'll keep the network status page updated throughout the day.
That's good news; is Chicago on the "small chance of delay" list, or should I start obsessively hitting F5 on the network status page? :-)
Chicago has two Chicagos. I'm fairly confident in both being completed soon, but QN Chicago has a higher likelihood of being completed first based on previous response times in terms of networking.
@yoursunny said:
It's two days before the IP change.
New IP subnet is not yet announced in BGP.
I predict the IP change will be delayed.
Switch configuration for most locations has been completed. The IP addresses were finally assigned to us and are getting announced. There's a small chance some locations may have to be delayed to Friday but I think we're finally in a position where I can say that any major delay has been avoided.
Phoenix has been fully completed and just waiting for the official switch-over on Thursday (or you can do it early.)
I'll keep the network status page updated throughout the day.
That's good news; is Chicago on the "small chance of delay" list, or should I start obsessively hitting F5 on the network status page? :-)
Chicago has two Chicagos. I'm fairly confident in both being completed soon, but QN Chicago has a higher likelihood of being completed first based on previous response times in terms of networking.
I'm on CHIZ001, but I have no idea which Chicago that is (although traceroute would suggest QN so hopefully yay!)
(Side note against all the tales of woe; aside from a brief outage caused by an unexpected IP change a few months ago, this VPS has been quietly and reliably rumbling on so it's not all doom and gloom)
@windytime said: @VirMach : When will the JP location available for order new VPS?
We're still working this out. We have about 20 servers left to send out and we're deciding how many to send where. Japan does have one server that's awaiting setup so it may go back in stock briefly but we have to make sure to lock everything down first which has delayed it.
This may come as a surprise to you, @VirMach, but we monitor the offerings and performance of dozens of providers worldwide so that our users can make informed decisions moving forward. The easy way would be to simply write your service off and move on. But we have a number of users that already use your platform so we'll hang in there, but I appreciate the refund offer. And hopefully your service will get over these speed bumps and improve in coming months. Best of luck.
Sidenote: Never mind the quality, feel the width - said facetiously with approx. 40 years IT "experience".
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).
xTom coming through again with ridiculously good support. I think within an hour of me firing off the LOA they have it all set up for Frankfurt and working on Amsterdam now (taking longer because of our initial big VLAN but being worked on now.)
I'll switch main IPs after validating and then make the status update so those locations you should be able to use the new IPs soon.
(Was talking about that earlier: 2 New Yorks, 2 Kansas' .. )
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).
@lysdev said:
New IPs on MIAZ012 seem to be working. I've manually added mine and it's now accessible.
Yep, was just about to update everyone. Network status page updated.
Miami, QN LAX, QN Chicago, Frankfurt, and Amsterdam all ready. Amsterdam is still technically not accessible globally as it just got announced but should be good in the next hour or two. We haven't yet updated the main IPs but you can technically change it sooner.
LOA for Dedipath/INAP and Hivelocity have errors in them, my fault. I crammed in a /22 last minute at the wrong place and everything got offset in a way where these are technically not valid. I've already requested a correction.
Oh and Dedipath/INAP Phoenix was already done yesterday.
The IP changes have worked smoothly for me so far. It is good to have an overlap where both old & new are functional.
I have experienced much worse with other providers, e.g. hard switch with no notice, only informed of new IP after it is active, /etc/network/interfaces rewritten causing loss of wireguard interface, etc.
@tetech said:
The IP changes have worked smoothly for me so far. It is good to have an overlap where both old & new are functional.
I have experienced much worse with other providers, e.g. hard switch with no notice, only informed of new IP after it is active, /etc/network/interfaces rewritten causing loss of wireguard interface, etc.
I'm waiting to see what happens. Wasn't sure how smooth it was going to go so I converted several of my machines to use DHCP figuring when it happened I'd just reset the interface and it'd all just be there. Tables haven't updated yet though.
I am wondering if I need to have Syncthing Discovery (UDP Port 21027) enabled when I only explicitly want to use Syncthing on my LAN. It seems to be enabled by default.
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).
@VirMach any i.p update as to NYCB033X is concerned?
@soulchief said:
I've got all my ip's updated and working except for NY and DAL. Still waiting for those ip's to work.
So around 48x /24 blocks or servers remaining. That's NYC, Seattle, Dallas, Atlanta, San Jose, Tampa, HV Chicago, and HV Los Angeles. The rest which is the majority have already completed.
Still waiting on the LOA situation to be rectified and really hoping it doesn't cause a delay past Thursday.
I have experienced much worse with other providers, e.g. hard switch with no notice, only informed of new IP after it is active, /etc/network/interfaces rewritten causing loss of wireguard interface, etc.
Hey that sounds like us in a difficult situation.
I hope the last part doesn't happen this time but it's technically a possibility. If your service is offline, not accepting ping, or the script errors out, it might try to reconfigure it again.
@AlwaysSkint said:
AMSD029 just worked smoothly for me and I re-established it as a nameserver.
Network broadcasters are at it already:
I am wondering if I need to have Syncthing Discovery (UDP Port 21027) enabled when I only explicitly want to use Syncthing on my LAN. It seems to be enabled by default.
Amsterdam is going to have it's VLANs split off after this is over. Most likely Friday or Monday.
One CHI successfully changed - I'll leave for other to auto-migrate (for curiosity's sake).
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).
@Eason said: @VirMach It's been rumored on loc recently. Will you start to migrate from F12 to JP for an additional $2 per month? is this real?
What a weirdly specific rumor. I'm trying to think if it's a misinterpretation of something I said but that's definitely not planned. I will say though that in the past our tools were never built for a location possibly costing more so if we continue the upcharge for Tokyo then we obviously would need to figure out how to do it officially since otherwise everyone would just buy one location then migrate to Tokyo to avoid the fee.
We've obviously already noticed that happening but that's technically fine to do right now but wouldn't be a permanent solution.
IMO my favorite thing to do would be to just have Tokyo at the same price as all the other locations if everyone would just behave and form an orderly queue but that's an unrealistic thing to want when it's clearly more popular. The other part is that Tokyo ends up being more tickets, more everything, even though NYC and LAX have more servers and customers.
But short answer: no, not true. Currently undetermined what we'll do.
But short answer: no, not true. Currently undetermined what we'll do.
Lmao. Don't you think it's a genius idea that MJJs come up in your stead?
Adding few bucks a month and you get all the Tokyo illegal immigrants, abusers etc. moving their asses out on their own.
Probably more efficient of a deterrent than previous options listed.
But short answer: no, not true. Currently undetermined what we'll do.
Lmao. Don't you think it's a genius idea that MJJs come up in your stead?
Adding few bucks a month and you get all the Tokyo illegal immigrants, abusers etc. moving their asses out on their own.
Probably more efficient of a deterrent than previous options listed.
Okay I started hearing back from people on storage. I'll be a little vague to maintain privacy.
One guy brought up how the server has gone down (he was one of the people that caused it to lock up once or twice, well one of the main pieces to it happening) in the ticket as if that changes anything in his favor, but he's essentially using it to do video processing. I explained to him that he should consider not using HDD storage for that, so we'll see if he agrees and expands his setup to maybe include an NVMe server to actually do the processing before he stores the large video files on the storage server.
Second guy said he uploads files at one location and downloads files at a second location. That's an interesting way to describe a Plex server that has 100-150 different people connected to it right now. Not that I care, it just means we can't really help him reduce the usage so I hope he's got it figured out.
Third guy said he's using it as a backup server with a script that's not optimized. Strange, he's doing a lot more reads than writes. The said script must be called "qBittorent." But again I hope he figures out how to fix his settings. I would have loved to help him out to reduce the usage but he's not interested either.
By the way I want to re-iterate that I am not in any way accessing the customer's service, just basic tools that show general outputs. Like if an IP is using port 80 then you know they're running a webserver, etc.
Jesus, these could be semi-OK if people just didn't use it as a dedicated CDN, video processing, and streaming site. Even the Plex guy would probably be fine if he wasn't literally mass file sharing on Plex. I guess no one's ever heard of use cases or efficiency.
Comments
It's two days before the IP change.
New IP subnet is not yet announced in BGP.
I predict the IP change will be delayed.
We accept Karma donations for the last flan. 🍮 affbrr
You can migrate users with high long-term traffic usage to other locations.
I'm on SEAZ002, have opened a ticket, and networking is dead as a doornail.
SEAZ002 isn't even down. There's 2% of VMs offline but that's a normal amount as some people power down their services to that level when they're not using it. Disks are all healthy. Uptime 81 days. CPU is at 25% or so. Active memory usage around 50% and someone is bursting I/O right now over the last 30 minutes but otherwise low usage there too. Load is at 8-10 which is low.
I see one ticket about SEAZ002 so I'll assume it's yours. For some reason SolusVM assigned the IP incorrectly here so when anti-IP stealing and ARP attack feature was turned on it broke your connection. I'm handling the ticket now.
I really hope not but it seems like a possibility with how long they're taking on everything.
These aren't changing.
No idea if you want to check that. id=613983
I'll see what happened with FFME
@VirMach DALZ008 seems to be having some problem (not booting).
shame, SJCZ005 offline again.
Routing issue. Trying to look into it and see what we can do, same with QN LAX. Already reported to the DCs as well. I don't know what specifically happened outside of the IRR issue but it looks like a lot of routes have problems since the day we discovered it, including even some routing from our office in LA.
Hopefully it can be escalated to the appropriate carriers. DALZ008 seems to have problems to NYC, Virginia, Turkey, Saudi Arabia, and most of China.
We were able to get some people off but it went offline pretty quickly. I've already requested the DC try to bring it back up and monitoring so we can continue the emergency migrations.
Always interesting when people come in full of energy and ready to shit on Virmach for what they think the issue was... But don't have the energy after to even apologize or thank them for working on their issue which was not as they portrayed it.
Must be that 30+ years of "experience" making them so very tired that they need to go take a nap.
LAX QN is back to normal. I've investigated this and it 100% looks like internet backbone issue. Some carrier in between LAX and Dallas and earlier LAX and LAX was having issues.
It went from Charter LAX --> QN and INAP having speed issues, to some issues between Cloudflare LAX and OVH Virginia, and a few others in between such as INAP NJ having issues to varying degrees. DALZ008 to SolusVM couldn't reach eachother at all, but they can finally reach eachother now with no changes on our end, except they still refuse to connect and DALZ008 is having its previous issues as well.
I'll look into it further but it seems like we just have to wait until the carriers involved figure it out. Seems like we were the only ones to notice early on as OVH just posted a vague network issue tonight and then quickly removed it.
Great,
My vps is finally out of SJCZ005 node after two months down.
@VirMach : When will the JP location available for order new VPS?
If there's any sense, it'll be unavailable for the foreseeable. Try Chicago instead; on 2nd thoughts don't!
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).
Switch configuration for most locations has been completed. The IP addresses were finally assigned to us and are getting announced. There's a small chance some locations may have to be delayed to Friday but I think we're finally in a position where I can say that any major delay has been avoided.
Phoenix has been fully completed and just waiting for the official switch-over on Thursday (or you can do it early.)
I'll keep the network status page updated throughout the day.
Actually, @Daevien, the issue was exactly as I described. All network connectivity was down FOR DAYS. I fully appreciate that isn't that long in Virmach time, but it's intolerable in most businesses including mine. By @VirMach's own admission, the misconfiguration was solely the result of actions taken by them which blew the networking out of the water. @VirMach clearly had no clue there was even a problem until I opened a ticket which went into the pit with a thousand other open tickets. Only when I later complained about it here did the matter get addressed. And I'm supposed to apologize because they restored service that I'm paying for?? You may recall that the Soup Nazi got away with bad behavior because the soup was good. Wish I could say the same for Virmach.
That's good news; is Chicago on the "small chance of delay" list, or should I start obsessively hitting F5 on the network status page? :-)
There's a difference between coming here, immediately telling us to find a new line of work, mentioning you've been doing "this" for 30 years, mentioning critical service outages, while implying that your VPS on a server not included in any outages is part of them, coming here just to tell everyone else to follow advice that you clearly yourself were not interested in, and coming here to report the actual issue you were facing which is that your clearly "online" service was having connectivity issues and your priority ticket had gone unanswered for 18 hours.
So congratulations, you did get it addressed a few hours sooner.
I'll write it out again as you've misinterpreted. This was due to a bug in the third party software we use, that is not open source, and for some reason the industry-standard for a decade when it comes to affordable virtual servers. I'm sure you can twist our words to make it seem like it's somehow in the end our fault.
But yes this is a case where it would have been difficult for us to identify it quickly on our own without a ticket being created. Your ticket didn't go into a pit of a thousand other tickets, we have the numbers down, and it was actually in the top 20 tickets view and we would have gotten to it most likely a few hours after your comment.
Once again congratulations. By making false claims, you grabbed my attention and were able to skip a few tickets in line and put yourself ahead of others. All that was necessary was my genuine concern that anything you initially said was possibly true and thus unknown by us, and affecting everyone on your node, so you got me to investigate it in an inefficient manner.
The best part of this is that you stated that you believed we were having many catastrophic failures, and did not take that as an opportunity to perhaps empathize. Instead you saw that as us, according to you, were have the HIGHEST number of catastrophic issues you've EVER seen, and even then, you could not justify waiting more than 18 hours for your ticket to be answered before coming here to exaggerate the situation and only care about yourself. In your own words, this was something you've never seen before yet you expected us to be able to still get back to you for your individual issue, while everything else is on fire, to assist you and you only first.
Hey, at least you're revealing your true motives. It doesn't seem like your goal was to help anyone else by getting them to avoid us, it was to get your service online. Which is fine.
I still highly recommend you contact us based on your own advice as someone who has been doing "this" for 30 years. I am offering you a full refund. It's obviously your choice to make, but remember that it was offered. I'll even go through in this case and refund any store credits involved in the purchase, so that's money back to your card/PayPal.
Based on your continued comments you clearly do not trust our abilities so I do not understand under any circumstances why you'd want to continue with us when I'm offering you a policy exception refund in this case.
Chicago has two Chicagos. I'm fairly confident in both being completed soon, but QN Chicago has a higher likelihood of being completed first based on previous response times in terms of networking.
I'm on CHIZ001, but I have no idea which Chicago that is (although traceroute would suggest QN so hopefully yay!)
(Side note against all the tales of woe; aside from a brief outage caused by an unexpected IP change a few months ago, this VPS has been quietly and reliably rumbling on so it's not all doom and gloom)
We're still working this out. We have about 20 servers left to send out and we're deciding how many to send where. Japan does have one server that's awaiting setup so it may go back in stock briefly but we have to make sure to lock everything down first which has delayed it.
This may come as a surprise to you, @VirMach, but we monitor the offerings and performance of dozens of providers worldwide so that our users can make informed decisions moving forward. The easy way would be to simply write your service off and move on. But we have a number of users that already use your platform so we'll hang in there, but I appreciate the refund offer. And hopefully your service will get over these speed bumps and improve in coming months. Best of luck.
Sidenote: Never mind the quality, feel the width - said facetiously with approx. 40 years IT "experience".
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).
We accept Karma donations for the last flan. 🍮 affbrr
xTom coming through again with ridiculously good support. I think within an hour of me firing off the LOA they have it all set up for Frankfurt and working on Amsterdam now (taking longer because of our initial big VLAN but being worked on now.)
I'll switch main IPs after validating and then make the status update so those locations you should be able to use the new IPs soon.
(Was talking about that earlier: 2 New Yorks, 2 Kansas' .. )
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).
It seems that the thousandfold bandwidth issue caused by the migration has been fixed. Good job!
New IPs on MIAZ012 seem to be working. I've manually added mine and it's now accessible.
VirMach vs NerdUno drama, narrated for your listening entertainment.
We accept Karma donations for the last flan. 🍮 affbrr
Looking forward to hearing the musical!
yabs daddy
Yep, was just about to update everyone. Network status page updated.
Miami, QN LAX, QN Chicago, Frankfurt, and Amsterdam all ready. Amsterdam is still technically not accessible globally as it just got announced but should be good in the next hour or two. We haven't yet updated the main IPs but you can technically change it sooner.
LOA for Dedipath/INAP and Hivelocity have errors in them, my fault. I crammed in a /22 last minute at the wrong place and everything got offset in a way where these are technically not valid. I've already requested a correction.
Oh and Dedipath/INAP Phoenix was already done yesterday.
Hi... Welcome to page 100... Plenty of "refound" offers but none taken :-)
yes --- i did get my account credited. maybe others now follow
VIRRRRR VISHHHHH refund NOW -
The Bus Killer
Have you tried turning it off and on again?The IP changes have worked smoothly for me so far. It is good to have an overlap where both old & new are functional.
I have experienced much worse with other providers, e.g. hard switch with no notice, only informed of new IP after it is active, /etc/network/interfaces rewritten causing loss of wireguard interface, etc.
I'm waiting to see what happens. Wasn't sure how smooth it was going to go so I converted several of my machines to use DHCP figuring when it happened I'd just reset the interface and it'd all just be there. Tables haven't updated yet though.
AMSD029 just worked smoothly for me and I re-established it as a nameserver.
Network broadcasters are at it already:
A syncthing, apparently.
1st page of DuckDuckGo..
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).
@VirMach any i.p update as to NYCB033X is concerned?
I've got all my ip's updated and working except for NY and DAL. Still waiting for those ip's to work.
So around 48x /24 blocks or servers remaining. That's NYC, Seattle, Dallas, Atlanta, San Jose, Tampa, HV Chicago, and HV Los Angeles. The rest which is the majority have already completed.
Still waiting on the LOA situation to be rectified and really hoping it doesn't cause a delay past Thursday.
Hey that sounds like us in a difficult situation.
I hope the last part doesn't happen this time but it's technically a possibility. If your service is offline, not accepting ping, or the script errors out, it might try to reconfigure it again.
Amsterdam is going to have it's VLANs split off after this is over. Most likely Friday or Monday.
@VirMach It's been rumored on loc recently. Will you start to migrate from F12 to JP for an additional $2 per month? is this real?
One CHI successfully changed - I'll leave for other to auto-migrate (for curiosity's sake).
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 clicked Main IP button in SolusVM.
vps1 is now online with new IP.
Checklist of where I had to update IP address:
$HOME/.ssh/config/etc/netplan/01-netcfg.yamlbinddirectivesWe accept Karma donations for the last flan. 🍮 affbrr
What a weirdly specific rumor. I'm trying to think if it's a misinterpretation of something I said but that's definitely not planned. I will say though that in the past our tools were never built for a location possibly costing more so if we continue the upcharge for Tokyo then we obviously would need to figure out how to do it officially since otherwise everyone would just buy one location then migrate to Tokyo to avoid the fee.
We've obviously already noticed that happening but that's technically fine to do right now but wouldn't be a permanent solution.
IMO my favorite thing to do would be to just have Tokyo at the same price as all the other locations if everyone would just behave and form an orderly queue but that's an unrealistic thing to want when it's clearly more popular. The other part is that Tokyo ends up being more tickets, more everything, even though NYC and LAX have more servers and customers.
But short answer: no, not true. Currently undetermined what we'll do.
Tomorrow's headline: VirMach destroyed my billion dollar business
I ahead do ip switching for my VMs. Hopefully @VirMach 's will not switch them back
Virmach Deals
Lmao. Don't you think it's a genius idea that MJJs come up in your stead?
Adding few bucks a month and you get all the Tokyo illegal immigrants, abusers etc. moving their asses out on their own.
Probably more efficient of a deterrent than previous options listed.
Wow Page #100.
Congratz everyone.
https://microlxc.net/
100 Pages - free VPS?
Okay I started hearing back from people on storage. I'll be a little vague to maintain privacy.
One guy brought up how the server has gone down (he was one of the people that caused it to lock up once or twice, well one of the main pieces to it happening) in the ticket as if that changes anything in his favor, but he's essentially using it to do video processing. I explained to him that he should consider not using HDD storage for that, so we'll see if he agrees and expands his setup to maybe include an NVMe server to actually do the processing before he stores the large video files on the storage server.
Second guy said he uploads files at one location and downloads files at a second location. That's an interesting way to describe a Plex server that has 100-150 different people connected to it right now. Not that I care, it just means we can't really help him reduce the usage so I hope he's got it figured out.
Third guy said he's using it as a backup server with a script that's not optimized. Strange, he's doing a lot more reads than writes. The said script must be called "qBittorent." But again I hope he figures out how to fix his settings. I would have loved to help him out to reduce the usage but he's not interested either.
By the way I want to re-iterate that I am not in any way accessing the customer's service, just basic tools that show general outputs. Like if an IP is using port 80 then you know they're running a webserver, etc.
Jesus, these could be semi-OK if people just didn't use it as a dedicated CDN, video processing, and streaming site. Even the Plex guy would probably be fine if he wasn't literally mass file sharing on Plex. I guess no one's ever heard of use cases or efficiency.