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.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
This is our OpenClaw instance hallucinating.
Kindly close this thread.
Reguards
Blyat, everyone check their OVH DEDI!
I fkn knew it, the french did fuck us.
I hope this is meant to be an april fools joke
We can't express outrage properly without names, come on lad.
We got a few questions on whether the dedicated servers customers placed at South Pole Colocation would be virtualized.
The answer is currently not.
We still have colo space for a few million servers.
However, if global warming continues and our data center starts to melt, we may be forced to consolidate.
Even in that extreme case, you won’t notice any difference in
systemd-detect-virt.We’ll employ advanced TDMA technology so that multiple servers of the same model is merged into fewer servers.
You can still use your server normally, but any time it’s idle, our remote flappers would pass some of the hardware resources to other customers.
If you want to slow down the final consolidation, please help with environmental initiatives to slow down global warming:
ondemandCPU scheduler.Maybe, but this is a very strange way to minimize costs. Business, in general, is about making money out of thin air. So, call this implementation "improving the security of your data" or something else in the spirit of marketing, and you'll create a new niche in the market
As far as I remember, these options were once called "hybrid" options. A bad implementation is always bad for any transaction.
This is, of course, bad. At least the hoster should have informed the customers about the migration.
Understood.
BTW. Around 2006-2008, we conducted similar experiments, of course, with the permission of our client. The main goal was to transfer a dedicated server to an OpenVZ host and create a single large virtual machine to simplify the process of updating the operating system, moving between hardware servers, and migrating from one data center to another for our client. Although it was a good idea in theory, OpenVZ had limited features and significantly reduced server performance, leading to the termination of the experiment. Maybe TS case is result of new experiments with new virtualization:)
Something else worth doing — run
ipmitool user list 1on your server and check how many accounts exist. Most providers keep an operator-level account with their own password. That's enough to reboot your machine and access the serial console from home without you knowing. If you see one you didn't create, change the password.That's trivial. Vmware converter had that for free for ages. I don't know about kvm tools, but imagine ai could slap something together to automate it regardless.
Edit: https://pve.proxmox.com/wiki/Advanced_Migration_Techniques_to_Proxmox_VE
I particularly bolded live migrate.
If these guys are managing to pull off a live migration such that their servers aren't even going down while switching from bare metal to VPS, then they've accomplished quite a feat.
I can think of ways of dealing it with minimal downtime with root access (by adding sufficiently large swap, then suspend to swap and migrating before unsuspend), but not a live migration of a random dedi without a reboot which is what the OP claimed.
tbh i just ignored the live-migrated part, the idea that there's some lowend provider out there pulling these shenanigans just tickled me endlessly.
@ralf It wasn't a live migration — I said in the original post that "the customer's SSH sessions crashed when the physical machine went down for the switch." The machine went down, they copied the disk, installed a hypervisor, and booted the copy as a VM. Downtime was involved, just not announced.
You actually did say live-migrated, oops!
@enzosama What is this company you refuse to name reply to the support ticket? I sure hope the first thing you did was open a ticket since the resources paid for were drastically cut and changed to shared. Though it does say it was posted on April 1st so...
Yes, and VMWare converter does that, as do many Backup and restore apps like Veeam. It's just a matter of synchronizing them, shutting down the source and powering up the VM. It's generally 3-10 seconds of downtime, depending on switches and services. It generally goes unnoticed.
attention dedicated server owner you might be getting CUCKED
@Murv any thoughts on this
This obviously didn't happen. Live-migrating a running dedicated server?
Here's what really happened:
Anyway, OP is posting really naive detection mechanisms for a well-known malicious technique called "bluepill". However, this is not something that would be done by a shitty low-end host but by an APT with an advanced rootkit, and all the techniques he described to detect it would be defeated by a few simple patches to QEMU and some configuration changes.
Except that if it was on a dedi to start with, you'd need root access to prepare the suspend to disk, as I said above. Otherwise, all you could do is shutdown and migrate. That is why the fact OP said it was a live migration was remarkable. Although he's now backtracked and said it wasn't.
Again, I bolded live migration for a reason, and explained that reason multiple times.
Not only that, but he his LLM strongly implied it as well by suggesting running the tests in a cron job every 5 minutes, which indicates that he his LLM believes that the running system could be migrated to a VM without being shut down or disrupted.
And I replied with software that does what I quoted you asked for. You said one thing but implied something else (in-place hot migrate).
But we all know OP is full of shit with secondhand information and speculation.
@enzosama Is the company that you claim did this on LET?
They never said the provider didn't have root password, either. May have been autoinstalled from template instead of customer ISO. But also, with console access, they can boot to recovery and set root password. If the customer uses passwordless login with a key, they may not know if root was changed. It may never have been set!
But my point again, I answered the specific statement about live migration in general, not this nonexistent live in-place mythical scenario.
Maybe you need to read up on what LIVE migration means. And while you're at it, read the very first post in this thread, where the OP specifically says live migration.
You should definitely name the provider.
Yeah that’d actually be a solid guide live migrating dedi to VM isn’t trivial, would save a lot of people from trial-and-error headaches. That would be cool
Whoosh
It’s possible to do a live migration if the disks are moved to a proxmox hypervisor and you do disk pass through. However this would require a short downtime as the disks are physically moved from the bare metal server to a hypervisor, say 10 minutes. On power on the vm specs can be made identical to look like the bare metal server.
The problem is how the physical disks would be copied to the storage pool on the hypervisor. Obviously you can run the VM with disk passthrough but it’s more efficient to copy it to the zfs backed storage pool. There might be some tool out there that can detect and keep track of the block device and block changes while silently cloning it to the zfs pool.
OP seems to believe there's a risk that it can be done at any time while the system is running such that you'd need to run the check at 5 minute intervals... Which is, of course, nonsense.
That's not live migration, that's specifically cold migration.
It's generally ok to do live migrations anytime for a static server. Active Directory and databases are always recommended for cold migration to prevent corruption and other database consistency reasons.
Companies have been doing P2V live migration with VMWARE for ages. I did it 10 years ago at a previous job retiring Dell 2950 servers.
But can we all agree OP is getting incorrect third-party information? I mean, when he said ssh crashed instead of "closed" or "disconnected", you knew what kind of accuracy you're dealing with. Not even factoring in the lack of provider naming.
Fair point on the "live-migrated" wording, that was sloppy on my part. To be clear: the machine went down, disk was copied offline, hypervisor was installed, VM booted with the copy. Not a hot migration. The 5-minute cron isn't for detecting a live migration in progress, it's for catching the state after it's already happened and the VM is running. You reboot for maintenance, come back, everything looks normal, but you're in a VM now. That's the scenario.
And no, this wasn't diagnosed by AI. The evidence was systemd journal boot records showing DMI changing from the real motherboard vendor to QEMU between consecutive boots, on the same OS installation. That's not something an LLM hallucinates, it's what journalctl prints.
Anyway, the detection methods work regardless of whether you believe this specific case. I've said what I can say.