Hi,
The DHCP for servers is not recommended. However, below you will see the example
enp5s0 to your interface name. After all, you have to issue the `
Another note: when the IP of the Proxmox VE got changed, you have to edit it in the `/etc/hosts` file as well.
The DHCP for servers is not recommended. However, below you will see the example
Code:
iface enp5s0 inet manual
auto vmbr0
iface vmbr0 inet dhcp
bridge-ports enp5s0
bridge-stp off
bridge-fd 0In order to set the DHCP on your Proxmox VE, you have to edit the `/etc/network/interfaces` file in the above example, you have also to change the interface name
ifreload -a` command in order to take the effect.Another note: when the IP of the Proxmox VE got changed, you have to edit it in the `/etc/hosts` file as well.
If it is "permanent" in the sense of it being reserved in the DHCP server, just follow the standards and the official recomendation of having the IP statically configured in the Proxmox host. If you ever change your DHCP server or change the nic or mac of your Proxmox host, there's a high chance to forget that the IP is configured via DHCP, your host will get a different IP and Proxmox services will stop working properly.
just to close the topic (though I am not the OP), the approach suggested by @Moayad does work, and I am able to get the static lease offered by DHCP server instead of hardcoded IP in proxmox interfaces. I also edited the `/etc/hosts` and commented out the hardcoded ip (`#<ip> proxmox.local proxmox`) since the nslookup automatically adds the `.local` by default which is my local domain too.
Not sure if things have changed since the above post, but if I comment out the hardcoded ip in `/etc/hosts` then Proxmox services will not start after a reboot. However, this post has a script to change the hardcoding dynamically whenever the IP address changes, and that worked for me.
I like the auto script of updating /etc/hosts. Usually I will do it via the rc.local, but his mechanism is even better (using the dhcp hook)
Linking related TUTORIAL FOR DHCP deployment: https://forum.proxmox.com/threads/dhcp-cluster-deployment-no-static-ips.154780/
Obviously, for single node, it is a trivial case.
NB The hostnames do NOT need to be managed by the DNS, but it makes perfect sense. Then you are all good without scripts and can even shut down whole cluster and have it restarted in different network environment.
Obviously, for single node, it is a trivial case.
NB The hostnames do NOT need to be managed by the DNS, but it makes perfect sense. Then you are all good without scripts and can even shut down whole cluster and have it restarted in different network environment.
Last edited:
I always thought the whole point of DHCP was that there was a high chance a forgotten machine somewhere (or a fat typo finger) that one day causes an IP conflict which is hard to trace. Something a DHCP server caters for - there's a reason we kept them with IPv6 besides SLAAC still. For servers.
I would really love to see the proxmox team adopt these small quality-of-life changes that they may believe are unnecessary, but every other hypervisor in existence supports out of the box. We (the proxmox community) can either think we are right and all other hypervisors are wrong, or we can try to understand that there is probably a very good reason why users should be able to manage the hypervisor's IP address through the hypervisor's config page and why we should be able to set things to DHCP should we want them to be that way.
I suspect the major issue PVE has with this is the philosophy of all nodes being equal and no control panel "node". But it only works in theory. At the end of the day, when your cluster falls apart, you need some tooling (and Proxmox appear to actively avoid to provide anything like that) that puts it back together. You cannot distribute changes properly if the distributed state machine fell apart till you get it working, for that you need to update the corosync configuration uniformly and kickstart it, but you cannot do it over the corosync messages, obviously.
When you apply this logic to other centrally managed concept like DHCP + DNS, you get the idea. The last option is that Proxmox calculated how likely users are to come with e.g. misconfigured DHCP and put it on their shoulders to troubleshoot, so they rather actively discourage it out of convenience of their own support load.
NB When you look at the tutorial linked, there really isn't much that one has to do to have it working well, it's just putting back dhcp and hostnames where PVE scripting would get you populated resolved IP addresses.
I think the logic should change to clustering, make static IPs required for clusters to avoid issues - but for standalone hosts, might be an easy thing to do. The issue really goes beyond dhcp, just changing the IP address alone is something we can't currently do through GUI.
ps: maybe I'm just done, but i couldn't get a standalone node to work on dhcp using the tutorial above, I can ssh fine into the machine, but the pve web ui never loads
One thing I noticed for sure, everything (on a single node) is run as-if it was in a cluster already, to keep the codebase constant. It literally even runs everything as-if at any point in needed to become part of a cluster. It's easier testing for them.
Maybe I forgot (to emphasize) something important that I took for granted, feel free to reply there (or create a new thread, your choice) to troubleshoot, it might help someone else after all.
EDIT: I did test the config, I run it myself, it runs even when entire cluster is taken off and put into completely different environment, i.e. nodes start all with new IPs. Single one can't be more complex.
Sounds something minor forgotten, I would start with hostname --ip-address to check.
Last edited:
I followed this and ended up locking myself out, luckily it was in a virtual proxmox test lab.
i reverted everything to as it was before and still couldnt get back in
Did you follow this as it is?
the hostname did not change in the /etc/hosts config and i had to manually update it.
would be great if I could get DHCP working for this portable lab
Thanks.
I followed this and ended up locking myself out, luckily it was in a virtual proxmox test lab.
i reverted everything to as it was before and still couldnt get back in
When you boot and you see complaints (check
journalctl -u pve-cluster) about hostname not resolving, it is because, well, it is not resolving. You can have it resolve it multiple ways, but the standard install PVE relies on putting a static entry into /etc/hosts (which is not how name resolution should happen though). It never changes, unless you change it or do something extra (e.g. DNS and proper resolving configuration, e.g. nsswitch.conf) to make it resolve. And do note that corosync.conf needs to amended as well if you have a cluster.A quick check can be done with:
hostname --ip-addressThis needs to show some other than loopback address.
I don't want to be pushing my tutorial (why not search before asking), but you can get exactly that:
https://forum.proxmox.com/threads/dhcp-cluster-no-static-configuration-auto-install.154780/
Last edited:
Hi thanks for the above
I did check out your link before posing my message and as it stated cluster I wasn't sure if it was aimed at a solo node (more so if I can achieve what I need without setting PVE on top of Debian that would also be preferred)
Alright, my bad, I should emphasize that somewhere at the top it also applies to a single node, you simply do not need to worry about the clustering part. Also, there's a section on ISO install. The most important, however, are the prerequisites.
Alright, here is something for SINGLE node ONLY: https://forum.proxmox.com/threads/dhcp-single-node-install-only.155125/
Thank you for this
will have a pop at it now (I did try doing it from the original link but must have done something wrong lol)
this new link does look slightly different though so fingers crossed I can make it work
ok do going for round three... i had cluster services turned offThank you for this
will have a pop at it now (I did try doing it from the original link but must have done something wrong lol)
this new link does look slightly different though so fingers crossed I can make it work
one more try and then bed time for me