Why does PVE need the hostname to be resolvable via /etc/hosts?
- Thread starter kayson
- Start date
Hi @kayson ,
Being able to resolve "hostname" without any external services is the very basic part of networking. You are already using Static IP (DHCP is not recommended for PVE/Server), so being able to resolve that IP to a hostname with minimum dependencies seems natural.
It may seem strange to some, but most people do not control the DNS they are using.
Finally, there is some explicit code that reads the context of /etc/hosts, whether for efficiency or historical reasons.
Regardless, name resolution via /etc/hosts is the fastest and most reliable option. It's also a barrier for thousands of forum posts titled "My internet is down, why is Proxmox not working?".
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
Being able to resolve "hostname" without any external services is the very basic part of networking. You are already using Static IP (DHCP is not recommended for PVE/Server), so being able to resolve that IP to a hostname with minimum dependencies seems natural.
It may seem strange to some, but most people do not control the DNS they are using.
Finally, there is some explicit code that reads the context of /etc/hosts, whether for efficiency or historical reasons.
Regardless, name resolution via /etc/hosts is the fastest and most reliable option. It's also a barrier for thousands of forum posts titled "My internet is down, why is Proxmox not working?".
Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
This makes no sense, sorry. The basic part of networking is to be routable. Yes, exactly, it is already forced to use static IPs so it's completely logical question on the OP's part to ask, just like people were asking why e.g. 127.0.1.1 had to be mapped, etc.
A root on a server cannot set his own nameservers?
This is the most politically correct way to put it - historical reasons.
No it's not, it's not even used for e.g. corosync which has its own config with IPs.
No, inexperienced user is really not the reason for hocus pocus requirements on the hosts file, sloppiness is.
Thanks. This is kind of what I figured. I can attempt to understand why you would want to force the installation to use a static IP and /etc/hosts, but I and it seems many other users, would like better support for DHCP.
Don't hold your breath for it. Proxmox installer will grab DHCP to begin with, but afterwards a server really needs a static IP.
DHCP Reservation in your router might be worth looking into if you want the pve instance to have a certain IP, but then you'll need to write down the MAC address in advance and configure that before booting the installer.
Proxmox is a clusterable, Enterprise-grade hypervisor. Just because a lot of people are using it for homelab doesn't mean the company will cater to that demographic.
DHCP Reservation in your router might be worth looking into if you want the pve instance to have a certain IP, but then you'll need to write down the MAC address in advance and configure that before booting the installer.
Proxmox is a clusterable, Enterprise-grade hypervisor. Just because a lot of people are using it for homelab doesn't mean the company will cater to that demographic.
Yes that's what I mean. DHCP, but not dynamic IP. IMO it's easier to centralize control of IP distribution this way. In fact that's what my enterprise does, so I don't think it just caters to homelabbers.
This is precisely why I'm asking. I know it breaks things, but it's not clear to me why. I would be surprised if there's a fundamental technical limitation (e.g. in Linux kernel) that requires this to be so.
Last edited:
This is a topic like ... opening a can of worms. Meanwhile after your last comment, it would be tossing in some DHCP into the DNS inquiry.
You will notice a lot of tokens of "wisdom" on this forum, the likes of earlier:
Or now:
And even:
Alas, the product name is PVE and O am not sure if it is "enterprise-grade" when one delves into the reasons, the actual reasons, the OP is seeking in this post.
You are asking the same kind of "child-like" questions as anyone curious who approached a black box and as it is open source and has an active community, rightfully so. You are getting the same kind of answers like when we asked why the sky was blue once. It's preposterous. Notice that none of the answers comes from PVE staff, they know better.
It's been over half a year since I had those same questions, over time I went through some of the code and noticed strange skeletons in the wardrobe like subroutines that are meant to obtain a remote node IP but with hackish comments of the sort "this is also used to get this node's IP", etc.
The whole PVE stack is like a pyramid and some of the pve-common parts are so ancient, it's hard to satisfactorily answer your question. With that said, it was asked so many times, it would really deserve an official FAQ section.
PVE clearly started as some MVP where lots of assumptions were made, simplicity was key, it helped streamline the early development. But then you build a lot of things on it, bugs pile on, things are harder to debug, introducing something like your casual request later is like being asked to touch a bee's nest.
Take for instance, that even if you do not use High Availability, that part of stack is always active, then there are bugs there (there's lots of self-denial and finger pointing when it comes to bugs on this forum), then if things get out of sync in an HA cluster, there will be reboots, you may basically end up completely losing the cluster if e.g. nodes would not be able to form a quorum.
Component like corosync which does not exactly run on the Perl scripts from PVE team has its own config file where hardcoded static addresses are preferred. You may wonder why, if everything was meant to be sourced from /etc/hosts, I would too. Then there is the "cluster filesystem", which is a shared database to which each node is meant to contribute, create its locks, etc. It is this part that needs to be synced amongst the nodes.
Now suppose you wanted the nodes to get DHCP assigned IPs (now if you are dreaming, you may as well dream big, imagine DHCP Option 12 support upon boot), it should not be a problem, each of your nodes should simply obtain other others' IPs from their resolver, you should be actually more stable in that there's no worries about discrepancies of /etc/hosts on different nodes.
But then you have to cater for cases when that resolver is taking its time, or you have round-robin and they get inconsistent, or two names return same IP, etc.
You will read on this forum how "corosync needs low latency" and thus PVE is not meant for geographically disparate nodes, etc. It's misrepresentation, corosync can set operate on any timeouts, but there's lots of hardcoded time limits when it comes to that e.g. cluster filesystem code because and there's no consistent helper to have those configurable (at least try to tweak them), so lots of filesystem calls could start timing out if latency gets high.
Now think of that and the potential pitfalls DNS brings into this mix (or even temporarily misconfigured/rogue DHCP on lease renew) - you would need to cater for all this so that your cluster does not fall apart into pieces. No one did, now it's like asking for lots of code review for zero additional benefit, i.e. no one would pay extra subscriptions for having this since they started on the rudimentary setup.
Let's extrapolate, next thing I would ask is for my nodes to run on IPv6 and have the cluster dependably self-heal on updated RA/RS, etc.
Basically no one is going to pay for that, also customers do not really raise change requests for the sake of refactoring (and all the associated testing which it would require) parts of stack that have not been touched for 10 years. Are you? With that said, I wish this was all more openly discussed on this forum, instead of the likes of pseudo-elitist snide remarks such as:
No, it is really not your fault, you asked something very logical, the answer is a bit embarrassing to admit and there's no business case because it's really not that enterprise grade. It is really good considering how small the dev team is, also consider there's no proper governance board, etc. I wish not to be mean, some of the aboveI learned from PVE staff on the forum themselves willing to openly share, but what I will never understand why there's this over-protectionism against who knows which market forces (certainly not Broadcom lately) when (not) addressing these uncomfortable FAQs.
Oh, and anyone who really knows the code well, feel free to correct me wherever I was wrong myself.
> pseudo-elitist snide remarks such as
Pseudo-elitist? getaloadofthisguy.jpg
LOL, like you know me.
BTW, nothing stops you from adding another NIC, setting it to DHCP in /etc/network/interfaces, and using that to access the GUI at :8006. The VMs won't be able to use it because it's not on a bridge, and obv it's not tested for clustering, but there's your DHCP.
Pseudo-elitist? getaloadofthisguy.jpg
LOL, like you know me.
BTW, nothing stops you from adding another NIC, setting it to DHCP in /etc/network/interfaces, and using that to access the GUI at :8006. The VMs won't be able to use it because it's not on a bridge, and obv it's not tested for clustering, but there's your DHCP.
No hard feelings, I just did not want to go around the forum and be looking for some exemplary creme de la creme ones. My issue is, we do not really know who we reply to (OP in this case). A statement like "server really needs a static IP" might be instilling the wrong kind of knowledge to the aspiring next gen network engineer. I have no issue with statements like "I always like to assign static IPs to my servers because XYZ". Maybe when I see the XYZ, I just see my use case does not fit and that's why look at it differently.
My issue is, why are we making statements here which make it sound like there's something wrong with the request. It's a legit request. Honest answer is no it's not possible for mostly keeping-it-simple for the dev team, but there are workarounds. I also do not e.g. like staff often making here comebacks like "why do you need it" - it's not how you approach these things in the world of enterprise. It smells with "we do not really support that but want to gauge how much of a persuasive argument you might bring to the table or worse, just tell you that you were using it wrong.
NB Saying something is "enterprise grade" without saying why is a bit salesperson feel to me. Imagine you are concerned about how well something is encrypted and they tell you "military grade" instead of actual standard, etc.