All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
PSA: Your bare-metal server could be silently virtualized after deployment — here's how to check
Recently became aware of a case where a budget hosting provider silently installed a KVM hypervisor on a customer's bare-metal dedicated server — while the customer was actively using it. The OS was live-migrated into a VM, specs were cut (RAM halved, disk shrunk, CPU swapped to shared vCPUs), and the freed resources were presumably resold. The customer only noticed because they had persistent journald logging and the DMI string changed between boots.
Not naming the provider. But it made me realize most of us verify hardware once at deployment and never look again. Here's how to check yours right now.
Quick check — 10 seconds:
systemd-detect-virt
Returns none = bare metal. Anything else (kvm, xen, vmware) = you're in a VM.
Deeper checks (click to expand)
# Should show your real hardware vendor, not QEMU or Bochs
dmidecode -s system-manufacturer
dmidecode -s system-product-name
# CPU model should match what you ordered
lscpu | grep "Model name\|Hypervisor"
# Real disks are /dev/sd* or /dev/nvme*
# Virtual disks show as /dev/vd* (virtio)
lsblk
# Real disks support SMART, virtual disks don't
smartctl -i /dev/sda 2>&1 | head -10
# Bare metal ACPI tables come from your board vendor (AMI, Dell, HP, Supermicro)
# VMs show BOCHS or QEMU
dmesg | grep "ACPI: RSDP"
Check if it happened in the past (click to expand)
If you have persistent journald logging enabled, compare the DMI string across previous boots:
journalctl -b -1 -k | grep "DMI:"
journalctl -b -2 -k | grep "DMI:"
If the vendor string changes between boots, that's your answer.
Set up ongoing monitoring (click to expand)
Checking once isn't enough if it can happen at any time after deployment.
# Cron — checks every 5 minutes, alerts you if anything changes
*/5 * * * * [ "$(systemd-detect-virt)" != "none" ] && curl -s "https://your-webhook-url"
If you're running full disk encryption, consider having the watchdog trigger an immediate shutdown on detection. Once your server is inside a VM, the hypervisor admin has visibility into your decrypted storage. Shutting down locks the disk.
TLDR: Run systemd-detect-virt on your dedicated server right now. If it doesn't return none, you have a problem. Then set up a cron to keep checking — because it can happen at any time, not just at deployment.
- Yes — it's clean, bare metal confirmed34 votes
- Yes — and I found something suspicious20.59%
- No — checking now20.59%
- I don't have a dedicated server58.82%
Comments
You should definitely name the provider. How can you shrink disks and RAM that a customer is actively using, without crashing everything?
Not naming them — the server is still in use and I'd rather not invite retaliation from a budget US provider. I'll leave it at that.
To answer your technical question: they didn't resize a running VM. The physical machine had IPMI/BMC with a secondary operator-level account the provider retained. They used that to access the serial console (SOL), rebooted the machine into a PXE network boot, installed a hypervisor, and migrated the customer's OS into a VM from a copy of the running disk. The customer's SSH sessions crashed when the physical machine went down for the switch.
This is why checking once at deployment isn't enough — the provider has out-of-band access to your hardware at all times. Changing your IPMI passwords and monitoring for virtualization after the fact is really the only defense available to a dedicated server customer.
That's just fucking hilarious and I don't believe it actually happened unless you tell us who did it.
Also if they did it to 1 customer there's at least a chance they've done it more than once.
Wait is your name a clue?
@zed Haha, no, the name's not a clue — been using it for years.
I get the skepticism. All I can say is: the technical details I described (IPMI operator account + SOL + PXE boot + disk copy) are a real attack path that works on any standard Supermicro/Dell/HP dedicated server where the provider retains BMC access. Whether you believe this specific case happened or not, the detection methods in the post still work.
And yes, if they did it once, they've almost certainly done it to others. That's kind of the whole point of this post. There have been threads on LET recently about budget providers silently relocating customers to different datacenters without notice — if they're willing to move your machine to a different city, virtualizing it in the same rack isn't exactly a stretch.
Are you using AI?
so the customer had their resources halved, but that the server is still in use.
are you saying that nothing was done about it, they didn't make a ticker or anything, they just accepted half the resources they paid for and are happy to continue paying them and not say anything?
this smells..
@Pandy The customer did open a ticket. The provider denied everything, restored it to bare metal during the ticket exchange, then deleted the journal entries that proved it happened. The customer has full forensic evidence backed up offline but chose not to go public because the server is still needed and there aren't many alternatives at that price point in the same location. Not ideal, but that's the reality of budget dedicated servers — your leverage is limited when the provider knows you don't have many options.
@Obelous Yeah I used AI to help clean up the writing — English isn't my first language. The technical details and the incident are real though.
I do actually believe it, I was just trying to cleverly trick you into insisting on telling us!
What's this? The Truman Show? Too crazy!
You don’t have to provide a name, a color would be good to know - red, green, purple or something else?
Because it fucking didn’t happen
Let me guess, George Datacenter?
This thread reads like an april 1st joke.
Name and shame.
Do not enable shitty behavior by hiding it.
@SGraf Didn't even realize the timing — this happened on March 31st and I've been writing it up since. Worst possible day to post about something real, I know. The detection commands work regardless of what day it is though.
@MaxTakeba I get it. If things change I might. Right now the priority is keeping the server running. The point of this post was always the detection method, not the drama.
I doubt the feasibility of this solution, because it won't help the provider make more profit. There are too many complex manual operations just to save a few dollars. I think it's more like an operation against specific customers. It might have been done at the request of law enforcement agencies or something like that. But I have to say that even in this case, the work was done in a dirty way.
AI hallucination alert, post created by bot.
This didn't happen!
Are you a construction worker and this is your hobby, like the other bot? @enzosama
@rustelekom Interesting perspective, but I'd push back on the "too complex for a few dollars" argument. If the provider runs blade chassis with 10-12 nodes each, the whole process can be scripted: scan utilization across nodes → flag low-usage machines on promo plans → dd the running block device to a virtual disk → install hypervisor → boot the copy as a VM. One script, applied to an entire chassis, frees up resources worth 2-3x the original revenue per node. It's not manual work per customer — it's a batch operation.
And consider: there was a thread on LET recently about a budget provider silently relocating VPS customers to a different datacenter without notice. If a provider has the operational capability and willingness to move machines between cities without telling customers, virtualizing them in place is a smaller step, not a bigger one.
As for law enforcement — no. The customer's data wasn't targeted. The VM was created with a generic template (standard vCPU/RAM allocation), not a forensic image. This was resource optimization, not surveillance.
source: my ai model told me so
WTF?
This is the first time I've ever heard of such a thing since LET was formed and you won't tell us who did it?
And what retaliation? What can they do - cancel the service? But surely no one would continue to use such an insidious provider, so...what is there to lose?
What you're saying is that the customer is so desperate for service that they'll stick with this provider anyways. No geography is that rare.
Yes it is. Providers relocate customers to different datacenters for network reasons, for bill-paying reasons, etc. But to actually conduct the relatively sophisticated attack you're describing is a stretch. Can you point to any examples of others doing this?
NAMES OR GTFO
fake & gay. this thread belongs in off-topic
If OP won't name then I can only assume this to project and a ruse.
Something smells fishy.
A better april fools would be to go the other way (vm->dedicated). :P
where are your balls man
If any of my providers, buget or not, critical or not would pull this shit on me, I'd name and shame them to oblivion.
So this is either fake, or you (or your client) are under some strong Stockholm syndrome bullshit.
Can you ask the provider to do a write up of how to live migrate a dedi to a VM. Sounds like something that'd be useful!