@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
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