Proxmox 5 won't quit pulling a dhcp lease?

[Kevo]

I setup a new Proxmox 5 install on my home network with DHCP. After verifying I could log in to the web interface and ran updates I set the IP to static shutdown the server and took it to work.

At work I logged into the ip that was on the home network updated it to match the work network and saved the changes. I then rebooted. After reboot I could not log in. Checking our router I find the server MAC has an IP lease on it. I try logging in to that IP and can't either. Nor can I ping either IP. No monitor with the right interface at the office to log in locally so I take the server back home.

At home, the server pulls it's old original IP as a lease, and I still can't ping or log into that IP. So I log in physically and change the interfaces file from the work IP to the current dhcp IP and now I can log in.

The interfaces file looks like all the examples I see online on how to do a static IP, so I don't get what's going on. Anyone have any ideas? TIA

 

[Kevo]

So after a little more playing around, it seems that the server is pulling it's IP at the grub boot screen. I looked through the grub config file but there's not much there. At this point I think I may just reinstall from scratch to see what happens if I set up a static during the initial install.

 

[Kevo]

So I reloaded and setup the work IP during the install. I added that subnet to my home router and it does work on that IP now.

The weird thing is I still see the lease created in the router at the grub screen even though I did not setup dhcp anywhere. Once the server is up I cannot ping the leased IP, nor can I ssh to it, or log into the proxmox web interface on it. I have one other server running proxmox 4 on the same hardware and it does not pull a lease. Weird.

 

[fabian]

PVE does not setup DHCP in any way (it only uses DHCP to try to get an initial IP in the installer, to pre-fill the network config screen with default values). network setup also happens long after Grub or the initramfs..

 

[Kevo]

Interesting. This server had ESXi on it previously. Maybe it tweaked something in the EFI that is pulling an IP. I'll have to play around with it some more and see what happens. For now I have it set to static and also have a static lease for the same IP setup for it in the router. Seems to boot up and communicate on the network fine now.

 

[Kevo]

So it turns out that this server supports net booting with no os installed and the EFI is by default pulling an IP. I loaded the latest EFI update and it still does that so I think it's normal. Now why the IP set for Proxmox/Debian would not work after the machine booted I don't know. I think that must have been a separate issue. In any case, after reloading everything it's working on the proper IP now so I guess I'm going to call it a glitch in the original installation. Sorry for the wasted bandwidth.

 

[dfenwick]

It's not a glitch. If your NIC has a PXE interface on it, it's just going through the standard PXE boot process. During hardware startup, if your network interface has a higher priority for boot than your hard disk, the PXE interface will attempt to boot, which requires it to do a DHCP request and get a DHCP response. If a boot image is offered in the DHCP lease, it will configure the NIC with the lease IP and download its boot image.

If there is no PXE boot option available from the DHCP server, the server will drop through the rest of the boot process, eventually finding your bootable hard drive. The OS will load. All of the DHCP lease information is completely unknown to the OS.

Some admins rely on the remote boot capability because they can reimage a machine remotely. They want the PXE boot option before the other options so they can remotely boot into a network OS. If the hard disk is in the boot sequence before the PXE nic, this wouldn't be possible without having some kind of lights out interface on the machine.

 

[Kevo]

I'm not sure why you think I'm calling the netboot functionality and the pulling of the IP on boot the glitch. I think what I wrote is pretty clear that I now think that part is normal.

The glitch was after the first install I could not get an IP change to work. I tried changing the interfaces file manually, I tried changing the IP in the Proxmox web interface, and anytime I changed the IP I would lose connection on the next boot. I could go back to the install IP using a physical keyboard and monitor, but any change away from that IP didn't work. So at the office I put my home network IP in the router and was able to get in that way. Change the IP and I can't get in any more.

So I think there was some sort of glitch in the install or maybe the way stretch is working on this particular machine.

On the second install I made sure to change the IP from the DHCP supplied IP during the installation wizard to the IP I was planning on using at my office. Now it seems to communicate on that IP fine. So I'm saying it was an install glitch, but I don't understand why it didn't work before. There's nothing different in the interfaces file now than what was there before. So I don't really know what the problem was or if it would still happen since I put in the IP I wanted during install this time instead of accepting the default.

 

[dfenwick]

I'm not sure why you think I'm calling the netboot functionality and the pulling of the IP on boot the glitch. I think what I wrote is pretty clear that I now think that part is normal.

The glitch was after the first install I could not get an IP change to work. I tried changing the interfaces file manually, I tried changing the IP in the Proxmox web interface, and anytime I changed the IP I would lose connection on the next boot. I could go back to the install IP using a physical keyboard and monitor, but any change away from that IP didn't work. So at the office I put my home network IP in the router and was able to get in that way. Change the IP and I can't get in any more.

So I think there was some sort of glitch in the install or maybe the way stretch is working on this particular machine.

On the second install I made sure to change the IP from the DHCP supplied IP during the installation wizard to the IP I was planning on using at my office. Now it seems to communicate on that IP fine. So I'm saying it was an install glitch, but I don't understand why it didn't work before. There's nothing different in the interfaces file now than what was there before. So I don't really know what the problem was or if it would still happen since I put in the IP I wanted during install this time instead of accepting the default.

I get what you're saying now. You didn't happen to change the interface information in the UI then change it manually in the OS before rebooting did you? The UI lays down a temporary file in the /etc/network directory (interfaces.new I think?) and if that file exists, on next boot it will copy what's in that file over the top of the /etc/network/interfaces file and then remove the .new file. I tend to do a bit of manual meddling with my interfaces file because I'd rather not wait for the 8 - 15 minute boot cycle to complete on my physical servers.

I've never seen the behavior you're talking about with 5.0. I have some boxes I installed with DHCP just for testing, and changing the interfaces through the GUI seemed to work just fine as long as I rebooted right after I did the changes, obviously due to the interfaces.new thing. I have, however, seen some interesting state behavior with regard to the timing of bringing the bridges up versus the time it takes to initialize interfaces, particularly 10Gbps interfaces, that causes the bridge MTU to clamp at a particularly low MTU. I pulled some of my hair out over that because it ends up giving me 25MB/s on my SAN rather than the 400MB/s - 500MB/s I would normally expect.