2025 SALE: AMD EPYC KVM Servers from €4.99/mo – Limited Stock!

layer7

@hyperblast said:
i checked all my vps and none of the providers i have a vps with has qemu qemu-kvm installed!

thanks go out to:
@advinservers @dataforest @AlexPads @NDTN @hostiko @HostSlick @MannDude @IONOS @layer7 @lnx @LiteServer

Hi,

unfortunately i have to correct this at this point.

By default the qemu-guest-agent IS installed on the images we provide. ( Except debian 12 image i think which was ?!forgotten?! ).

This is technically necessary to offer functions like automatic IP address reconfiguration or rootpassword resets on click in the clientarea. Also its supporting functions like snapshots/backups to have smoother micro fs-freezes for them.

Its not used to spy users. Doing so is most probably illegal anyway, at least according to german law.

Thats like someone is renting an appartment from you and using another key to check frequently if all is in order inside. Thats so hard privacy violation... we dont do such things.

There are anyway enough possibilities to measure what ever relevant usages from the outside.

No need to spy....

hyperblast

@Advin said:

@hyperblast said:

@gbzret4d said:

@Motion3549 said:

@rattlecattle said:
Just checked the qemu guest agent logs on the VMs I have.

Roughly every 30 minutes qemu guest agent is running the command "bash -c ps -eo pcpu,args"

$ sudo journalctl -u qemu-guest-agent.service | grep 'guest-exec called'
<snip...>
Jul 25 19:01:59 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 19:31:59 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 20:01:44 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 20:31:45 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 21:01:43 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 21:31:59 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 22:02:01 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 22:31:41 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 23:01:54 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 23:31:51 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 26 00:01:43 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 26 00:30:38 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"

I guess that way it is possible for the host to monitor what processes are running, but auto banning users this way is very risky. There can be false positives.

How to uninstall this qemu guest completely?

sudo apt-get remove --purge qemu qemu-kvm

i checked all my vps and none of the providers i have a vps with has qemu qemu-kvm installed!

thanks go out to:
@advinservers @dataforest @AlexPads @NDTN @hostiko @HostSlick @MannDude @IONOS @layer7 @lnx @LiteServer

It's apt-get remove qemu-guest-agent, not qemu or qemu-kvm

Pretty much every hosting provider uses guest agent. It can help with VPS shutdowns, backups, changing passwords live, and pausing/resuming VMs.

Also, I believe that the big cloud providers like GCP also scan processes for malicious applications (e.g., XMR miners) unless it’s something like confidential computing. I could be wrong on this. It’s not something we would do but it’s something to note.

apt-get remove qemu-guest-agent removed at:

@advinservers @dataforest @AlexPads @hostiko @HostSlick @MannDude @lnx @LiteServer

these providers stood out positively because the qemu-guest-agent was not installed at all! and their systems also run stably:

@layer7 @IONOS @NDTN

hyperblast

@layer7 said:

@hyperblast said:
i checked all my vps and none of the providers i have a vps with has qemu qemu-kvm installed!

thanks go out to:
@advinservers @dataforest @AlexPads @NDTN @hostiko @HostSlick @MannDude @IONOS @layer7 @lnx @LiteServer

Hi,

unfortunately i have to correct this at this point.

By default the qemu-guest-agent IS installed on the images we provide. ( Except debian 12 image i think which was ?!forgotten?! ).

This is technically necessary to offer functions like automatic IP address reconfiguration or rootpassword resets on click in the clientarea. Also its supporting functions like snapshots/backups to have smoother micro fs-freezes for them.

Its not used to spy users. Doing so is most probably illegal anyway, at least according to german law.

Thats like someone is renting an appartment from you and using another key to check frequently if all is in order inside. Thats so hard privacy violation... we dont do such things.

There are anyway enough possibilities to measure what ever relevant usages from the outside.

No need to spy....

then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

COLBYLICIOUS

@hyperblast said:
after this loss of image, the community expects the best deals. how about:

4C (Threadripper PRO 9995WX),16GB,320GB NVME,15TB Traffic - 7€/month , 55,50€/year

@ehab @COLBYLICIOUS @gbzret4d @Mumbly

I agree with that.

layer7

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

gbzret4d

@hyperblast said:

@Advin said:

@hyperblast said:

@gbzret4d said:

@Motion3549 said:

@rattlecattle said:
Just checked the qemu guest agent logs on the VMs I have.

Roughly every 30 minutes qemu guest agent is running the command "bash -c ps -eo pcpu,args"

$ sudo journalctl -u qemu-guest-agent.service | grep 'guest-exec called'
<snip...>
Jul 25 19:01:59 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 19:31:59 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 20:01:44 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 20:31:45 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 21:01:43 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 21:31:59 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 22:02:01 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 22:31:41 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 23:01:54 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 25 23:31:51 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 26 00:01:43 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"
Jul 26 00:30:38 kvmXXXX qemu-ga[704]: info: guest-exec called: "bash -c ps -eo pcpu,args"

I guess that way it is possible for the host to monitor what processes are running, but auto banning users this way is very risky. There can be false positives.

How to uninstall this qemu guest completely?

sudo apt-get remove --purge qemu qemu-kvm

i checked all my vps and none of the providers i have a vps with has qemu qemu-kvm installed!

thanks go out to:
@advinservers @dataforest @AlexPads @NDTN @hostiko @HostSlick @MannDude @IONOS @layer7 @lnx @LiteServer

It's apt-get remove qemu-guest-agent, not qemu or qemu-kvm

Pretty much every hosting provider uses guest agent. It can help with VPS shutdowns, backups, changing passwords live, and pausing/resuming VMs.

Also, I believe that the big cloud providers like GCP also scan processes for malicious applications (e.g., XMR miners) unless it’s something like confidential computing. I could be wrong on this. It’s not something we would do but it’s something to note.

ok. i check again... and name the "sniffers" then.

@gbzret4d

I shouldnt post when im almost asleep, thanks @Advin for correcting me

hyperblast

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

i am the only client!

ProHosting24

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

That‘s not entirely true as well, if the pve hypervisor for whatever reasons needs the guests to be properly shutdown because the host itself is trying to shut it self down then the guest/vps process will just be terminated ungraceful with the possibilty to cause data corruption.
You would need an option to let the customer disable the guest agent entirely enabling the hypervisor to send ACPI shutdown signals instead of shutdown via guest agent.

Something we will look into ourselves for our new backend/frontend.

hyperblast

@ProHosting24 said:

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

That‘s not entirely true as well, if the pve hypervisor for whatever reasons needs the guests to be properly shutdown because the host itself is trying to shut it self down then the guest/vps process will just be terminated ungraceful with the possibilty to cause data corruption.
You would need an option to let the customer disable the guest agent entirely enabling the hypervisor to send ACPI shutdown signals instead of shutdown via guest agent.

Something we will look into ourselves for our new backend/frontend.

@layer7 please provide technical classification.

fLoo

@PrepaidHost said:
First of all, we take the feedback from the community seriously.

Our automated process monitoring system was originally introduced to detect and mitigate massive intentional abuse, especially related to outbound mail spam. Over the past months, we’ve seen significant volumes of deliberate mass mailing activity, not caused by hacked CMS installs, but by users knowingly operating mail spam tools. This created a severe threat to our infrastructure, IP reputation, and ultimately affected all customers.

The monitoring system worked by querying running processes via the qemu-guest-agent at regular intervals. It did not scan uploaded files, did not read file contents, and did not access user data. It simply looked for known abuse signatures in active processes.

That said, we understand the criticism:
The suspension for tools like qbittorrent-nox, without a manual review or warning, was too aggressive and not transparent enough. While not the intent, it unintentionally affected legitimate use cases and open-source binaries.

As of now, this type of automated monitoring has been completely disabled.
We're moving forward with a more refined detection system, where suspicious activity is reviewed manually before any action is taken.

We’re thankful for the honest (and blunt) feedback – it helped us recognize where we overstepped. Our goal is to keep the platform clean without compromising trust or fairness.

Just for reference, in Germany this is a massive breach of DSGVO and consumer rights and - more important - the so called "StGB" (criminal punishment act). The provider is activly scanning all processes and analysing them to a point, where customer data is at risk.

Section 202a StGB – Unauthorized Access to Data (Ausspähen von Daten)

If the provider unlawfully gains access to data that is specially protected (e.g., data secured against unauthorized access), this may constitute a criminal offense.

Section 202b StGB – Interception of Data (Abfangen von Daten)

If the provider intercepts data during its transmission (e.g., reading emails or other communications in transit), this may be punishable.

Section 203 StGB – Violation of Private Secrets (Verletzung von Privatgeheimnissen)

This applies primarily to individuals with professional confidentiality obligations (e.g., doctors, lawyers). It may apply to providers if they are handling such confidential data on behalf of these professionals (e.g., in a hosting or processing role).

E.g.:

[root@vps ~]# watch -n 1 mysqladmin -uroot -psecretpassword -hlocalhost processlist

[root@qemu-host ~]#
%CPU COMMAND
[...]
 0.0 watch -n 1 mysqladmin -uroot -psecretpassword -hlocalhost processlist

You get the point. This fucks with so many laws ..

I advice every single customer of this "hoster" to change all used passwords on that machine or any machines connected to or from that host, is it ssh, mysql, telnet, whatever application. Also, i filed a notice to the appropriate organisation in Germany which takes care of this fuckup.

I mean, everyone makes mistakes, but this is a deliberate act to spy on users processes and especially including process arguments (like passwords)!

nghialele

@fLoo said: I advice every single customer of this "hoster" to change all used passwords on that machine or any machines connected to or from that host, is it ssh, mysql, telnet, whatever application. Also, i filed a notice to the appropriate organisation in Germany which takes care of this fuckup.

I will simply let mine expired, no more renew.

PrepaidHost

We added 10 Servers
-> https://prepaid-host.com/aktion/2025-sale-m

gbzret4d

I don't understand why people want to pin abuse on open processes. I also have a torrent client open on some of my servers to help distribute legal torrents, and being blocked for that is completely unfounded. I'm not a host, but as already mentioned, there are many ways to detect possible abuse without even having to go down the CharityHost route.

tentor

@gbzret4d said:
I don't understand why people want to pin abuse on open processes.

Want to be Big Brother

tynan

Is there any refund policy?

PrepaidHost

We want to share one final post on the recent discussion – not to excuse anything, but to be fully transparent with the technical community here.

Yes, we ran a small automated system that queried running processes via qemu-guest-agent.
It executed:

bash -c 'ps -eo pcpu,args'
roughly every 30 minutes via qm guest exec.

The goal was to detect known abuse patterns — e.g., outbound spam tools — based on a simple signature list (downloaded from a central blacklist). If a match was found, the VM ID and process string were passed to our API, which then triggered a suspension. The code that handled this was fully automated and static. You can review the logic yourself in pseudocode terms:

enumerate all VMs
dump ps output
match strings from the blacklist
suspend if matched, with reason

Nothing was logged long-term, no content was parsed, and no file or disk access was ever performed. It was pure process string matching.

But let’s be clear: even just running ps aux inside a customer VM is already too much.
We underestimated how invasive this would feel — and how seriously this violates expectations and trust. That’s entirely on us.

This system is now completely and permanently removed. We’ll handle abuse differently going forward (e.g., outbound port blocks).

We’ve been around since 2018, and our focus remains the same: providing fast, affordable infrastructure — but without touching customer internals, ever again.

We thank everyone who voiced their criticism – even if it was harsh, it was deserved.
You helped make sure this won’t happen again.

— Christopher Sakel
Prepaid-Host.com

rattlecattle

@PrepaidHost said: The goal was to detect known abuse patterns — e.g., outbound spam tools — based on a simple signature list (downloaded from a central blacklist). If a match was found, the VM ID and process string were passed to our API, which then triggered a suspension. The code that handled this was fully automated and static. You can review the logic yourself in pseudocode term

The string comparison logic itself is flawed. What if someone runs a hello world bash script with the name "qbittorrent-nox". Is it going to be banned just because the process name matched to some list. Just a strcmp doesn't warrant a ban.

hezi

@rattlecattle said:
The string comparison logic itself is flawed. What if someone runs a hello world bash script with the name "qbittorrent-nox". Is it going to be banned just because the process name matched to some list. Just a strcmp doesn't warrant a ban.

The only reason a bash script should ever be named "qbittorrent-nox" is if it launches the real "qbittorrent-nox"

I'd actually say it's more flawed because of the reverse. You can just change the name of the binary. I find it hard to believe that the system was intended to stop spam or malicious actors because it would only catch the absolute lowest-hanging fruit. Change the name of your spam executable and you've competely bypassed their abuse system

seoworld

Danke Christopher - die Diskussion ist hier - in diesem Fachforum - offen und ehrlich geführt und hat viel zur Info beitragen. Und bei dieser Gelegenheit: die Angebote und Qualität sind super und preislich ein Hit! Vielen Dank und weiter so !

Thanks, Christopher – the discussion here, in this specialized forum, has been open and honest and has contributed a lot of information. And by the way, the offers and quality are fantastic, and the price is amazing! Thank you very much, and keep up the good work!

layer7

@hyperblast said:

@ProHosting24 said:

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

That‘s not entirely true as well, if the pve hypervisor for whatever reasons needs the guests to be properly shutdown because the host itself is trying to shut it self down then the guest/vps process will just be terminated ungraceful with the possibilty to cause data corruption.
You would need an option to let the customer disable the guest agent entirely enabling the hypervisor to send ACPI shutdown signals instead of shutdown via guest agent.

Something we will look into ourselves for our new backend/frontend.

@layer7 please provide technical classification.

Hi sir yes sir,

quiet simple in this case:

https://pve.proxmox.com/wiki/QEMU/KVM_ACPI_Guest_Shutdown

ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it. If not, it will be hard shutdown ( with the chance of dataloss -- which in the real world happens only under specific conditions ).

Alternatively ( like stated on the link i pasted ), the qemu guest agent can bring the system to a smooth(er) shutdown.

So there is actually no real need to have the qemu guest agent installed to have (cleaner) ACPI shutdowns.

ProHosting24

@layer7 said:

@hyperblast said:

@ProHosting24 said:

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

That‘s not entirely true as well, if the pve hypervisor for whatever reasons needs the guests to be properly shutdown because the host itself is trying to shut it self down then the guest/vps process will just be terminated ungraceful with the possibilty to cause data corruption.
You would need an option to let the customer disable the guest agent entirely enabling the hypervisor to send ACPI shutdown signals instead of shutdown via guest agent.

Something we will look into ourselves for our new backend/frontend.

@layer7 please provide technical classification.

Hi sir yes sir,

quiet simple in this case:

https://pve.proxmox.com/wiki/QEMU/KVM_ACPI_Guest_Shutdown

ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it. If not, it will be hard shutdown ( with the chance of dataloss -- which in the real world happens only under specific conditions ).

Alternatively ( like stated on the link i pasted ), the qemu guest agent can bring the system to a smooth(er) shutdown.

So there is actually no real need to have the qemu guest agent installed to have (cleaner) ACPI shutdowns.

yes sure but that won't work unless you completely disable qemu-agent support for the machine in proxmox, that's the reason it would make sense to implement a ui feature to make it more safe to run machines without an agent running guestside

proxmox won't try to shutdown the guest via acpi if guest-agent support is still enabled in proxmox db's guest config

borngreat

Did you add more L servers?

PrepaidHost

@borngreat said:
Did you add more L servers?

We added 10 Servers
-> https://prepaid-host.com/aktion/2025-sale-m
-> https://prepaid-host.com/aktion/2025-sale-l

weintraubthomas956

@PrepaidHost said:

@borngreat said:
Did you add more L servers?

We added 10 Servers
-> https://prepaid-host.com/aktion/2025-sale-m
-> https://prepaid-host.com/aktion/2025-sale-l

Why is my server offline so often?

PrepaidHost

@weintraubthomas956 said:

@PrepaidHost said:

@borngreat said:
Did you add more L servers?

We added 10 Servers
-> https://prepaid-host.com/aktion/2025-sale-m
-> https://prepaid-host.com/aktion/2025-sale-l

Why is my server offline so often?

Please Write an Ticket. I take a Look.

hyperblast

@layer7 said:

@hyperblast said:

@ProHosting24 said:

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

That‘s not entirely true as well, if the pve hypervisor for whatever reasons needs the guests to be properly shutdown because the host itself is trying to shut it self down then the guest/vps process will just be terminated ungraceful with the possibilty to cause data corruption.
You would need an option to let the customer disable the guest agent entirely enabling the hypervisor to send ACPI shutdown signals instead of shutdown via guest agent.

Something we will look into ourselves for our new backend/frontend.

@layer7 please provide technical classification.

Hi sir yes sir,

quiet simple in this case:

https://pve.proxmox.com/wiki/QEMU/KVM_ACPI_Guest_Shutdown

ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it. If not, it will be hard shutdown ( with the chance of dataloss -- which in the real world happens only under specific conditions ).

Alternatively ( like stated on the link i pasted ), the qemu guest agent can bring the system to a smooth(er) shutdown.

So there is actually no real need to have the qemu guest agent installed to have (cleaner) ACPI shutdowns.

thank you very much. i value your opinion and trust your judgement. you always write in detail and with technical expertise, and i also like to support ultra-local providers.

ProHosting24

@hyperblast said:

@layer7 said:

@hyperblast said:

@ProHosting24 said:

@layer7 said:

@hyperblast said:
then I was lucky, because I use my vps from you with debian 12. and if the qemu agent had been on it, it would be gone now. see my previous post.

Hi,

thats perfectly fine. Its your server and you are the boss on your server.

All you loose is that our clientareatools wont be able to do the job here and there when it comes to the helper functions. If you dont need/use them anyway, then it makes no difference at all.

That‘s not entirely true as well, if the pve hypervisor for whatever reasons needs the guests to be properly shutdown because the host itself is trying to shut it self down then the guest/vps process will just be terminated ungraceful with the possibilty to cause data corruption.
You would need an option to let the customer disable the guest agent entirely enabling the hypervisor to send ACPI shutdown signals instead of shutdown via guest agent.

Something we will look into ourselves for our new backend/frontend.

@layer7 please provide technical classification.

Hi sir yes sir,

quiet simple in this case:

https://pve.proxmox.com/wiki/QEMU/KVM_ACPI_Guest_Shutdown

ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it. If not, it will be hard shutdown ( with the chance of dataloss -- which in the real world happens only under specific conditions ).

Alternatively ( like stated on the link i pasted ), the qemu guest agent can bring the system to a smooth(er) shutdown.

So there is actually no real need to have the qemu guest agent installed to have (cleaner) ACPI shutdowns.

thank you very much. i value your opinion and trust your judgement. you always write in detail and with technical expertise, and i also like to support ultra-local providers.

Well that wont make his statement less wrong though? https://forum.proxmox.com/threads/openwrt-vm-reboot-shutdown-not-working.68154/post-307268

@layer7 said: ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it.

This is just simply not true, you can support my idea to let customers decide if ga support should be disabled hypervisor side to improve everyday operations (or make your statement true) or you can be against implementing such a feature as you don't see the point in it.

I just don't think that it's fair that i share my idea with you just out of friendlyness while you are saying that i am wrong.
Especially when people start to believe stuff that isn't technically correct, I'd appreciate it if you could tell me what bothers you so much since you always seem to be pretty chill and friendly as well, I mean unless you didn't know it better? @layer7

layer7

@ProHosting24 said:

@layer7 said: ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it.

This is just simply not true, you can support my idea to let customers decide if ga support should be disabled hypervisor side to improve everyday operations (or make your statement true) or you can be against implementing such a feature as you don't see the point in it.

I just don't think that it's fair that i share my idea with you just out of friendlyness while you are saying that i am wrong.
Especially when people start to believe stuff that isn't technically correct, I'd appreciate it if you could tell me what bothers you so much since you always seem to be pretty chill and friendly as well, I mean unless you didn't know it better? @layer7

@hyperblast said:
thank you very much. i value your opinion and trust your judgement. you always write in detail and with technical expertise, and i also like to support ultra-local providers.

Hi,

before things escalate in this beautiful LET Shark tank:

Firstly:

i pasted an information from Proxmox Wiki. So thats NOT my opinion. Thats the "Opinion" of Proxmox how they think their product works.

So if you are not happy with that, complain with Proxmox, not with me. I just referred to their information -- without any own opinion.

Secondly ( and because i usually at least try to be of use and helpful ):

I tested now, if the Wiki of Proxmox is fake news / outdated or correct.

How i tested:

• Using a vanilla Debian 12
• ACPI yes in proxmox
• qemu-guest-agent in proxmox enabled
• Stopping the qemu-guest-agent
• Checking in the Proxmox UI if qemu-guest-agent still reports informations ( like set IPs )

Then i clicked for the VM on the shutdown ( not stop ) and then an Proxmox sended an ACPI shutdown command to the VM.

In the logs i see about this command:

First:

https://ibb.co/5XHxz1pj

And then the services and bla bla shutting down properly.

Down to last log entry:

https://ibb.co/rGN1RK0d

Which, after all services shut down cleanly, the server was powered off.

---

So from my humble perspective, the information in the Proxmox wiki seems to be still correct.

I was testing with Version 8 of Proxmox.

If your systems behave differently, i suggest you to check out the VM settings you configured.

Especially in the options if ACPI is actually on ( which is the default i think anyway, but who knows ).

And another thing that might be important:

We use by default host-passthrough so all CPU capabilities are given to the guest. If you are using a CPU emulation, maybe that might be the reason why the ACPI signal wont make it properly through. -- Theoretically that should not make a difference... but theory usually dont apply to the real world.

Last but not least:

Sorry that i just gave the pictures as links. I am here on a short trip with the children and refuse to invest more than 1% brain to find out why the LET forum software will not just display the picture in the preview when i give the correct URL

ProHosting24

@layer7 said:

@ProHosting24 said:

@layer7 said: ACPI shutdowns will be sended to the OS. If the OS supports it, it will do it.

This is just simply not true, you can support my idea to let customers decide if ga support should be disabled hypervisor side to improve everyday operations (or make your statement true) or you can be against implementing such a feature as you don't see the point in it.

I just don't think that it's fair that i share my idea with you just out of friendlyness while you are saying that i am wrong.
Especially when people start to believe stuff that isn't technically correct, I'd appreciate it if you could tell me what bothers you so much since you always seem to be pretty chill and friendly as well, I mean unless you didn't know it better? @layer7

@hyperblast said:
thank you very much. i value your opinion and trust your judgement. you always write in detail and with technical expertise, and i also like to support ultra-local providers.

Hi,

before things escalate in this beautiful LET Shark tank:

Firstly:

i pasted an information from Proxmox Wiki. So thats NOT my opinion. Thats the "Opinion" of Proxmox how they think their product works.

So if you are not happy with that, complain with Proxmox, not with me. I just referred to their information -- without any own opinion.

Secondly ( and because i usually at least try to be of use and helpful ):

I tested now, if the Wiki of Proxmox is fake news / outdated or correct.

How i tested:

• Using a vanilla Debian 12
• ACPI yes in proxmox
• qemu-guest-agent in proxmox enabled
• Stopping the qemu-guest-agent
• Checking in the Proxmox UI if qemu-guest-agent still reports informations ( like set IPs )

Then i clicked for the VM on the shutdown ( not stop ) and then an Proxmox sended an ACPI shutdown command to the VM.

In the logs i see about this command:

First:

https://ibb.co/5XHxz1pj

And then the services and bla bla shutting down properly.

Down to last log entry:

https://ibb.co/rGN1RK0d

Which, after all services shut down cleanly, the server was powered off.

---

So from my humble perspective, the information in the Proxmox wiki seems to be still correct.

I was testing with Version 8 of Proxmox.

If your systems behave differently, i suggest you to check out the VM settings you configured.

Especially in the options if ACPI is actually on ( which is the default i think anyway, but who knows ).

And another thing that might be important:

We use by default host-passthrough so all CPU capabilities are given to the guest. If you are using a CPU emulation, maybe that might be the reason why the ACPI signal wont make it properly through. -- Theoretically that should not make a difference... but theory usually dont apply to the real world.

Last but not least:

Sorry that i just gave the pictures as links. I am here on a short trip with the children and refuse to invest more than 1% brain to find out why the LET forum software will not just display the picture in the preview when i give the correct URL

No you are right that feature was added in pve 8.4 back in april, we usually wait up to 6 months until upgrading. It would be great to see proxmox fixing even more stuff about it's behaviour with expecting the guest agent to be available. That would make it obsolete to have a feature in place and enables us to not care if the guest agent is configured but not available.

"Shutting down a VM with the QEMU guest agent enabled will now fall back to ACPI shutdown if the QEMU guest agent is not active."

https://pve.proxmox.com/wiki/Roadmap

I usually don't like to reference the proxmox wiki as i have stumbled across other wrong things to in the past as well, but as my main concern has been addressed that is not of any meaning to me. I was wondering about your assumption as shutting down guests with no running ga kills them instead of shutting them really down prior to 9th of april or when you upgraded to 8.4.

Actually there are a lot more other things that bother me about pve but their code base or docs don't look very much inviting to me, let's see what time will bring

PrepaidHost

We added 10 Servers
-> https://prepaid-host.com/aktion/2025-sale-m
-> https://prepaid-host.com/aktion/2025-sale-l