@VirMach said: I mean if you reallllyyy wanted and it's super important and time sensitive I could bill you for several hours of work
I mean it's not that it's time sensitive, exactly, at this point I've been offline for 3 months now as of today, another couple weeks isn't going to hurt much more, but I need to stop dragging this out even if it means using my obscenely out of date backup.
What's the rate for that work? Can you credit the two months of downtime towards the work? (you guys fixed the VM to the point I could have restored my backup ~1mo ago so the past month is mainly on me)
You were the guy that re-installed already right? And you have an out of date backup? Just use the old backup and reply to the ticket or if you can't reply close it and open a new one and tell us not to restore it directly/not to overwrite the existing service and we can just generate a new one and restore it to that if it exists and is more recent. Just mention the old ticket # at the bottom for reference.
@VirMach said: You were the guy that re-installed already right?
I actually haven't reinstalled yet, whatever backup I restore with I'm 100% committed to, because frankly I don't think anyone has successfully merged two pleroma databases before, and I don't want to attempt to be the first lol
So as it stands, I'm happy to have you guys overwrite the current state of the VPS. Should I still make a new ticket?
@VirMach said: You were the guy that re-installed already right?
I actually haven't reinstalled yet, whatever backup I restore with I'm 100% committed to, because frankly I don't think anyone has successfully merged two pleroma databases before, and I don't want to attempt to be the first lol
So as it stands, I'm happy to have you guys overwrite the current state of the VPS. Should I still make a new ticket?
In that case just leave it as it is since you wouldn't be able to merge the databases. I'll try to fit this into the schedule soon.
@VirMach I've been waiting since August 6th. I've had a ticket in about reinstalling the OS on my replacement server, since IPMI is still down. Now the service is suspended due to billing,, even though I haven't been able to use it. Can you look into this please?
TS Ticket: 218112
Billing Ticket: 888039
@Civalo said: @VirMach I've been waiting since August 6th. I've had a ticket in about reinstalling the OS on my replacement server, since IPMI is still down. Now the service is suspended due to billing,, even though I haven't been able to use it. Can you look into this please?
TS Ticket: 218112
Billing Ticket: 888039
Really would like to get this up and running.
Same boat here (minus the suspension). I believe it's being worked on, I saw some activity on my ticket. Hoping you're next!
@Civalo said: @VirMach I've been waiting since August 6th. I've had a ticket in about reinstalling the OS on my replacement server, since IPMI is still down. Now the service is suspended due to billing,, even though I haven't been able to use it. Can you look into this please?
TS Ticket: 218112
Billing Ticket: 888039
Really would like to get this up and running.
Trying my best to get to all of these today. I handed them off to someone else who missed some. I think they'll be up next in the ticket queue after I finish these emergency SEAZ002 migrations.
@AlwaysSkint said: In other news: not only is SolusVM unresponsive but the AMS Alpha/Beta seems overloaded/crashed. Just before I started a kernel build task.
@AlwaysSkint said:
In other news: not only is SolusVM unresponsive but the AMS Alpha/Beta seems overloaded/crashed. Just before I started a kernel build task.
Maybe all my archiveteam warriors finally killed the poor thing. Rest in peace.
We're going to be getting the missing IPv4 request button ready. You'll see it on your product details page. It'll be a button called "Missing IP's?" or similar. Here's how it'll work, but this may end up completely different based on what portions our developer can or cannot do in a short period of time.
You will only have one chance to make the request. It's mostly based on an honor system but if you lie and get caught you forfeit any additional IPv4. If you don't fill it out correctly, the initial way it's fulfilled stands.
The button may not appear, in this case we'll rely on people here to let us know of their exact plan & situation and add it into the code as it's improved.
You'll pick [1] how many IPv4 addresses you're missing, [2] how many of them you actually require (chance to give any excess back and receive discount instead), and [3] what you want us to do if there aren't enough IPv4 on your node.
Discount:
This will be 10% per IPv4, one step at a time. So this means if you have a $10 a year plan and had 12 additional IPv4 you will NOT have a product that is negative $2 a year. Instead it goes $100.9 = $90.9 = $8.10.9 = $7.290.9 ... ... final price = $2.82 per year. Or another way of thinking of it is $10*0.9^12
Not enough IPv4:
You will be able to pick (default) option from a dropdown to either have us move you to the closest available server with enough IPv4 (it may end up being far way, I can tell you right now we have low IPv4 per node in Tokyo for example) or to stay on the same node and take the discount instead. We'll add whatever is available (partial fulfillment if any) and instead apply discount for the remainder if you pick this option.
Feedback? Let me know. If you have any suggested changes, it has to be realistic and simple. It can't add in extra steps or back and forth messages, it has to be one and done or else you're going to be waiting another year for us to get through all the requests.
I also know people have not had their additional IPv4 for a while so I'll try to work out a quick way of also crediting people while we process them but I don't have any information on what that would end up being. I'd say we could also offer a pro-rated cancellation and refund as an option just case all the options are disliked but there's no point because most of these are BF specials and there'd be no way to do refunds that are this old, the payment processer won't allow it and if we did it to store credit too many people would be confused/upset when it doesn't go back to their original payment method.
And once again, it's possible our developer gets back to me and says "yeah, can't do it, it's just going to be a button where there's no specifications." This is just the ideal way, if possible.
@VirMach said:
Okay I'm feeling cocky and energetic again so I'm once more taking guesses for the number of tickets I'll get completed by tonight. This time let's say whoever gets within +/-20 but still only one winning so if two or more people get it, then it's whoever is closest.
Everyone will get 1x IPv6. Any old IPv6 will break (no notification, the only people that have it were never "sold" an IPv6 or they were told it may break.) We may or may not first clean up/scrub currently assigned IPv6. If we do that we'll try to do it immediately before we add the new one.
Tokyo, Amsterdam, and Frankfurt may also receive either a /64, /56, /52, or /48
All other locations may also receive a /64, /60, or /56
All we can guarantee automatically is 1x IPv6. Anything else depends on how painful SolusVM makes it. And obviously if we do manual requests that won't really save us much time if a lot of people just end up making requests so the most I can kind of lightly "promise" is that we'll definitely give people who actually bought a plan as a "maybe" /64 IPv6 a chance to request it, not all the way back to your 2015 OpenVZ plan (unless it's relatively easy to do.)
@VirMach said:
Okay I'm feeling cocky and energetic again so I'm once more taking guesses for the number of tickets I'll get completed by tonight. This time let's say whoever gets within +/-20 but still only one winning so if two or more people get it, then it's whoever is closest.
Everyone will get 1x IPv6. Any old IPv6 will break (no notification, the only people that have it were never "sold" an IPv6 or they were told it may break.) We may or may not first clean up/scrub currently assigned IPv6. If we do that we'll try to do it immediately before we add the new one.
Tokyo, Amsterdam, and Frankfurt may also receive either a /64, /56, /52, or /48
All other locations may also receive a /64, /60, or /56
All we can guarantee automatically is 1x IPv6. Anything else depends on how painful SolusVM makes it. And obviously if we do manual requests that won't really save us much time if a lot of people just end up making requests so the most I can kind of lightly "promise" is that we'll definitely give people who actually bought a plan as a "maybe" /64 IPv6 a chance to request it, not all the way back to your 2015 OpenVZ plan (unless it's relatively easy to do.)
@tenpera said: @VirMach What happened to NY node(NYCB033X)? It is completely off, doesn't even connect from MY Service either. Just spinning.
Been working on this. AMSD030 facing the same issue, I just rebooted that one. NYCB033X looks maybe savable but about to reboot that as well once I'm done collecting data if the fix doesn't work.
Okay I hate this ticket number guessing game, it just makes us look bad.
I guess it was still overall a good day. All servers have been online for at least... 3 hours and 50 minutes and it looks like AMSD030 is about to crash again. And NYCB038 but it still counts because it's technically not down yet.. Anyway, I shall distract you guys with some IPv6 and we'll pretend like the number was so high that no one go it and definitely not so low that no one got it. The 42 guy was the closest but off by over 20. I won't say in which direction (okay just kidding, I didn't do that bad.)
Anyway what were we talking about? Oh yeah, IPv6 in Tokyo is getting deployed right now. Nevermind.
Actually I have an even better idea to dig myself a bigger grave. There's like what 30 guesses? Okay this should get the job done. I really shouldn't be doing this but it sounds fun. Everyone who made a guess (for today/yesterday, whatever you want to call it) will get an SSD2G for life if I don't either (1) answer 1,000 tickets today or (2) clear out the ticket queue via non-automated means, as in I won't just close all of them. Very bold move, let's see how it plays out. I'm going to go immediately acquire some ... cocoa beans. Meanwhile you guys can celebrate prematurely. Honestly it's probably 80/20 in your odds.
And of course if I don't get anywhere close it just means I could've definitely done it but I wanted to let you guys win.
Comments
You were the guy that re-installed already right? And you have an out of date backup? Just use the old backup and reply to the ticket or if you can't reply close it and open a new one and tell us not to restore it directly/not to overwrite the existing service and we can just generate a new one and restore it to that if it exists and is more recent. Just mention the old ticket # at the bottom for reference.
And yeah you'll get an extension.
I actually haven't reinstalled yet, whatever backup I restore with I'm 100% committed to, because frankly I don't think anyone has successfully merged two pleroma databases before, and I don't want to attempt to be the first lol
So as it stands, I'm happy to have you guys overwrite the current state of the VPS. Should I still make a new ticket?
In that case just leave it as it is since you wouldn't be able to merge the databases. I'll try to fit this into the schedule soon.
@VirMach I've been waiting since August 6th. I've had a ticket in about reinstalling the OS on my replacement server, since IPMI is still down. Now the service is suspended due to billing,, even though I haven't been able to use it. Can you look into this please?
TS Ticket: 218112
Billing Ticket: 888039
Really would like to get this up and running.
Same boat here (minus the suspension). I believe it's being worked on, I saw some activity on my ticket. Hoping you're next!
Trying my best to get to all of these today. I handed them off to someone else who missed some. I think they'll be up next in the ticket queue after I finish these emergency SEAZ002 migrations.
In other news: not only is SolusVM unresponsive but the AMS Alpha/Beta seems overloaded/crashed. Just before I started a kernel build task.
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
Good job, you broke it!
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
https://lowendspirit.com/uploads/editor/gi/ippw0lcmqowk.png
Maybe all my archiveteam warriors finally killed the poor thing. Rest in peace.
We're going to be getting the missing IPv4 request button ready. You'll see it on your product details page. It'll be a button called "Missing IP's?" or similar. Here's how it'll work, but this may end up completely different based on what portions our developer can or cannot do in a short period of time.
Discount:
This will be 10% per IPv4, one step at a time. So this means if you have a $10 a year plan and had 12 additional IPv4 you will NOT have a product that is negative $2 a year. Instead it goes $100.9 = $90.9 = $8.10.9 = $7.290.9 ... ... final price = $2.82 per year. Or another way of thinking of it is $10*0.9^12
Not enough IPv4:
You will be able to pick (default) option from a dropdown to either have us move you to the closest available server with enough IPv4 (it may end up being far way, I can tell you right now we have low IPv4 per node in Tokyo for example) or to stay on the same node and take the discount instead. We'll add whatever is available (partial fulfillment if any) and instead apply discount for the remainder if you pick this option.
Feedback? Let me know. If you have any suggested changes, it has to be realistic and simple. It can't add in extra steps or back and forth messages, it has to be one and done or else you're going to be waiting another year for us to get through all the requests.
I also know people have not had their additional IPv4 for a while so I'll try to work out a quick way of also crediting people while we process them but I don't have any information on what that would end up being. I'd say we could also offer a pro-rated cancellation and refund as an option just case all the options are disliked but there's no point because most of these are BF specials and there'd be no way to do refunds that are this old, the payment processer won't allow it and if we did it to store credit too many people would be confused/upset when it doesn't go back to their original payment method.
And once again, it's possible our developer gets back to me and says "yeah, can't do it, it's just going to be a button where there's no specifications." This is just the ideal way, if possible.
789
We're close to doing IPv6.
Everyone will get 1x IPv6. Any old IPv6 will break (no notification, the only people that have it were never "sold" an IPv6 or they were told it may break.) We may or may not first clean up/scrub currently assigned IPv6. If we do that we'll try to do it immediately before we add the new one.
Tokyo, Amsterdam, and Frankfurt may also receive either a /64, /56, /52, or /48
All other locations may also receive a /64, /60, or /56
All we can guarantee automatically is 1x IPv6. Anything else depends on how painful SolusVM makes it. And obviously if we do manual requests that won't really save us much time if a lot of people just end up making requests so the most I can kind of lightly "promise" is that we'll definitely give people who actually bought a plan as a "maybe" /64 IPv6 a chance to request it, not all the way back to your 2015 OpenVZ plan (unless it's relatively easy to do.)
@VirMach What happened to NY node(NYCB033X)? It is completely off, doesn't even connect from MY Service either. Just spinning.
"Operation Timed Out After 90001 Milliseconds With 0 Bytes Received"
129
Sultan Muda - Amazon Store
212
Finger poised, at the ready!
It wisnae me! A big boy done it and ran away.
NVMe2G for life! until death (the end is nigh)
174
Powerful Core i9 VPS (aff)| List of all VirMach VPS (aff)
I'll guess 387
I'll guess 10
225
I bench YABS 24/7/365 unless it's a leap year.
awesome. yoursunny can finally get off your back
everyone basically means every location right?
I bench YABS 24/7/365 unless it's a leap year.
225.
I bench YABS 24/7/365 unless it's a leap year.
Been working on this. AMSD030 facing the same issue, I just rebooted that one. NYCB033X looks maybe savable but about to reboot that as well once I'm done collecting data if the fix doesn't work.
NYCB033X came back working.
Hi,
Don't want to bother or get privileged here, but if possible, please help me activate invoice #1484691. Thanks.
Any updates on IPv4 PTR?
Expecting PTRs on IPv6 would probably be lucrative right?
With all of the other work going on I will estimate
189 tickets completed
Okay I hate this ticket number guessing game, it just makes us look bad.
I guess it was still overall a good day. All servers have been online for at least... 3 hours and 50 minutes and it looks like AMSD030 is about to crash again. And NYCB038 but it still counts because it's technically not down yet.. Anyway, I shall distract you guys with some IPv6 and we'll pretend like the number was so high that no one go it and definitely not so low that no one got it. The 42 guy was the closest but off by over 20. I won't say in which direction (okay just kidding, I didn't do that bad.)
Anyway what were we talking about? Oh yeah, IPv6 in Tokyo is getting deployed right now. Nevermind.
Actually I have an even better idea to dig myself a bigger grave. There's like what 30 guesses? Okay this should get the job done. I really shouldn't be doing this but it sounds fun. Everyone who made a guess (for today/yesterday, whatever you want to call it) will get an SSD2G for life if I don't either (1) answer 1,000 tickets today or (2) clear out the ticket queue via non-automated means, as in I won't just close all of them. Very bold move, let's see how it plays out. I'm going to go immediately acquire some ... cocoa beans. Meanwhile you guys can celebrate prematurely. Honestly it's probably 80/20 in your odds.
And of course if I don't get anywhere close it just means I could've definitely done it but I wanted to let you guys win.
I'll count that as a guess.