@wuyicheng538 said:
While I know @virmach is busy with Black Friday orders, I wanted to give you a quick reminder not to forget to fix DALZ004 and DALZ007.
Thank you for the reminder, I had completely forgotten these nodes even exist and definitely was not already coordinating with Flexential for them per the previous network status update.
@wuyicheng538 said:
While I know @virmach is busy with Black Friday orders, I wanted to give you a quick reminder not to forget to fix DALZ004 and DALZ007.
Thank you for the reminder, I had completely forgotten these nodes even exist and definitely was not already coordinating with Flexential for them per the previous network status update.
@wuyicheng538 said:
While I know @virmach is busy with Black Friday orders, I wanted to give you a quick reminder not to forget to fix DALZ004 and DALZ007.
Thank you for the reminder, I had completely forgotten these nodes even exist and definitely was not already coordinating with Flexential for them per the previous network status update.
Send DALZ004 and DALZ007 to Tokyo, please. Everyone will wish for its smooth arrival.
@wuyicheng538 said:
While I know @virmach is busy with Black Friday orders, I wanted to give you a quick reminder not to forget to fix DALZ004 and DALZ007.
Thank you for the reminder, I had completely forgotten these nodes even exist and definitely was not already coordinating with Flexential for them per the previous network status update.
Will there be any compensation activities for DALZ004 and DALZ007 users? This outage has lasted for a long time.
@VirMach My ticket opened at last week for duplicate payment caused by paypal subscription is still waiting for your resolve.
Could you please take a minute for this issue?
It won't need to much time to either refund the duplicated payment or add the amount to my account.
Thank you!
Thank you for reaching out to us regarding the network connection issue with your VM (id=711334) on node ATL-Z006 with IPv4 66.59.198.xxx. I apologize for any inconvenience this may have caused.
Based on your description, it seems that the IP address 66.59.198.xxx is being assigned to another VM as well, causing the network connection to drop intermittently. However, the VM remains accessible through VNC with no other issues except for the inability to reach the outside network during the connection drops.
The error message you encountered in your logs, "ifup-eth: Error, some other host (00:16:3C:92:0A:BD) already uses address 66.59.198.xxx", confirms that there is a conflict with the IP address assignment.
To resolve this issue, I recommend the following steps:
Reconfigure Networking: You mentioned that you have already performed this step from the SolusVM panel. If you haven't done so, please try reconfiguring the networking again to ensure a proper reset of the network settings on your VM.
Check for any IP conflicts: It would be best to check if there are any other VMs on the same node ATL-Z006 that have been mistakenly assigned the same IP address (66.59.198.xxx). Our network team can assist you with this investigation.
Request VM migration: If the issue persists and no IP conflicts are found, we can consider migrating your VM to another node, such as San Jose, to ensure a stable network connection.
To proceed with the necessary troubleshooting and assistance, I kindly ask you to provide us with your ticket number or customer ID. This will help us locate your account and ensure that the appropriate team addresses your request as soon as possible.
Please let us know if there is anything else we can assist you with.
Your ticket is still waiting to be reviewed by a human , but if my answer was helpful, please close the ticket to mark it as resolved.
VirBot
@VirMach I see that you have put VirBot to work full time. But I am a bit confused as to why he would not know the ticket number that he is answering ? Also I am not sure if to add the ticket number and customer ID [account email ?] because it also says:
Please wait for a staff reply. If you need to add more information, you may have to close this ticket and start over. Otherwise we have already received your previous message and have already flagged your ticket to the correct department for a response. Further replies at this point would only delay resolution.
Please excuse my confusion as I have not submitted a service related ticket at VirMach for quite a long time and it seems many things have changed.
New VM id=711334 on node ATL-Z006 with IPv4 66.59.198.xxx keeps dropping network connection in a way that appears to suggest that IP is assigned also to another VM.
When connection drops from outside, VM is still accessible by VNC and shows no other issues except that it can not reach outside network. When connection is working there are no other issues.
I see the following error message in my logs:
"ifup-eth: 11Error, some other host (00:16:3C:92:0A:BD) already uses address 66.59.198.xxx."
I have already reinstalled multiple O/S and have had similar results.
I have already run reconfigure networking from SolusVM panel.
I have already verified that my firewall is not blocking connection from my IP or any outbound connections.
I have already checked networking configuration and routing.
Firewall is currently down, and ssh login with password is enabled. SSH port is xxx.
Main IP pings: true
Node Online: true
Service online: online
Operating System: linux-centos-7-x86_64-minimal-latest
Service Status:Active
Registration Date:2023-11-23
If it is required to move VM my preference would be San Jose
Thank you in advance for your assistance,
If you have any suggestions on how this ticket information could be improved, I expect that it might be helpful to myself as well as other clients in the future.
EDIT: The reason that I made the ticket is that other guy that has this IP is using ~10GB of transfer a day, so I expect my VM to get suspended in ~12 days and I don't want to get any negative flags on my account because of this.
Will there be any compensation activities for DALZ004 and DALZ007 users? This outage has lasted for a long time.
I'd be surprised if all the downtime is going to be accounted for and frankly I think that is fine. I considered trying to estimate what all the outage time might amount to over the the past year and half, but it is just too much work for too little gain. Partial refunds for potentially tens of ~$10/year BF specials won't come close to recouping the time spent to bother calculating. I'd guess less than $50. Sunk cost for the cheap prices.
Will there be any compensation activities for DALZ004 and DALZ007 users? This outage has lasted for a long time.
I'd be surprised if all the downtime is going to be accounted for and frankly I think that is fine. I considered trying to estimate what all the outage time might amount to over the the past year and half, but it is just too much work for too little gain. Partial refunds for potentially tens of ~$10/year BF specials won't come close to recouping the time spent to bother calculating. I'd guess less than $50. Sunk cost for the cheap prices.
Refunds aren't the only way. The latest down time (single event) is about to hit 25% in a 365-day window for these nodes so I'd expect some type of service extension, which is a very simple algorithm with no per-VM calculation.
@tetech said:
Refunds aren't the only way. The latest down time (single event) is about to hit 25% in a 365-day window for these nodes so I'd expect some type of service extension, which is a very simple algorithm with no per-VM calculation.
That would be lovely, but I am not optimistic an accurate accounting can even be made. If the provider makes an attempt, great, thanks, but I don't think people should get too bent out of shape if it's not perfect, at least for the BF deals.
Will there be any compensation activities for DALZ004 and DALZ007 users? This outage has lasted for a long time.
I'd be surprised if all the downtime is going to be accounted for and frankly I think that is fine. I considered trying to estimate what all the outage time might amount to over the the past year and half, but it is just too much work for too little gain. Partial refunds for potentially tens of ~$10/year BF specials won't come close to recouping the time spent to bother calculating. I'd guess less than $50. Sunk cost for the cheap prices.
Basically right now our auto crediting isn't being processed until we release version 2 of it as version 1 had lots of issues. So if it's worth it for anyone to make a proper ticket request SLA after the service is back up (we're not going to do more than one request, so you have to wait until it's up so we know the total) then we'll process it.
It will either be an extension or credits, you don't get to decide, but generally we do more extensions than credits and that's usually preferred.
Thank you for reaching out to us regarding the network connection issue with your VM (id=711334) on node ATL-Z006 with IPv4 66.59.198.xxx. I apologize for any inconvenience this may have caused.
Based on your description, it seems that the IP address 66.59.198.xxx is being assigned to another VM as well, causing the network connection to drop intermittently. However, the VM remains accessible through VNC with no other issues except for the inability to reach the outside network during the connection drops.
The error message you encountered in your logs, "ifup-eth: Error, some other host (00:16:3C:92:0A:BD) already uses address 66.59.198.xxx", confirms that there is a conflict with the IP address assignment.
To resolve this issue, I recommend the following steps:
Reconfigure Networking: You mentioned that you have already performed this step from the SolusVM panel. If you haven't done so, please try reconfiguring the networking again to ensure a proper reset of the network settings on your VM.
Check for any IP conflicts: It would be best to check if there are any other VMs on the same node ATL-Z006 that have been mistakenly assigned the same IP address (66.59.198.xxx). Our network team can assist you with this investigation.
Request VM migration: If the issue persists and no IP conflicts are found, we can consider migrating your VM to another node, such as San Jose, to ensure a stable network connection.
To proceed with the necessary troubleshooting and assistance, I kindly ask you to provide us with your ticket number or customer ID. This will help us locate your account and ensure that the appropriate team addresses your request as soon as possible.
Please let us know if there is anything else we can assist you with.
Your ticket is still waiting to be reviewed by a human , but if my answer was helpful, please close the ticket to mark it as resolved.
VirBot
@VirMach I see that you have put VirBot to work full time. But I am a bit confused as to why he would not know the ticket number that he is answering ? Also I am not sure if to add the ticket number and customer ID [account email ?] because it also says:
Please wait for a staff reply. If you need to add more information, you may have to close this ticket and start over. Otherwise we have already received your previous message and have already flagged your ticket to the correct department for a response. Further replies at this point would only delay resolution.
Please excuse my confusion as I have not submitted a service related ticket at VirMach for quite a long time and it seems many things have changed.
New VM id=711334 on node ATL-Z006 with IPv4 66.59.198.xxx keeps dropping network connection in a way that appears to suggest that IP is assigned also to another VM.
When connection drops from outside, VM is still accessible by VNC and shows no other issues except that it can not reach outside network. When connection is working there are no other issues.
I see the following error message in my logs:
"ifup-eth: 11Error, some other host (00:16:3C:92:0A:BD) already uses address 66.59.198.xxx."
I have already reinstalled multiple O/S and have had similar results.
I have already run reconfigure networking from SolusVM panel.
I have already verified that my firewall is not blocking connection from my IP or any outbound connections.
I have already checked networking configuration and routing.
Firewall is currently down, and ssh login with password is enabled. SSH port is xxx.
Main IP pings: true
Node Online: true
Service online: online
Operating System: linux-centos-7-x86_64-minimal-latest
Service Status:Active
Registration Date:2023-11-23
If it is required to move VM my preference would be San Jose
Thank you in advance for your assistance,
If you have any suggestions on how this ticket information could be improved, I expect that it might be helpful to myself as well as other clients in the future.
EDIT: The reason that I made the ticket is that other guy that has this IP is using ~10GB of transfer a day, so I expect my VM to get suspended in ~12 days and I don't want to get any negative flags on my account because of this.
Reply will end up being pretty bad in some cases and it can just be ignored. It's set to display as different than ticket replies on ticket view already and marked as AI reply, and lets you know a human will still review it at the end.
Sometimes the wording is not perfect and it deviates into telling you to contact us which you already did or providing it with useless information we would already know. I think it did that because you mentioned ID's and such in a way where it made it sound like we couldn't just find it on your account and therefore it's responding to you in a similar way. So if you left this part out it probably wouldn't say it in the weird way it did, maybe.
New VM id=711334 on node ATL-Z006
I also don't know if you re-arranged what it keeps at the top or removed it in which case it'd possibly mess up.
@FrankZ said: Thank you for reaching out to us regarding the network connection issue with your VM (id=711334) on node ATL-Z006 with IPv4 66.59.198.xxx. I
I already know what the issue is by the way. Added to my high priority list but everything's on there right now so it might be a couple days, years? minutes for a quick temporary fix, maybe.
@VirMach said:
It will either be an extension or credits, you don't get to decide, but generally we do more extensions than credits and that's usually preferred.
I suspect my BF stuff will be cancelled by then and no, not worth to continue renewing and calculating whatever extensions may be reasonable. It was a fun ride while it lasted.
@FrankZ said: Thank you for reaching out to us regarding the network connection issue with your VM (id=711334) on node ATL-Z006 with IPv4 66.59.198.xxx. I
I already know what the issue is by the way. Added to my high priority list but everything's on there right now so it might be a couple days, years? minutes for a quick temporary fix, maybe.
Not a high priority issue given that you have much bigger fish to fry. I'm just hoping to stay off the naughty list.
@tenpera said: @VirMach DALZ007 situation is unlikely to change in the foreseeable future?
Latest message I got back from Flexential was today. Server may have to be shipped back to us because it's having issues and it's difficult to get them to bring it back in a state where I can access it. Could be another 2 weeks, maybe. But that's a wild guess, especially with Flex involved.
@tenpera said: @VirMach DALZ007 situation is unlikely to change in the foreseeable future?
Latest message I got back from Flexential was today. Server may have to be shipped back to us because it's having issues and it's difficult to get them to bring it back in a state where I can access it. Could be another 2 weeks, maybe. But that's a wild guess, especially with Flex involved.
Due to the numerous major delays you've had with Flex, would you be willing to consider rebuilding the service elsewhere utilizing the data in the server? (I mean including services marked as special). If you're willing to do that, we're probably long out of that trap.
Or if you don't have any spare/suitable hardware for the DALZ007, would you be willing to consider not sending it to Flex's server room again and putting it somewhere else after the server is repaired? It just looks like a disaster here.
Have the honor of being the crybaby who pays $20 for a 128MB VPS at VirMach in 2023.
@tenpera said: @VirMach DALZ007 situation is unlikely to change in the foreseeable future?
Latest message I got back from Flexential was today. Server may have to be shipped back to us because it's having issues and it's difficult to get them to bring it back in a state where I can access it. Could be another 2 weeks, maybe. But that's a wild guess, especially with Flex involved.
Due to the numerous major delays you've had with Flex, would you be willing to consider rebuilding the service elsewhere utilizing the data in the server? (I mean including services marked as special). If you're willing to do that, we're probably long out of that trap.
Or if you don't have any spare/suitable hardware for the DALZ007, would you be willing to consider not sending it to Flex's server room again and putting it somewhere else after the server is repaired? It just looks like a disaster here.
To utilize the data, it'd still need to go through the same long process. If it gets sent back then we'd likely deploy it elsewhere or try to deploy it in OKC location if that is ready by then. We're already considering regenerating all services without data for the time being elsewhere, including specials and discussing this internally.
I want to be fair to Flex, outside of the horrendous delay initially to release hardware and then to ship it, and so on, the most recent hands requests have been above what we expected from them but perhaps it's because we've already set out expectations so low.
Based on our experience so far with the datacenter hands, it's possible that the previous experience we had was going through perhaps a layer of Dedipath deception, since Flexential has definitely performed more actions than what we previously thought they did which was basically nothing (in the past they had trouble locating a CMOS battery, they didn't know what it was, but maybe Dedipath lied and sent some third party tech and just billed us the DC rate.)
We do have enough hardware to deploy people, that's not the issue. It's that our mass redeployment script has issues, more specifically with specials, so we have t make some improvements first.
With all that said, the issue does not seem that complicated once it is in front us, probably less than half an hour to fix it unless it gets damaged during shipping. Flex didn't say anything that would indicate there was damage, but at the same time the server has regressed since being worked on. Initially it looked ready to go back online, and slowly declined to not even posting at this stage.
@FAT32 said:
No pressure but LAX2Z019 seems dead to me
It's been dead for a while. I think you've been idling a little too hard if you just noticed! Replacement was taken to the datacenter but they didn't let me in and it's been extremely hectic since. I do need to give that another attempt over the next 72 hours.
@VirMach said:
It's been dead for a while. I think you've been idling a little too hard if you just noticed! Replacement was taken to the datacenter but they didn't let me in and it's been extremely hectic since. I do need to give that another attempt over the next 72 hours.
You see, idling makes my neighbor happier. Whoever on the same node as me, congrats!
@VirMach said:
It's been dead for a while. I think you've been idling a little too hard if you just noticed! Replacement was taken to the datacenter but they didn't let me in and it's been extremely hectic since. I do need to give that another attempt over the next 72 hours.
You see, idling makes my neighbor happier. Whoever on the same node as me, congrats!
I have canceled the renewal of the VPS in DALZ004 because it was about to renew, but I don't know when it will be back online. I bought a VPS from a scalper to replace DALZ004, and I merged it into my own account. The first push was rejected, and the second push is still pending.
@ben said:
I have canceled the renewal of the VPS in DALZ004 because it was about to renew, but I don't know when it will be back online. I bought a VPS from a scalper to replace DALZ004, and I merged it into my own account. The first push was rejected, and the second push is still pending.
For more information and resolution have scalper generate request for custom $10 transfer. The $3 transfer doesn't include discussions, checking what happened, etc, but if it was rejected with refund it means we can't process the transfer. If no refund, it means instructions weren't followed and likely wrong email input.
I remember a transfer request that got rejected recently where they input an email address with a space in the middle of it so maybe it's that one.
(edit) I'll see if we can validate it for actually being an email format but I didn't expect anyone to want to throw away their transfer fee that quickly by doing that, I think that's the first one.
Comments
Now that BF is over, time for the usually late VirBot?
Thank you for the reminder, I had completely forgotten these nodes even exist and definitely was not already coordinating with Flexential for them per the previous network status update.
It's going to be early for BF 2024 this time.
I feel relieved when you say that.
the
/swas forgotten.Send DALZ004 and DALZ007 to Tokyo, please. Everyone will wish for its smooth arrival.
Impatiently tickle my balls
smartass shitposting satirist
Will there be any compensation activities for DALZ004 and DALZ007 users? This outage has lasted for a long time.
PHXZ003 high load @VirMach
same here, my vps is idling with 82.99 cpu load, no ssh possible and billing panel times out.
@VirMach My ticket opened at last week for duplicate payment caused by paypal subscription is still waiting for your resolve.
Could you please take a minute for this issue?
It won't need to much time to either refund the duplicated payment or add the amount to my account.
Thank you!
@VirMach I see that you have put VirBot to work full time. But I am a bit confused as to why he would not know the ticket number that he is answering ? Also I am not sure if to add the ticket number and customer ID [account email ?] because it also says:
Please excuse my confusion as I have not submitted a service related ticket at VirMach for quite a long time and it seems many things have changed.
My originally submitted ticket was:
If you have any suggestions on how this ticket information could be improved, I expect that it might be helpful to myself as well as other clients in the future.
EDIT: The reason that I made the ticket is that other guy that has this IP is using ~10GB of transfer a day, so I expect my VM to get suspended in ~12 days and I don't want to get any negative flags on my account because of this.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
I'd be surprised if all the downtime is going to be accounted for and frankly I think that is fine. I considered trying to estimate what all the outage time might amount to over the the past year and half, but it is just too much work for too little gain. Partial refunds for potentially tens of ~$10/year BF specials won't come close to recouping the time spent to bother calculating. I'd guess less than $50. Sunk cost for the cheap prices.
Dataplane.org's current server hosting provider list
Refunds aren't the only way. The latest down time (single event) is about to hit 25% in a 365-day window for these nodes so I'd expect some type of service extension, which is a very simple algorithm with no per-VM calculation.
That would be lovely, but I am not optimistic an accurate accounting can even be made. If the provider makes an attempt, great, thanks, but I don't think people should get too bent out of shape if it's not perfect, at least for the BF deals.
Dataplane.org's current server hosting provider list
Basically right now our auto crediting isn't being processed until we release version 2 of it as version 1 had lots of issues. So if it's worth it for anyone to make a proper ticket request SLA after the service is back up (we're not going to do more than one request, so you have to wait until it's up so we know the total) then we'll process it.
It will either be an extension or credits, you don't get to decide, but generally we do more extensions than credits and that's usually preferred.
Reply will end up being pretty bad in some cases and it can just be ignored. It's set to display as different than ticket replies on ticket view already and marked as AI reply, and lets you know a human will still review it at the end.
Sometimes the wording is not perfect and it deviates into telling you to contact us which you already did or providing it with useless information we would already know. I think it did that because you mentioned ID's and such in a way where it made it sound like we couldn't just find it on your account and therefore it's responding to you in a similar way. So if you left this part out it probably wouldn't say it in the weird way it did, maybe.
I also don't know if you re-arranged what it keeps at the top or removed it in which case it'd possibly mess up.
I already know what the issue is by the way. Added to my high priority list but everything's on there right now so it might be a couple days, years? minutes for a quick temporary fix, maybe.
I suspect my BF stuff will be cancelled by then and no, not worth to continue renewing and calculating whatever extensions may be reasonable. It was a fun ride while it lasted.
Dataplane.org's current server hosting provider list
Not a high priority issue given that you have much bigger fish to fry. I'm just hoping to stay off the naughty list.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
@VirMach DALZ007 situation is unlikely to change in the foreseeable future?
Latest message I got back from Flexential was today. Server may have to be shipped back to us because it's having issues and it's difficult to get them to bring it back in a state where I can access it. Could be another 2 weeks, maybe. But that's a wild guess, especially with Flex involved.
Due to the numerous major delays you've had with Flex, would you be willing to consider rebuilding the service elsewhere utilizing the data in the server? (I mean including services marked as special). If you're willing to do that, we're probably long out of that trap.
Or if you don't have any spare/suitable hardware for the DALZ007, would you be willing to consider not sending it to Flex's server room again and putting it somewhere else after the server is repaired? It just looks like a disaster here.
Have the honor of being the crybaby who pays $20 for a 128MB VPS at VirMach in 2023.
To utilize the data, it'd still need to go through the same long process. If it gets sent back then we'd likely deploy it elsewhere or try to deploy it in OKC location if that is ready by then. We're already considering regenerating all services without data for the time being elsewhere, including specials and discussing this internally.
I want to be fair to Flex, outside of the horrendous delay initially to release hardware and then to ship it, and so on, the most recent hands requests have been above what we expected from them but perhaps it's because we've already set out expectations so low.
Based on our experience so far with the datacenter hands, it's possible that the previous experience we had was going through perhaps a layer of Dedipath deception, since Flexential has definitely performed more actions than what we previously thought they did which was basically nothing (in the past they had trouble locating a CMOS battery, they didn't know what it was, but maybe Dedipath lied and sent some third party tech and just billed us the DC rate.)
We do have enough hardware to deploy people, that's not the issue. It's that our mass redeployment script has issues, more specifically with specials, so we have t make some improvements first.
With all that said, the issue does not seem that complicated once it is in front us, probably less than half an hour to fix it unless it gets damaged during shipping. Flex didn't say anything that would indicate there was damage, but at the same time the server has regressed since being worked on. Initially it looked ready to go back online, and slowly declined to not even posting at this stage.
No pressure but
LAX2Z019seems dead to meIt's been dead for a while. I think you've been idling a little too hard if you just noticed! Replacement was taken to the datacenter but they didn't let me in and it's been extremely hectic since. I do need to give that another attempt over the next 72 hours.
You see, idling makes my neighbor happier. Whoever on the same node as me, congrats!
I think @FrankZ is also idling on it. Or... was.
I have canceled the renewal of the VPS in DALZ004 because it was about to renew, but I don't know when it will be back online. I bought a VPS from a scalper to replace DALZ004, and I merged it into my own account. The first push was rejected, and the second push is still pending.
For staff assistance or support issues please use the helpdesk ticket system at https://support.lowendspirit.com/index.php?a=add
For more information and resolution have scalper generate request for custom $10 transfer. The $3 transfer doesn't include discussions, checking what happened, etc, but if it was rejected with refund it means we can't process the transfer. If no refund, it means instructions weren't followed and likely wrong email input.
I remember a transfer request that got rejected recently where they input an email address with a space in the middle of it so maybe it's that one.
(edit) I'll see if we can validate it for actually being an email format but I didn't expect anyone to want to throw away their transfer fee that quickly by doing that, I think that's the first one.