All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
[BEWARE] AlphaVPS kills KVM instance for reaching RAM limit (Debian 12/13)
Hi everyone,
I wanted to share a quick heads-up regarding a recent experience with AlphaVPS
I ordered a 512MB RAM KVM VPS to run a minimal Debian 12 setup. As we all know, Debian 12/13 runs perfectly fine on 512MB for headless tasks. However, I encountered constant, instant shutdowns.
Every time the VM reaches the allocated 512MB limit (e.g., during a standard apt upgrade), the provider's hypervisor forcefully kills the KVM process. This happens when installing with the ISO image or using their outdated debian 12 template and run dist-upgrade.
When contacted, the support claimed:
- 512MB is 'insufficient' for modern distros and I should use 'older ones'.
- The hypervisor shuts down the VM because it 'decided it uses too much RAM'.
- They claim a VM can 'temporarily use more RAM than allocated' in a KVM environment—which contradicts how KVM resource allocation works.
It seems they are running an extremely aggressive host-side monitoring that doesn't account for virtualization overhead (QEMU/KVM). Instead of capping the RAM at the limit and letting the Guest-OS handle it (OOM/Swap), they just pull the plug.
I was denied a refund despite the service being unfit for a standard Debian installation. Currently, a PayPal dispute is open.
Has anyone else seen this 'shutdown-on-limit' policy recently? It makes the allocated RAM effectively unusable if you can't even hit the 100% mark without a hard crash.
Specs: 512MB RAM / KVM / Debian 12
Comments
@AlexBarakov
This sounds weird, that's not really how KVM works. Guest can not exceed the allocated memory limit so it doesn't make sense for the host to "kill" the VM. Maybe your guest OS crashes?
Hmm, I am running OVZ 256MB vps with them and it is fine but I try to keep memory consumption limited.
No, it's not the OS. It's like the plug is pulled. Server "offline". VNC stopped. Immediately, during installation or upgrade.
OVZ is different since it's a container. On KVM the guest OS handles its memory management on its own and if it is not able to use all memory that has been allocated, it will end up very bad.
If the vm was swapless, adding 1gb of swap would have solved the issue.
Any screenshots of contact ?
That’s exactly the problem: the VM doesn't even get the chance to swap.
Swap is managed by the guest kernel. For the kernel to move pages to swap, it needs to reach a memory threshold first. However, this provider's hypervisor is so aggressive that it kills the entire KVM process the moment it touches the limit—before the guest OS even realizes it needs to start swapping or trigger its own OOM killer.
You can't solve a host-level 'hard kill' with a guest-level configuration like swap if the 'power' is cut instantly.
A 512MB VPS should be capped at 512MB by the hypervisor, allowing the guest OS to hit that ceiling and manage its own memory pressure (via swap or OOM). Killing the process externally at the first sign of 100% utilization is simply broken infrastructure and makes the allocated RAM unusable for any standard task like a kernel update
@patrick7 Are you writing with AI? this smells like AI...
This is usually a sign of a vps killed due to OOM, basically ram is oversold.
Sometimes, I use AI to polish my english. The issue is real and I'm a real person.
yeah probably. robot detected, opinion discarded. probably a user issue.
As said, I let AI help me improving my text. I'm not a native english speaker. There's nothing wrong with that in my opinion as long as everything is the truth (which it is!).
I gave AI my text to "write it in better words".
Anyways, can we please go back and focus on the issue? Thanks.
Yep, or a hard 512M limit for the KVM process (which includes, apart from the guest-usable memory, some overhead like Video RAM, ...).
Nope, guarantees that we run a lot under full utilization of RAM in any of our hundreds of hypervisors. But yes, with default settings from SolusVM applied to the hypervisor - the 512MB RAM instance does NOT really work well with any new OS. That's why we're completely removing the 15EUR/year plan, as it does not make either financial sense for us and only causes similar issues. Plan will be removed next week with our plan refresh and website update.
I do thank you for the random PayPal dispute, without even contacting us to request a refund, which would have been happily granted.
EDIT: You did request a refund, but as not eligible for one you received a denial from the team. I stand corrected, though issued an instruction to always allow exceptions similar to this.
It's going to be very tight if you try to install Debian 12/13 from ISO with 512MB -- not really recommended. (Here I mean the installation process from ISO)
How much swap space does their template include?
Check the ticket! I said that this request is my last one before taking actions. Your employee refused the refund, and I took actions!
Quote:
As this is not your first order, it's not eligible for a refund, but we are happy to assist you in any way possible to get your service running.
Absolutely, I already edited my response.
According to debian docs, 512M is sufficent. I tried it on several other instances and providers, and the only one that made issues was AlphaVPS.
?
I stand corrected there and edited my response. He did request a refund, was not eligible for one and was denied. Thus my later edit.
Thanks for the clarification @AlexBarakov
I'm happy with the refund and I guess everything important is said here.
Fair enough.
Is that really your policy? What does how many times someone has ordered from you have to do with issues that might lead to a customer requesting a refund? I haven't encountered this mutation before, sheltered perhaps.
My instinctive reaction is "make sure you don't ever order a 2nd service from this host, just in case".
This is a shield for specific types of customers. Rarely enforced. In reality 9 out of 10 refund requests are approved. Overall, our refund rates are very low, in single-digit amount per month, for the matter of transparency. We would never deny a refund when we're in the wrong. To continue transparency, in March we have processed 42x 15EUR/year 128G HDD orders. Out of them, not a single one complained. Luckily dipsute/chargeback rates are extremely low as well - for example @patrick7 is the first dispute/chargeback in over 40 days.
But I do know and do not deny in any way that Debian 13 is problematic on this plan. I have indeed seen other people experience similar problems, but the expectation is that they will find a way around it, due to the amount of resources they get for 1-ish EUR per month, IPv4 included.
Lastly, the issue is related to this specific thing:
https://support.solusvm.com/hc/en-us/articles/13268133793431-KVM-on-SolusVM-is-randomly-stopped-or-suspended-because-host-node-OOM-kills-corresponding-qemu-process
Our hard limit is 165 across all nodes, which usually gives ample of extra headroom for hypervisor needs.
@backtogeek I realize that this is neither your monkey nor your circus, but as you are the best expert on minimalism I know, can you speak to the RAM requirements of installing Debian 13?
I see that your Debian 13 template on Tierhive requires 256 MB RAM, but I assume that only means the template works with 256 MB RAM, not that you could actually install Debian 13 from scratch on 256 or 512 MB RAM.
We are running idling Debian 13 in Limitless Hosting $3/year 512MB IPv6-only KVM.
It was dist-upgrade from Debian 12, which in turn was manually installed from ISO.
The OS has 256MB swapfile.
I have no problems with Debian on a 512MB AlphaVPS KVM.
However, I have seen the issues before with SolusVM and a 512MB KVM with a different provider.
Essential, they didn't had a clue and suggested I upgrade.
I never seen this before, that the OOM killer inside the VM wasn't toggled but the Node killed the VM instead.
They actually gave me 512MB for free as an upgrade, never had issues since.
I'm well aware of the cheap price. I appreciated it - and neither I have big expectations nor I'm expecting miracles. I only have one requirement: The guest kernel must be able to address all bytes of memory that has been allocated to it by the hypervisor.
A fresh debian 13 installation uses around 184 mb memory. And debian clearly states in its docs that 512 M are enough for a minimal installation.
even I suspect the same. I've many 512MB vms with other hosts and never got killing instance on reaching 512MB RAM. Debian 13 works absolutely find on 512MB RAM.
Installing Debian 12/13 from ISO with 256MB RAM isn't going to work (without playing special tricks)
I installed Debian 12 from ISO with 768MB RAM recently, and although the installation succeeded, the installer needed to enter low-memory mode
I assume that 512MB RAM for installation from ISO could work, but it strikes me as living on the edge, and it may well depend on a provider's hypervisor and other settings whether this is easily doable in practice
Good enough, appreciate your taking the time. As a customer I tend to focus on customer-affecting bits but I try to be aware hosts need to protect themselves from bad actors too.