Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

DeluxHost.net | VPS Restock | Improved Storage Servers! | Z / T / Q | Highly DDoS Protected | NL

2»

Comments

  • @DeluxHost
    Hi!
    I couldn't SSH into my server today until I rebooted it. I see errors on the VNC console (screenshot attached), and there is also very high steal time ( >20 ) (video attached).
    Can you fix this?
    Thanks!
    P.S. And i can't submit this support ticket because your portal glitches out after I try to log in.
    errors

    Steal time - https://anonmp4.art/v/xWYg8Xym5hbuwU5

  • DeluxHostDeluxHost Member, Patron Provider

    @Loveyouvps said:
    @DeluxHost
    Hi!
    I couldn't SSH into my server today until I rebooted it. I see errors on the VNC console (screenshot attached), and there is also very high steal time ( >20 ) (video attached).
    Can you fix this?
    Thanks!
    P.S. And i can't submit this support ticket because your portal glitches out after I try to log in.
    errors

    Steal time - https://anonmp4.art/v/xWYg8Xym5hbuwU5

    Can you please send me your IP?

  • @DeluxHost said:

    @Loveyouvps said:
    @DeluxHost
    Hi!
    I couldn't SSH into my server today until I rebooted it. I see errors on the VNC console (screenshot attached), and there is also very high steal time ( >20 ) (video attached).
    Can you fix this?
    Thanks!
    P.S. And i can't submit this support ticket because your portal glitches out after I try to log in.
    errors

    Steal time - https://anonmp4.art/v/xWYg8Xym5hbuwU5

    Can you please send me your IP?

    I sent it to your forum pm box.

  • DeluxHostDeluxHost Member, Patron Provider

    @Loveyouvps said:

    @DeluxHost said:

    @Loveyouvps said:
    @DeluxHost
    Hi!
    I couldn't SSH into my server today until I rebooted it. I see errors on the VNC console (screenshot attached), and there is also very high steal time ( >20 ) (video attached).
    Can you fix this?
    Thanks!
    P.S. And i can't submit this support ticket because your portal glitches out after I try to log in.
    errors

    Steal time - https://anonmp4.art/v/xWYg8Xym5hbuwU5

    Can you please send me your IP?

    I sent it to your forum pm box.

    Will check in some hours

  • XakerzXakerz Member
    edited October 7

    I like it to wake up in the morning and find out that VPS is full of errors
    This time it survive 12 days lol

    Asked 4th time to move VPS to a Healthy node... will see...

    https://ibb.co/4wqSyfm9

    Screenshot-1

    ticket #TMTCIBEXQS5XY

  • kaitkait Member

    @forest said: @DeluxHost With all due respect, I have to agree with @zGato here. I use and enjoy your services, but you should prioritize fixing issues such as that strange persistent I/O failure that keeps occurring (system reboots and can't find the drive until it's force-reset from the panel) and clearing your ticket backlog.

    There is nothing wrong anywhere, stop saying there are issues. Everything works. Also we are connected to a gazillion networks and if you say otherwise, you are just lying because my spaghetti brain says its true.

  • DeluxHostDeluxHost Member, Patron Provider

    @Xakerz said:
    I like it to wake up in the morning and find out that VPS is full of errors
    This time it survive 12 days lol

    Asked 4th time to move VPS to a Healthy node... will see...

    https://ibb.co/4wqSyfm9

    Screenshot-1

    ticket #TMTCIBEXQS5XY

    Thanks for the report, Will check in some Hours this too

  • @DeluxHost do you have issues with authentication for the Dashboard? Can't seem to be able to login.


    Our experience with DeluxHost VPSs, September–October 2026

    We run six DeluxHost VPSs (Netherlands; F-4, Z-4 and L-4 plans) as part of a small Kubernetes cluster, next to VPSs at another provider that run the same operating system and workloads. Everything below comes from our own continuous monitoring: CPU steal measured inside each VPS, disk I/O stall time, and packet loss probes between all our servers every 15 seconds.

    We hold every VPS to the same bar. Over 72 hours:

    • CPU steal below 5% on average
    • no storage stalls
    • packet loss below 1%

    Our VPSs at the other provider meet that bar, with 0–2% steal.

    In this post the six VPSs are called VPS A to VPS F:

    VPS Plan
    A, E F-4
    B, C, D Z-4
    F L-4

    What we saw

    From the first week of September, CPU steal on several DeluxHost VPSs was far above that bar: 55–65% on one (ticket TMTNFIXBEG5CG) and 36–50% on VPS A, while our own processes used only a few percent of the CPU.

    ![VPS A: CPU steal from 7 September to 6 October, rising from about 36% to about 50% after the migration was proposed on 28 September](https://i.imgur.com/vg7EgyN.png

    The CPU steal followed the host, not the plan. Three VPSs on the same Z-4 plan sat at 5–6% on Xeon E5-2650 v4 hosts and at about 21% on a Xeon Platinum 8173M host.

    Average CPU steal per VPS, 29 September to 6 October, coloured by host CPU, next to our VPSs at another provider

    Three Z-4 VPSs also had their virtual disks stop completing any I/O for 20–70 minutes at a time, 30–60% of the time, from the day they were delivered (ticket TMULCTBQ5KZCM, opened 28 September).

    What DeluxHost did

    On 28 September DeluxHost offered to migrate the affected VPSs, and we agreed the same day.

    The disk freezes stopped on the evening of 29 September, after the VPSs were restarted without notice. That fix has held ever since, and we are grateful for it.

    Share of time each Z-4 VPS's disk was fully stalled, dropping to zero on the evening of 29 September

    The CPU steal remained, and so did a new packet-loss problem on one of the restarted VPSs. The migration itself did not follow for a week, despite several reminders in the ticket.

    On the evening of 6 October, after a further request to move the VPSs to less loaded hosts (ticket TMUX3OSZQYYBU), DeluxHost moved all of them within a few hours. Several were unreachable for one to three hours during the moves. Two did not come back usable, and we reinstalled both ourselves:

    • one failed to boot (the root filesystem could not be mounted)
    • one had a broken container runtime

    Where things stand on 7 October

    Right after the moves the results were very good: steal on VPS A and VPS B dropped from about 50% and 20% to 0–5%. The following morning the picture was mixed again.

    CPU steal per VPS over the last 24 hours, with the 5% target

    VPS CPU steal Packet loss
    E 3–4% 1–9%
    A, D 5–6% 2–6%, up to 15% at times
    B about 10% none
    C back at 15–25% (was 4–6% right after the move) 4–15%
    F about 22% throughout (ticket TMUN4DZW64YDO) 16–17%

    None of the six meets our bar yet.

    Packet loss to VPS A, C and D has risen steadily since the moves, from around 1% to about 5% on average, as seen from both of our other locations.

    Packet loss to each VPS over the last 24 hours, with the 1% target; grey marks the moves

    Our take

    DeluxHost's support does act on detailed evidence. The disk fix and the quick moves on 6 October show that the hardware can perform well.

    The problem is consistency:

    • CPU capacity on the hosts appears to fill up again within hours of a move.
    • Changes happened without notice and outside the window we agreed.
    • We waited a week for a migration we had already approved.

    We are continuing to measure and will decide per VPS after 72 hours of data.

    Related tickets: TMTNFIXBEG5CG, TMULCTBQ5KZCM, TMUN4DZW64YDO, TMUX3OSZQYYBU.

  • semanseman Member

    @forest said:

    @zGato said: stop selling shit until you fix your mess

    @DeluxHost With all due respect, I have to agree with @zGato here. I use and enjoy your services, but you should prioritize fixing issues such as that strange persistent I/O failure that keeps occurring (system reboots and can't find the drive until it's force-reset from the panel) and clearing your ticket backlog.

    @DeluxHost said:

    @johndeo983 said:
    Heard you allow spam

    Is this true?

    anything legal is allowed, otherwise not.

    Does this mean Tor exits are allowed? They are legal.

    no need as long he get money. people keep buying anyway lol

  • LoveyouvpsLoveyouvps Member
    edited October 7

    @Homelabby said:
    @DeluxHost do you have issues with authentication for the Dashboard? Can't seem to be able to login.


    Our experience with DeluxHost VPSs, September–October 2026

    We run six DeluxHost VPSs (Netherlands; F-4, Z-4 and L-4 plans) as part of a small Kubernetes cluster, next to VPSs at another provider that run the same operating system and workloads. Everything below comes from our own continuous monitoring: CPU steal measured inside each VPS, disk I/O stall time, and packet loss probes between all our servers every 15 seconds.

    We hold every VPS to the same bar. Over 72 hours:

    • CPU steal below 5% on average
    • no storage stalls
    • packet loss below 1%

    Our VPSs at the other provider meet that bar, with 0–2% steal.

    In this post the six VPSs are called VPS A to VPS F:

    VPS Plan
    A, E F-4
    B, C, D Z-4
    F L-4

    What we saw

    From the first week of September, CPU steal on several DeluxHost VPSs was far above that bar: 55–65% on one (ticket TMTNFIXBEG5CG) and 36–50% on VPS A, while our own processes used only a few percent of the CPU.

    ![VPS A: CPU steal from 7 September to 6 October, rising from about 36% to about 50% after the migration was proposed on 28 September](https://i.imgur.com/vg7EgyN.png

    The CPU steal followed the host, not the plan. Three VPSs on the same Z-4 plan sat at 5–6% on Xeon E5-2650 v4 hosts and at about 21% on a Xeon Platinum 8173M host.

    Average CPU steal per VPS, 29 September to 6 October, coloured by host CPU, next to our VPSs at another provider

    Three Z-4 VPSs also had their virtual disks stop completing any I/O for 20–70 minutes at a time, 30–60% of the time, from the day they were delivered (ticket TMULCTBQ5KZCM, opened 28 September).

    What DeluxHost did

    On 28 September DeluxHost offered to migrate the affected VPSs, and we agreed the same day.

    The disk freezes stopped on the evening of 29 September, after the VPSs were restarted without notice. That fix has held ever since, and we are grateful for it.

    Share of time each Z-4 VPS's disk was fully stalled, dropping to zero on the evening of 29 September

    The CPU steal remained, and so did a new packet-loss problem on one of the restarted VPSs. The migration itself did not follow for a week, despite several reminders in the ticket.

    On the evening of 6 October, after a further request to move the VPSs to less loaded hosts (ticket TMUX3OSZQYYBU), DeluxHost moved all of them within a few hours. Several were unreachable for one to three hours during the moves. Two did not come back usable, and we reinstalled both ourselves:

    • one failed to boot (the root filesystem could not be mounted)
    • one had a broken container runtime

    Where things stand on 7 October

    Right after the moves the results were very good: steal on VPS A and VPS B dropped from about 50% and 20% to 0–5%. The following morning the picture was mixed again.

    CPU steal per VPS over the last 24 hours, with the 5% target

    VPS CPU steal Packet loss
    E 3–4% 1–9%
    A, D 5–6% 2–6%, up to 15% at times
    B about 10% none
    C back at 15–25% (was 4–6% right after the move) 4–15%
    F about 22% throughout (ticket TMUN4DZW64YDO) 16–17%

    None of the six meets our bar yet.

    Packet loss to VPS A, C and D has risen steadily since the moves, from around 1% to about 5% on average, as seen from both of our other locations.

    Packet loss to each VPS over the last 24 hours, with the 1% target; grey marks the moves

    Our take

    DeluxHost's support does act on detailed evidence. The disk fix and the quick moves on 6 October show that the hardware can perform well.

    The problem is consistency:

    • CPU capacity on the hosts appears to fill up again within hours of a move.
    • Changes happened without notice and outside the window we agreed.
    • We waited a week for a migration we had already approved.

    We are continuing to measure and will decide per VPS after 72 hours of data.

    Related tickets: TMTNFIXBEG5CG, TMULCTBQ5KZCM, TMUN4DZW64YDO, TMUX3OSZQYYBU.

    Judging by the support response from @DeluxHost , for example, on my plan (T-2 with 1 vCPU processor), this kind of steal is normal...
    But I understand and know, having experience with many other hosting providers and single-core servers (including those I've used) that this is absolutely not normal. I've been on the forum for over two years and, knowing DeluxHost, I can say that for them, this is normal, but what you should do is up to you...

  • KylinTKylinT Member

    What's the bandwidth for T-series VPS? Does it unmetered? Thx

  • zqqzqqzqqzqq Member

    Order #7938307581
    +1 GB RAM

  • DeluxHostDeluxHost Member, Patron Provider

    @KylinT said:
    What's the bandwidth for T-series VPS? Does it unmetered? Thx

    Hello, nope, we have FUP

  • DeluxHostDeluxHost Member, Patron Provider
    edited October 7

    @Loveyouvps said:

    @Homelabby said:
    @DeluxHost do you have issues with authentication for the Dashboard? Can't seem to be able to login.


    Our experience with DeluxHost VPSs, September–October 2026

    We run six DeluxHost VPSs (Netherlands; F-4, Z-4 and L-4 plans) as part of a small Kubernetes cluster, next to VPSs at another provider that run the same operating system and workloads. Everything below comes from our own continuous monitoring: CPU steal measured inside each VPS, disk I/O stall time, and packet loss probes between all our servers every 15 seconds.

    We hold every VPS to the same bar. Over 72 hours:

    • CPU steal below 5% on average
    • no storage stalls
    • packet loss below 1%

    Our VPSs at the other provider meet that bar, with 0–2% steal.

    In this post the six VPSs are called VPS A to VPS F:

    VPS Plan
    A, E F-4
    B, C, D Z-4
    F L-4

    What we saw

    From the first week of September, CPU steal on several DeluxHost VPSs was far above that bar: 55–65% on one (ticket TMTNFIXBEG5CG) and 36–50% on VPS A, while our own processes used only a few percent of the CPU.

    ![VPS A: CPU steal from 7 September to 6 October, rising from about 36% to about 50% after the migration was proposed on 28 September](https://i.imgur.com/vg7EgyN.png

    The CPU steal followed the host, not the plan. Three VPSs on the same Z-4 plan sat at 5–6% on Xeon E5-2650 v4 hosts and at about 21% on a Xeon Platinum 8173M host.

    Average CPU steal per VPS, 29 September to 6 October, coloured by host CPU, next to our VPSs at another provider

    Three Z-4 VPSs also had their virtual disks stop completing any I/O for 20–70 minutes at a time, 30–60% of the time, from the day they were delivered (ticket TMULCTBQ5KZCM, opened 28 September).

    What DeluxHost did

    On 28 September DeluxHost offered to migrate the affected VPSs, and we agreed the same day.

    The disk freezes stopped on the evening of 29 September, after the VPSs were restarted without notice. That fix has held ever since, and we are grateful for it.

    Share of time each Z-4 VPS's disk was fully stalled, dropping to zero on the evening of 29 September

    The CPU steal remained, and so did a new packet-loss problem on one of the restarted VPSs. The migration itself did not follow for a week, despite several reminders in the ticket.

    On the evening of 6 October, after a further request to move the VPSs to less loaded hosts (ticket TMUX3OSZQYYBU), DeluxHost moved all of them within a few hours. Several were unreachable for one to three hours during the moves. Two did not come back usable, and we reinstalled both ourselves:

    • one failed to boot (the root filesystem could not be mounted)
    • one had a broken container runtime

    Where things stand on 7 October

    Right after the moves the results were very good: steal on VPS A and VPS B dropped from about 50% and 20% to 0–5%. The following morning the picture was mixed again.

    CPU steal per VPS over the last 24 hours, with the 5% target

    VPS CPU steal Packet loss
    E 3–4% 1–9%
    A, D 5–6% 2–6%, up to 15% at times
    B about 10% none
    C back at 15–25% (was 4–6% right after the move) 4–15%
    F about 22% throughout (ticket TMUN4DZW64YDO) 16–17%

    None of the six meets our bar yet.

    Packet loss to VPS A, C and D has risen steadily since the moves, from around 1% to about 5% on average, as seen from both of our other locations.

    Packet loss to each VPS over the last 24 hours, with the 1% target; grey marks the moves

    Our take

    DeluxHost's support does act on detailed evidence. The disk fix and the quick moves on 6 October show that the hardware can perform well.

    The problem is consistency:

    • CPU capacity on the hosts appears to fill up again within hours of a move.
    • Changes happened without notice and outside the window we agreed.
    • We waited a week for a migration we had already approved.

    We are continuing to measure and will decide per VPS after 72 hours of data.

    Related tickets: TMTNFIXBEG5CG, TMULCTBQ5KZCM, TMUN4DZW64YDO, TMUX3OSZQYYBU.

    Judging by the support response from @DeluxHost , for example, on my plan (T-2 with 1 vCPU processor), this kind of steal is normal...
    But I understand and know, having experience with many other hosting providers and single-core servers (including those I've used) that this is absolutely not normal. I've been on the forum for over two years and, knowing DeluxHost, I can say that for them, this is normal, but what you should do is up to you...

    We are always happy to help.

  • Order ID: #9066411351

    Did not know there is a latest post lol, but will comment as well, Thanks

  • Order #2973740154
    Preference: +1 vCore

    Thanks!

  • forestforest Member

    @DeluxHost Just FYI, 46.34.3.123 is down (state is powered off) since yesterday and attempting to boot it results in it reporting the boot failed after 4 minutes.

Sign In or Register to comment.