@cservers I'm really sorry for reaching out with LES thread, but I don't think I should use money for the paid tickets.
Both DE and FI servers have the same issue - incredible high packet loss. Both DE and FI servers do nothing atm. Both have 20% to 30% packet loss from just google ping.
Firstly I was thinking it's just ICMP which is bad, but no, api request to my main node have about the same failure rate.
First image is DE VPS, second is FI.
For the price you offer I'm fine even with something like 15-20Mbit. But losing one of every 3 to 4 packets is way to bad. And I had waited for more than a week for the situation to be resolved.
@Scioner said: @cservers I'm really sorry for reaching out with LES thread, but I don't think I should use money for the paid tickets.
Both DE and FI servers have the same issue - incredible high packet loss. Both DE and FI servers do nothing atm. Both have 20% to 30% packet loss from just google ping.
Firstly I was thinking it's just ICMP which is bad, but no, api request to my main node have about the same failure rate.
First image is DE VPS, second is FI.
For the price you offer I'm fine even with something like 15-20Mbit. But losing one of every 3 to 4 packets is way to bad. And I had waited for more than a week for the situation to be resolved.
Hello, no problem, though this is a technical issue and does belong on that section, but okay.
Check the MTU for your interface and try to change it to either 1420 or 1500 and see if it improves things. We don't have reported issues or any other complaints of packet loss in DE or FI at the moment though that happened for a while on the Falkenstein location (at the time even with VirtFusion) due to a different MTU configuration on that particular server, and the location's own network as well. Whenever someone reported that to us, changing the MTU sorted the issue out.
Alternatively, you probably should attempt a reinstall because provisioning already has the correct network settings. System-wise this was also corrected as well long ago - probably some remains of previous configurations as well contributing to the process.
@cservers said:
Alternatively, you probably should attempt a reinstall because provisioning already has the correct network settings. System-wise this was also corrected as well long ago - probably some remains of previous configurations as well contributing to the process.
fresh debian 13, mtu 1500 by default
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.49 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.46 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.46 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.52 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=1.41 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=1.45 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=2.27 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 7 received, 30% packet loss, time 9088ms
rtt min/avg/max/mdev = 1.412/1.579/2.270/0.283 ms
fresh debian 12, mtu 1500 by default
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.34 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.50 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=1.51 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=1.42 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=1.40 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9087ms
rtt min/avg/max/mdev = 1.340/1.433/1.505/0.061 ms
fresh almalinux, mtu 1500 by default
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.41 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.93 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=1.48 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.48 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=3.46 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=2.28 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=1.45 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=1.69 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9105ms
rtt min/avg/max/mdev = 1.414/1.898/3.463/0.654 ms
there's also fresh alpine mount: mounting /dev/vda on /sysroot failed: No such file or directory [ 0.924227] Mounting root: failed.
and fresh centos [ 1.146596] ---[ end Kernel panic - not syncing: System is deadlocked on memory ]---
@cservers said:
Alternatively, you probably should attempt a reinstall because provisioning already has the correct network settings. System-wise this was also corrected as well long ago - probably some remains of previous configurations as well contributing to the process.
fresh debian 13, mtu 1500 by default
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.49 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.46 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.46 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.52 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=1.41 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=1.45 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=2.27 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 7 received, 30% packet loss, time 9088ms
rtt min/avg/max/mdev = 1.412/1.579/2.270/0.283 ms
fresh debian 12, mtu 1500 by default
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.34 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.50 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=1.51 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=1.42 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=1.40 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9087ms
rtt min/avg/max/mdev = 1.340/1.433/1.505/0.061 ms
fresh almalinux, mtu 1500 by default
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.41 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.93 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=1.48 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.48 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=3.46 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=2.28 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=1.45 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=1.69 ms
^C
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 9105ms
rtt min/avg/max/mdev = 1.414/1.898/3.463/0.654 ms
there's also fresh alpine mount: mounting /dev/vda on /sysroot failed: No such file or directory [ 0.924227] Mounting root: failed.
and fresh centos [ 1.146596] ---[ end Kernel panic - not syncing: System is deadlocked on memory ]---
MTU is correct at 1500. Essentially what you're getting is something different to mere packet loss - it's entire loss of connectivity for some seconds at a time. That's something different and can happen for several reasons.
Send us your user via PM so we can take a better look at what is going on on your particular VPS service.
My server has been constantly showing that the CPU usage is 100%. I thought that by shutting down the service, I could change the IP of the server. But nothing happened. I sent you an email, but you haven't replied yet.
VPS has only been purchased for half a year, and the server has been unavailable since late July. Now, even the account can‘t be logged in,There was no response to contacting customer service on the website, no response to sending emails, and no work order system
@imeng said:
VPS has only been purchased for half a year, and the server has been unavailable since late July. Now, even the account can‘t be logged in,There was no response to contacting customer service on the website, no response to sending emails, and no work order system
@imeng said:
VPS has only been purchased for half a year, and the server has been unavailable since late July. Now, even the account can‘t be logged in,There was no response to contacting customer service on the website, no response to sending emails, and no work order system
Not really, the VMs are working correctly and we have been working on the panel this weekend.
The customer himself demanded that the VM would be cancelled immediately in 21-07-2026. (The print is in Portuguese due to temporary internal i18n issues we are sorting out, but "Cancelar imediatamente" means exactly that).
So, he self-inflicted his lack of VPS service. And there has been existing support where there is support to be given at services.
His account is also active and accessible as well, any issues on recieving passwords are exclusively associated to his e-mail which is a @163.com e-mail. We would be having our support tickets filled if there was an issue there.
That's also at New Jersey, the node that will be decomissioned in a few days, and a 320MB RAM VPS at that.
So @imeng not going to happen any reinstatement. You voluntarily asked for cancellation and we did it. There's a 48 hour period on the T&Cs where it is predicted such cancellations can be reversed, not a 17 day period (the difference between 21-07 and 09-08). End of statement.
@cservers said:
The customer himself demanded that the VM would be cancelled immediately in 21-07-2026. (The print is in Portuguese due to temporary internal i18n issues we are sorting out, but "Cancelar imediatamente" means exactly that).
How dare you cancel the VPS immediately after the client requested an immediate cancelation!
@imeng if you requested cancellation, no use crying over leftover funds. Happened to me as well with another provider. Canceled a VPS with 9 months left while trying to cancel another VPS that had 14 days remaining... Oh well, learn and move on
I speak fluent sarcasm and broken logic. | I would agree with you, but thæn we’d both be wrong.
@imeng said:
VPS has only been purchased for half a year, and the server has been unavailable since late July. Now, even the account can‘t be logged in,There was no response to contacting customer service on the website, no response to sending emails, and no work order system
Not really, the VMs are working correctly and we have been working on the panel this weekend.
The customer himself demanded that the VM would be cancelled immediately in 21-07-2026. (The print is in Portuguese due to temporary internal i18n issues we are sorting out, but "Cancelar imediatamente" means exactly that).
So, he self-inflicted his lack of VPS service. And there has been existing support where there is support to be given at services.
His account is also active and accessible as well, any issues on recieving passwords are exclusively associated to his e-mail which is a @163.com e-mail. We would be having our support tickets filled if there was an issue there.
That's also at New Jersey, the node that will be decomissioned in a few days, and a 320MB RAM VPS at that.
So @imeng not going to happen any reinstatement. You voluntarily asked for cancellation and we did it. There's a 48 hour period on the T&Cs where it is predicted such cancellations can be reversed, not a 17 day period (the difference between 21-07 and 09-08). End of statement.
Starting from July 8th, my server displayed a 100% CPU usage warning and was then restricted and shut down by the provider. Submit a support ticket? Don’t make me laugh. Where is the ticket system on your website? The site states “Regular Support: 24/7”, which is completely fake. There is no support phone number, and my support‑emails go unanswered. I even suspect the listed email address is bogus. I’m writing this as a warning for other users.
Canceling my service does not restore my service. What about my money?
Here is exactly what they did:
1.First, the server showed a 100% CPU usage warning, then they restricted and manually shut down the server on their end. Power‑on and reboot do not work, even OS reinstallation fails.
2.There is no ticket system anywhere on the site. No real‑human support can be reached, and emails receive zero replies.
3.Surprisingly, the “Cancel Service” button inside the dashboard works perfectly fine and is clickable.
4.In the end, they simply ban the user account, making it impossible to log in at all.
@cservers said:
The customer himself demanded that the VM would be cancelled immediately in 21-07-2026. (The print is in Portuguese due to temporary internal i18n issues we are sorting out, but "Cancelar imediatamente" means exactly that).
How dare you cancel the VPS immediately after the client requested an immediate cancelation!
@imeng if you requested cancellation, no use crying over leftover funds. Happened to me as well with another provider. Canceled a VPS with 9 months left while trying to cancel another VPS that had 14 days remaining... Oh well, learn and move on
Starting from July 8th, my server has been showing 100% CPU usage and has been restricted from use ever since. There is no option to restore service, and there is no ticket system at all. My emails go unanswered. Inside the entire dashboard, surprisingly, only the “Cancel Service” button is functional and clickable. :'(
I clicked Cancel Service because the page stated that service could be restored within 48 hours. However, after I cancelled, I could not find any button to restore my service at all. The 48‑hour restoration claim is false.
@cservers I haven't been able to receive any emails from the panel, so I can't reset my panel password. I also couldn't sign up for your support portal because I never received the verification email.
I tried using a different email address to sign up for the support portal, and that worked successfully. However, I can't reliably access the AI chat because it says:
"Right now, I'm not seeing any WebStore account matching the email you're signed in with here."
Can you please check whether there is an issue with email delivery for my account and advise me on how I can regain access to the panel and support portal?
@truemagic said: @cservers I haven't been able to receive any emails from the panel, so I can't reset my panel password. I also couldn't sign up for your support portal because I never received the verification email.
I tried using a different email address to sign up for the support portal, and that worked successfully. However, I can't reliably access the AI chat because it says:
"Right now, I'm not seeing any WebStore account matching the email you're signed in with here."
Can you please check whether there is an issue with email delivery for my account and advise me on how I can regain access to the panel and support portal?
I'll PM you my email address. Thank you!
Hello! Answering you shortly via PM so we can sort it out, that's a normal message because the AI chat does check services considering the e-mail between the WebStore and the Support, but it's perfectly solvable. Thank you!
@imeng said:
I clicked Cancel Service because the page stated that service could be restored within 48 hours. However, after I cancelled, I could not find any button to restore my service at all. The 48‑hour restoration claim is false.
I'm sorry but that was dumb. That's like admitting to murder because your lawyer says he's already got great grounds for an appeal. I'm fairly certain that statement actually means if you clicked cancel in error you can terminate the cancellation within 48 hours. Presumably by contacting support directly and immediately.
@imeng said:
I clicked Cancel Service because the page stated that service could be restored within 48 hours. However, after I cancelled, I could not find any button to restore my service at all. The 48‑hour restoration claim is false.
I'm sorry but that was dumb. That's like admitting to murder because your lawyer says he's already got great grounds for an appeal. I'm fairly certain that statement actually means if you clicked cancel in error you can terminate the cancellation within 48 hours. Presumably by contacting support directly and immediately.
Unfortunately, they don't have customer service or customer support. After buying their service, you can't contact them except here, and even if you don't cancel the service, your server is locked
@cservers I still haven't received a reply via PM. My main issue is that I'm currently unable to access the EagleKey Panel, which I need in order to configure port mapping (NAT) for my VPS.
I've also sent you my email address via PM, as it needs to be updated so I can receive emails from the portal.
Can you please look into the EagleKey Panel access issue and the email delivery issue for me? Thanks!
@truemagic said: @cservers I still haven't received a reply via PM. My main issue is that I'm currently unable to access the EagleKey Panel, which I need in order to configure port mapping (NAT) for my VPS.
I've also sent you my email address via PM, as it needs to be updated so I can receive emails from the portal.
Can you please look into the EagleKey Panel access issue and the email delivery issue for me? Thanks!
We didn't yet go to review your situation and the present status, hence why you didn't get yet any confirmation that it was sorted out. It will be done as soon as possible and after some validations are held internally first.
I am also unable to access my EagleKey control panel. When I try to log in, I get an "Account suspended" error message. I believe this might be a mistake or related to the ongoing system validations.
I have just sent you a PM with my account details. Could you please check it for me when you have a moment? Thank you!
@truemagic said: @cservers I still haven't received a reply via PM. My main issue is that I'm currently unable to access the EagleKey Panel, which I need in order to configure port mapping (NAT) for my VPS.
I've also sent you my email address via PM, as it needs to be updated so I can receive emails from the portal.
Can you please look into the EagleKey Panel access issue and the email delivery issue for me? Thanks!
We didn't yet go to review your situation and the present status, hence why you didn't get yet any confirmation that it was sorted out. It will be done as soon as possible and after some validations are held internally first.
Thanks for the update. I'll wait for your confirmation once the review is completed
@cservers Thanks for sorting this out! I've checked and can confirm that the EagleKey Panel access issue is also resolved. Really appreciate your help and the quick follow-up!
I am currently experiencing an issue with my VPS (VM #998, located on the Zeta.9 Coventry node). The server is completely stopped and I am unable to boot it up.
Whenever I attempt to start the VM from the portal, it immediately throws the following error:
vm.boot: CHV /api/v1/vm.boot: HTTP 500: ["Error from API","The VM could not boot","Error from device manager","Cannot create virtio-net device","Failed to open taps","Error related to the multiqueue support (no support device side)"]
Based on the error log, it seems to be an issue on the host node. The underlying Cloud Hypervisor is failing to allocate the virtio-net device and open TAP interfaces due to an issue with multiqueue support (HTTP 500). Since this appears to be a host-level virtualization or network configuration issue, there is nothing I can do to fix it from the user panel.
Has anyone else on the Zeta.9 node experienced this recently? Could the technical support team please look into the host node's configuration and help resolve this network device allocation issue?
@Antoninus said:
I am currently experiencing an issue with my VPS (VM #998, located on the Zeta.9 Coventry node). The server is completely stopped and I am unable to boot it up.
Whenever I attempt to start the VM from the portal, it immediately throws the following error:
vm.boot: CHV /api/v1/vm.boot: HTTP 500: ["Error from API","The VM could not boot","Error from device manager","Cannot create virtio-net device","Failed to open taps","Error related to the multiqueue support (no support device side)"]
Based on the error log, it seems to be an issue on the host node. The underlying Cloud Hypervisor is failing to allocate the virtio-net device and open TAP interfaces due to an issue with multiqueue support (HTTP 500). Since this appears to be a host-level virtualization or network configuration issue, there is nothing I can do to fix it from the user panel.
Has anyone else on the Zeta.9 node experienced this recently? Could the technical support team please look into the host node's configuration and help resolve this network device allocation issue?
That'll be something with the multiqueue. We'll have to take a look at the code and probably fix something there system-wide - several VMs booted with the multiqueue active, apparently at least two didn't so far.
No data at risk, so don't worry - this is only a question of getting the XML sorted out.
NanoVPS-384 Low-Cost Special
vps-3133 - 192.168.220.247 Since this service has ceased operation, I need a refund to the payment account.
Why hasn't the refund been credited to my account?
@Josu said:
NanoVPS-384 Low-Cost Special
vps-3133 - 192.168.220.247 Since this service has ceased operation, I need a refund to the payment account.
Why hasn't the refund been credited to my account?
No services at New Jersey have yet ceased operation, that is operating with a delay to the ETA of August 13th due to internal reconfigurations. It's all still up and will only start to cease later today, and progressively at that.
This also allowed for additional time for any last-minute backups that could be needed.
@Antoninus said:
I am currently experiencing an issue with my VPS (VM #998, located on the Zeta.9 Coventry node). The server is completely stopped and I am unable to boot it up.
Whenever I attempt to start the VM from the portal, it immediately throws the following error:
vm.boot: CHV /api/v1/vm.boot: HTTP 500: ["Error from API","The VM could not boot","Error from device manager","Cannot create virtio-net device","Failed to open taps","Error related to the multiqueue support (no support device side)"]
Based on the error log, it seems to be an issue on the host node. The underlying Cloud Hypervisor is failing to allocate the virtio-net device and open TAP interfaces due to an issue with multiqueue support (HTTP 500). Since this appears to be a host-level virtualization or network configuration issue, there is nothing I can do to fix it from the user panel.
Has anyone else on the Zeta.9 node experienced this recently? Could the technical support team please look into the host node's configuration and help resolve this network device allocation issue?
That'll be something with the multiqueue. We'll have to take a look at the code and probably fix something there system-wide - several VMs booted with the multiqueue active, apparently at least two didn't so far.
No data at risk, so don't worry - this is only a question of getting the XML sorted out.
This has been sorted out, it was an error on the multiqueue implementation network-wise exclusively for some 1 vCPU nodes. 3.7% of the VMs were affected and this has been sorted out entirely.
Sounds like a solid upgrade especially the focus on performance and keeping prices unchanged for 2026. The reduced RAM usage and zero-downtime migration are particularly nice improvements
Looking forward to seeing how EagleKey performs in practice
Comments
@cservers I'm really sorry for reaching out with LES thread, but I don't think I should use money for the paid tickets.
Both DE and FI servers have the same issue - incredible high packet loss. Both DE and FI servers do nothing atm. Both have 20% to 30% packet loss from just google ping.
Firstly I was thinking it's just ICMP which is bad, but no, api request to my main node have about the same failure rate.
First image is DE VPS, second is FI.
For the price you offer I'm fine even with something like 15-20Mbit. But losing one of every 3 to 4 packets is way to bad. And I had waited for more than a week for the situation to be resolved.
Hello, no problem, though this is a technical issue and does belong on that section, but okay.
Check the MTU for your interface and try to change it to either 1420 or 1500 and see if it improves things. We don't have reported issues or any other complaints of packet loss in DE or FI at the moment though that happened for a while on the Falkenstein location (at the time even with VirtFusion) due to a different MTU configuration on that particular server, and the location's own network as well. Whenever someone reported that to us, changing the MTU sorted the issue out.
Alternatively, you probably should attempt a reinstall because provisioning already has the correct network settings. System-wise this was also corrected as well long ago - probably some remains of previous configurations as well contributing to the process.
fresh debian 13, mtu 1500 by default
fresh debian 12, mtu 1500 by default
fresh almalinux, mtu 1500 by default
there's also fresh alpine
mount: mounting /dev/vda on /sysroot failed: No such file or directory[ 0.924227] Mounting root: failed.and fresh centos
[ 1.146596] ---[ end Kernel panic - not syncing: System is deadlocked on memory ]---MTU is correct at 1500. Essentially what you're getting is something different to mere packet loss - it's entire loss of connectivity for some seconds at a time. That's something different and can happen for several reasons.
Send us your user via PM so we can take a better look at what is going on on your particular VPS service.
My server has been constantly showing that the CPU usage is 100%. I thought that by shutting down the service, I could change the IP of the server. But nothing happened. I sent you an email, but you haven't replied yet.
VPS has only been purchased for half a year, and the server has been unavailable since late July. Now, even the account can‘t be logged in,There was no response to contacting customer service on the website, no response to sending emails, and no work order system
@cservers = new @VirMach ?
Not really, the VMs are working correctly and we have been working on the panel this weekend.
The customer himself demanded that the VM would be cancelled immediately in 21-07-2026. (The print is in Portuguese due to temporary internal i18n issues we are sorting out, but "Cancelar imediatamente" means exactly that).
So, he self-inflicted his lack of VPS service. And there has been existing support where there is support to be given at services.
His account is also active and accessible as well, any issues on recieving passwords are exclusively associated to his e-mail which is a @163.com e-mail. We would be having our support tickets filled if there was an issue there.
That's also at New Jersey, the node that will be decomissioned in a few days, and a 320MB RAM VPS at that.
So @imeng not going to happen any reinstatement. You voluntarily asked for cancellation and we did it. There's a 48 hour period on the T&Cs where it is predicted such cancellations can be reversed, not a 17 day period (the difference between 21-07 and 09-08). End of statement.
How dare you cancel the VPS immediately after the client requested an immediate cancelation!
@imeng if you requested cancellation, no use crying over leftover funds. Happened to me as well with another provider. Canceled a VPS with 9 months left while trying to cancel another VPS that had 14 days remaining... Oh well, learn and move on
Starting from July 8th, my server displayed a 100% CPU usage warning and was then restricted and shut down by the provider. Submit a support ticket? Don’t make me laugh. Where is the ticket system on your website? The site states “Regular Support: 24/7”, which is completely fake. There is no support phone number, and my support‑emails go unanswered. I even suspect the listed email address is bogus. I’m writing this as a warning for other users.
Canceling my service does not restore my service. What about my money?
Here is exactly what they did:
1.First, the server showed a 100% CPU usage warning, then they restricted and manually shut down the server on their end. Power‑on and reboot do not work, even OS reinstallation fails.
2.There is no ticket system anywhere on the site. No real‑human support can be reached, and emails receive zero replies.
3.Surprisingly, the “Cancel Service” button inside the dashboard works perfectly fine and is clickable.
4.In the end, they simply ban the user account, making it impossible to log in at all.
Starting from July 8th, my server has been showing 100% CPU usage and has been restricted from use ever since. There is no option to restore service, and there is no ticket system at all. My emails go unanswered. Inside the entire dashboard, surprisingly, only the “Cancel Service” button is functional and clickable. :'(
I clicked Cancel Service because the page stated that service could be restored within 48 hours. However, after I cancelled, I could not find any button to restore my service at all. The 48‑hour restoration claim is false.
@cservers I haven't been able to receive any emails from the panel, so I can't reset my panel password. I also couldn't sign up for your support portal because I never received the verification email.
I tried using a different email address to sign up for the support portal, and that worked successfully. However, I can't reliably access the AI chat because it says:
Can you please check whether there is an issue with email delivery for my account and advise me on how I can regain access to the panel and support portal?
I'll PM you my email address. Thank you!
Hello! Answering you shortly via PM so we can sort it out, that's a normal message because the AI chat does check services considering the e-mail between the WebStore and the Support, but it's perfectly solvable. Thank you!
Thanks for the clarification! No problem at all, I’ll keep an eye out for your PM. Appreciate your help!
I'm sorry but that was dumb. That's like admitting to murder because your lawyer says he's already got great grounds for an appeal. I'm fairly certain that statement actually means if you clicked cancel in error you can terminate the cancellation within 48 hours. Presumably by contacting support directly and immediately.
Unfortunately, they don't have customer service or customer support. After buying their service, you can't contact them except here, and even if you don't cancel the service, your server is locked
@cservers I still haven't received a reply via PM. My main issue is that I'm currently unable to access the EagleKey Panel, which I need in order to configure port mapping (NAT) for my VPS.
I've also sent you my email address via PM, as it needs to be updated so I can receive emails from the portal.
Can you please look into the EagleKey Panel access issue and the email delivery issue for me? Thanks!
We didn't yet go to review your situation and the present status, hence why you didn't get yet any confirmation that it was sorted out. It will be done as soon as possible and after some validations are held internally first.
I am also unable to access my EagleKey control panel. When I try to log in, I get an "Account suspended" error message. I believe this might be a mistake or related to the ongoing system validations.
I have just sent you a PM with my account details. Could you please check it for me when you have a moment? Thank you!
Thanks for the update. I'll wait for your confirmation once the review is completed
@cservers Thanks for sorting this out! I've checked and can confirm that the EagleKey Panel access issue is also resolved. Really appreciate your help and the quick follow-up!
I am currently experiencing an issue with my VPS (VM #998, located on the Zeta.9 Coventry node). The server is completely stopped and I am unable to boot it up.
Whenever I attempt to start the VM from the portal, it immediately throws the following error:
vm.boot: CHV /api/v1/vm.boot: HTTP 500: ["Error from API","The VM could not boot","Error from device manager","Cannot create virtio-net device","Failed to open taps","Error related to the multiqueue support (no support device side)"]
Based on the error log, it seems to be an issue on the host node. The underlying Cloud Hypervisor is failing to allocate the virtio-net device and open TAP interfaces due to an issue with multiqueue support (HTTP 500). Since this appears to be a host-level virtualization or network configuration issue, there is nothing I can do to fix it from the user panel.
Has anyone else on the Zeta.9 node experienced this recently? Could the technical support team please look into the host node's configuration and help resolve this network device allocation issue?
That'll be something with the multiqueue. We'll have to take a look at the code and probably fix something there system-wide - several VMs booted with the multiqueue active, apparently at least two didn't so far.
No data at risk, so don't worry - this is only a question of getting the XML sorted out.
NanoVPS-384 Low-Cost Special
vps-3133 - 192.168.220.247 Since this service has ceased operation, I need a refund to the payment account.
Why hasn't the refund been credited to my account?
No services at New Jersey have yet ceased operation, that is operating with a delay to the ETA of August 13th due to internal reconfigurations. It's all still up and will only start to cease later today, and progressively at that.
This also allowed for additional time for any last-minute backups that could be needed.
This has been sorted out, it was an error on the multiqueue implementation network-wise exclusively for some 1 vCPU nodes. 3.7% of the VMs were affected and this has been sorted out entirely.
Sounds like a solid upgrade especially the focus on performance and keeping prices unchanged for 2026. The reduced RAM usage and zero-downtime migration are particularly nice improvements
Looking forward to seeing how EagleKey performs in practice