Slim down Promxmox? Disable corosync, pve-ha services?

[mdbraber]

Hi,

I'm running a single node Proxmox server as my homelab. Is it possible to disable / switch off unncessary services? What services could I switch off?

pve-ha-lrm
pve-ha-crm
spiceproxy (don't use)
corosync

Probably some (all) are vital, but I'd appreciate some insights on what I could safely disable when running a single node.

 

[Dominic]

Our documentation gives an overview of service daemons and their tasks. Turning off corosync is a start if you don't run a cluster.

 

[mdbraber]

Our documentation gives an overview of service daemons and their tasks. Turning off corosync is a start if you don't run a cluster.

Thanks Dominic - that's helpful! Is there a way to determine which I *can* switch off in a single node / non-cluster setup?

 

[Dominic]

It depends a lot on your requirements and I suggest you simply try it out in a test VM. The 4 services that you mentioned are a reasonable start.

This is not recommended and will reduce functionality and might void support, but if you want to trim down your PVE host service count nonetheless, you could go even further and for example run

systemctl stop pvestatd pve-ha-crm pve-ha-lrm pve-firewall pvefw-logger corosync spiceproxy

and still start VMs in the GUI. Some things like the icons in the resource tree, however, won't work. You could go on and do

systemctl stop pveproxy pvedaemon pvebanner

In this case the web interface is not working anymore, but you can still start and stop VMs via SSH.

edit: clarify that disabling those services is in general not recommended and might impact functionality

 

[mdbraber]

Thanks Dominic. I've implemented several of the services to be switched off. For anyone considering doing the same, you can override the systemctl files, but as After or Before can't be overriden without changing the whole file, you should use something like:

systemctl edit --full pve-manager

 

[Proxygen]

Also running a single node here with external firewall.

Do I have to also mask

pvefw-logger spiceproxy corosync pve-ha-crm pve-ha-lrm pve-firewall

or is it enough to just disable them?

 

[t.lamprecht]

or is it enough to just disable them?

disable only disables auto-starting of the service itself, but other services can still "load" it if they have a dependency on that service. For the HA services it's enough to disable them. For spiceproxy and firewall you'd need to mask them as pve-guests.service (the one doing the autostarts on boot and shutting down everything on shutdown) pulls them in with it's "Wants=" directive.

FYI: corosync only starts if there is a /etc/corosync/corosync.conf config, it has a ConditionPathExists=/etc/corosync/corosync.conf in it's unit file, so not point to mask/disable that one if no cluster is configured anyway.

 

[luison]

I understand this thread is old but as it still a "gray" area in PVE7, may I suggest for an easy way or a wiki document explaining how to disable unneeded services in single server PVE installations.

In our case with PVE 7 we've stopped and disabled

systemctl stop pve-ha-lrm pve-ha-crm corosync pvesr.timer pve-firewall pvefw-logger

And now testing it after edits to: systemctl edit --full pve-manager like:
systemctl edit --full pve-manager

Description=PVE guests
ConditionPathExists=/usr/bin/pvesh
RefuseManualStart=true
RefuseManualStop=true
Wants=pvestatd.service
Wants=pveproxy.service
Wants=spiceproxy.service
#Wants=pve-firewall.service
Wants=lxc.service
After=pveproxy.service
After=pvestatd.service
After=spiceproxy.service
#After=pve-firewall.service
After=lxc.service
#After=pve-ha-crm.service pve-ha-lrm.service

But after a restart and making sure it was disabled in the PVE UI, I see the firewall service is back on, so I am not sure if a "mask" of the service is required.

 

[LnxBil]

Why would you want to disable the firewall?

 

[Proxygen]

Why would you want to disable the firewall?

I'm also looking on how to accomplish disabling these services.

In my case, the firewall is replaced by something more robust (pfSense).

 

[t.lamprecht]

Besides that I'd really not agree that pfSense is not more robust than Linux kernel firewalls Proxmox VE uses, disabling the firewall service is not required for that either way. Firewall generation is disabled by default, and messing with PVE's services should be avoided, it might result in "interesting" (i.e., opposite of robust) effects due to not always obvious interactions of the Proxmox VE stack.

 

[Proxygen]

Besides that I'd really not agree that pfSense is not more robust than Linux kernel firewalls Proxmox VE uses, disabling the firewall service is not required for that either way. Firewall generation is disabled by default, and messing with PVE's services should be avoided, it might result in "interesting" (i.e., opposite of robust) effects due to not always obvious interactions of the Proxmox VE stack.

There is a reason ppl purchase and use pfsense/palo alto networks/fortinet/etc firewalls instead of using Netfilter. The feature set is incomparable, and even for some of the stuff which can be done with the latter, it is much easier to accomplish with the former.

 

[LnxBil]

There is a reason ppl purchase and use pfsense/palo alto networks/fortinet/etc firewalls instead of using Netfilter. The feature set is incomparable, and even for some of the stuff which can be done with the latter, it is much easier to accomplish with the former.

Sounds interesting, what are those features?

 

[Proxygen]

N

Sounds interesting, what are those features?

Normally I wouldn't reply to this question because it is out of scope for this forum. But let me chatGPT the answer for you. Should be mostly correct:

Here are some things that can be done with pfSense that cannot be done with Netfilter/Iptables:

1. Easy Web-based GUI: pfSense provides an easy-to-use web-based graphical user interface (GUI) that makes it simple to configure and manage the firewall rules. In contrast, Netfilter/Iptables requires manual configuration through the command line.
2. Multi-WAN support: pfSense supports multiple WAN (Wide Area Network) connections, which allows you to connect to multiple internet service providers (ISPs) and distribute traffic across them. This can provide increased redundancy and reliability for your network.
3. Traffic shaping and QoS: pfSense includes powerful traffic shaping and Quality of Service (QoS) features that allow you to prioritize and control network traffic based on a variety of factors, such as bandwidth, application, and user.
4. VPN support: pfSense supports a wide range of VPN protocols, including OpenVPN, IPSec, and PPTP. This allows you to create secure VPN connections for remote access, site-to-site connectivity, and other purposes.
5. Captive portal: pfSense includes a captive portal feature that allows you to create a custom splash page for guest Wi-Fi access. This can be used to display branding, terms of service, or other information, and can also require authentication before granting access to the network.
6. Package management: pfSense includes a built-in package management system that allows you to easily install and manage additional features and functionality, such as intrusion detection, content filtering, and more.

Overall, while both pfSense and Netfilter/Iptables are powerful firewall solutions, pfSense offers some additional features and functionality that can be useful for more complex network setups.

 

[alexskysilk]

site wide firewall and per guest firewalls are NOT MUTUALLY EXCLUSIVE. your site wide firewall doesn't provide protection for intrusions stemming from the inside.

 

[Proxygen]

site wide firewall and per guest firewalls are NOT MUTUALLY EXCLUSIVE. your site wide firewall doesn't provide protection for intrusions stemming from the inside.

correct. but I don't run guests for 3rd parties, I am the only person with access to them (and no guests even have SSH)

 

[alexskysilk]

I am the only person with access to them (and no guests even have SSH)

... that you know of. kinda the point. only a fool trusts his security just because he is not aware of any intrusion.

 

[luison]

This has become a firewall discussion now, apparently. In our case I'll say we do use iptables, but rules are generated via CSF, including on the containers. In any case, I can imagine that the firewall service running would not likely affect performance, so not terrible concern with it.

In any case, the discussion remains the same to me. Understanding that PVE is thought for HA and clustering systems I can imagine a very large percentage of installations are solo servers, so it would be very helpful if the developers clarified how to reduce the load of those services. In my case more than resources, I am also trying to reduce unneeded writes to disk from logs.

For the moment, I am running with the mentioned services and assuming that the firewall service will rerun at a certain point.

 

[t.lamprecht]

Normally I wouldn't reply to this question because it is out of scope for this forum. But let me chatGPT the answer for you. Should be mostly correct:

Here are some things that can be done with pfSense that cannot be done with Netfilter/Iptables:

1. Easy Web-based GUI: pfSense provides an easy-to-use web-based graphical user interface (GUI) that makes it simple to configure and manage the firewall rules. In contrast, Netfilter/Iptables requires manual configuration through the command line.
2. Multi-WAN support: pfSense supports multiple WAN (Wide Area Network) connections, which allows you to connect to multiple internet service providers (ISPs) and distribute traffic across them. This can provide increased redundancy and reliability for your network.
3. Traffic shaping and QoS: pfSense includes powerful traffic shaping and Quality of Service (QoS) features that allow you to prioritize and control network traffic based on a variety of factors, such as bandwidth, application, and user.
4. VPN support: pfSense supports a wide range of VPN protocols, including OpenVPN, IPSec, and PPTP. This allows you to create secure VPN connections for remote access, site-to-site connectivity, and other purposes.
5. Captive portal: pfSense includes a captive portal feature that allows you to create a custom splash page for guest Wi-Fi access. This can be used to display branding, terms of service, or other information, and can also require authentication before granting access to the network.
6. Package management: pfSense includes a built-in package management system that allows you to easily install and manage additional features and functionality, such as intrusion detection, content filtering, and more.

Overall, while both pfSense and Netfilter/Iptables are powerful firewall solutions, pfSense offers some additional features and functionality that can be useful for more complex network setups.

Besides 1. I can all do that with plain netfilters et al., so sure if you want a central web interface to manage your FW using something like pfSense is IMO certainly valid, and while certainly useful to some, framing that as being more powerful it's IMO misleading, as that would suggest that it can actually do more on its own, but it's rather just providing a UI that for people used to such things makes management easier.

I personally don't have uses for UI's but rather want git managed configs and nft scripts, with that I have a quick and simple overview, can back up and restore the whole thing easily, can deploy changes fast and have full change tracking.
Tbh, after the drama w.r.t. wireguard, pfSense/netgate left a bit of a sour impression from my side.

There is a reason ppl purchase and use pfsense/palo alto networks/fortinet/etc firewalls instead of using Netfilter. The feature set is incomparable, and even for some of the stuff which can be done with the latter, it is much easier to accomplish with the former.

Now if you compare to paolo alto or the likes then it's a different story, as for huge multi-site setups one might have a hard time finding the admins capable of managing this on a lower level, especially with the churn such companies go through it gets a basic requirement of paying big bucks to offload (most of) this into a comprehensive software (helping to) managing all that nicely - cannot be compared to pfSense though.

Anyhow, use what ever fits you need, I naturally don't care much about that and there are many tools to do the job. But those listed solutions, and especially pfSense can IME not be classified as more robust than standard Linux firewall technology like netfilter/nftables/bpf/..., which is what you originally wrote, as robustness doesn't mean more (management) features or a web UI.

 

[t.lamprecht]

In any case, the discussion remains the same to me. Understanding that PVE is thought for HA and clustering systems I can imagine a very large percentage of installations are solo servers, so it would be very helpful if the developers clarified how to reduce the load of those services. In my case more than resources, I am also trying to reduce unneeded writes to disk from logs.

Without a cluster corosync doesn't even run:

FYI: corosync only starts if there is a /etc/corosync/corosync.conf config, it has a ConditionPathExists=/etc/corosync/corosync.conf in it's unit file, so not point to mask/disable that one if no cluster is configured anyway.

So there's the pve-ha-lrm pve-ha-crm, which make most sense to disable if one wants to reduce disk writes, as they might occasionally write their last active status time to disk.

All other services don't log much if not enabled on a higher config/management level, and in that case you want to have them run anyway.

Note also that if log-reduction is your goal then disabling services is IMO the wrong solution anyway. For that you can:

1. purge rsyslog, it's a remain of the past and handled by systemd-journald anyway - newer PVE installations won't include it anyway. So having that installed and the journald persistent logging enable might duplicate your logging amount (not 1:1 as journald is much more efficient, but almost).
2. If you really don't care about logs
   1. mount /var/log in a tmpfs, that way it's backed by memory and no write on any (log) file there will hit the disk - reboot naturally clears memory, so all logs from the last reboot are lost.
   2. As alternative to 2.1., set the Storage=volatile option in /etc/systemd/journald.conf, that way only the journal file not be stored to disk.
3. If you only want to filter out some log you could override their service files using systemctl edit UNIT and add a snippet like:

   [Service]StandardOutput=null
   StandardError=null

   This will redirect all stdout/stder logging of that service to the void, naturally hiding also potential errors.

Personally I'd go for 1. and 2.2, as there you got reduced write impact on disk from system logging, but the full log from the current boot is still available with all messages/warings/errors - which can be def. useful.

Alternatively, get a small enterprise SSD (with power loss protection) for just the root fs and don't bother changing anything at all and enjoy having actual logs available to debug if things are going south..