Mmm, I tried that. It only allows you to select from existing events which probably fuels the rants of the other user ;-)

Totally agree. Its a bit counterintuitive. I suspect its because people share events and locations

ran the above and the following pops up. the MAC ending is c3 is the new one I assigned to the 20.91 address on DHCP pfsense server about an hr ago.

EDIT: wondering whether this may be a network manager problem on the VM client? See here

EDIT2: Even tried running ip addr flush dev <your_adapter_id> as suggested here but no effect at all

EDIT3: This is now solved. It was a client problem. Somewhere buried in the system, a static IP had been set up on this machine in the past I image.

When running ntmui, the 106 address was configured as static address. Deleted it and now only sees the 91 address. Didn’t realise you coudl set two IPs against same interface. This is the page that helped following advice from @nibbler@discuss.tchncs.de of runnign dhclient -v ens18; for i in $(seq 60); do ip a s dev ens18; sleep 1; done

deleted by creator

a) turned off VM b) deleted the static mapping and recreated c) change the MAC on the VM and then the same MAC on pfSense d) checked /var/dhcpd/var/db/dhcpd.leases and there is no sign of any 192.168.20.XX lower than 20.110 (from 110 I leave the space availble for occasional wifi access of devices not in my home) e) Rebooted pfSense

absolutely the same problem again :-(

don’t I have not configure proxy arp on PVE. the only arp is what I see cached by pfSense. tried flushing the table in pfSense with not luck … the VM is still hooking up to 106 and this is confirmed in the pfSense ARP table even after flushing, despite the DHCP lease table saying that the VM is hooked to 91.

Can I just check with @tiptoes@sh.itjust.works and @Eggymatrix@sh.itjust.works that what I’m doing is what you are saying.

I’m not setting static IPs at client level. Would be a nightmare. What I do is assign IPs on the DHCP server i.e MAC address on VM1 is XX:XX:XX:XX so I set this MAC address in DHCP to correspond to IP 192.168.20:XX so that the machine gets a unique IP all the time. Is this what you meant? I thought everyone would be doing this nowadays as it so easy to manage, except when something goes wrong like in this case.

Maybe I’m misunderstanding but what I mean is that I assign static IP via DHCP based on the MAC. I’m not setting static IPs at client level. i.e MAC address on VM1 is XX:XX:XX:XX so I set this MAC address in DHCP to correspond to IP 192.168.20:XX so that the machine gets a unique IP all the time. Is this what you meant?

No netplan folder under either /etc/ or /var/run/

See message above. I doubt it. I would have had this problem a lot earlier with other machines.

What a surprise … if I were to believe this I would file for madness state support. Look like the VM is having a nice chat with the DHCP sever and both agree that the IP should be 192.168.2’.91. Then one of the two cheat, and actually work on 106. Logs in DHCP server a showing nothing. I even told pfSense to ignore the machine ID and it had no effect whatsoever. If there was another DHCP server hiding somewhere, dhclient would have picked that up presumably.

Just to be clear, this is what is in the ARP table on pfSense: and this is what is in the DHCP lease table in pfSense. What I’ve concluded is that the DHCP sees the VM is online, it probably offered the 91 IP, and just shows it online. The ARP table is showing what the actual assigned IP is (106) and SSH login attempts confirm this. There is no 106 entry in the DHCP table. I would ignore the VM2 element of the equation i described above for now. I added just to describe the conflict that arose when I switched it on. I woudl also say that VM1 was backed up on another Proxmox server I had runnina and then restore it on this new Proxmox server I have with a bigger NVMe.

But if there was another DHCP server hiding somewhere, i would have had this problem years ago with all the other machines that are using the same router/DHCP server?

Well, because its all managed in one place rather than having to go and configure loads of machines

I hadn’t realised that matter was making such progress. I was about to start installing KNEX stuff at my home, which I would later integrate with Zigbee or the other stuff.

You need to share your setup then … :-) I wanted to set this up next.

So I created an ext4 256GB partition at install time hoping when logged in the GUI, I would get the option to create a ZFS partition on the free space of the NVMe. However. the free space is not showing up under disk and I don’t get the option to add another partition, whether ZFS or other. Any clues why this would be?

Ok, but I assume this means that I have to configure the new node from scratch, adding the storage, etc. Correct? So the steps would be:

a) build new node with spare Optiplex + 1 new NVMe and install Proxmox from scratch b) configure the new node and add to the cluster c) migrate the VM from old now to new node d) decomission old node but installing the 2nd NVMe and Proxmox from scratch e) add the second rebuilt node to the cluster again.

Did I get this right?