[SOLVED] Cannot access Proxmox GUI after VM's startup

[gothex]

I'm not sure why, but after I finish starting my VMs, I always get a "Connection Refused" error when trying to access the Proxmox GUI in my browser. The same happens when I use curl from the terminal.
Interestingly, I can still ping the Proxmox instance successfully. Also, the GUI is always accessible from my phone.

What I’ve tried so far:
1. Cleared browser cookies and cache / tried different brows
2. Checked logs using journalctl
3. Restarted the pveproxy.service
4. Monitored system resources using htop while VMs are running

 

[l.leahu-vladucu]

Hello gothex! Do you find any relevant logs in /var/log/pveproxy/? You can also enable verbose logging, as explained in our documentation.

Also, please post the output of cat /etc/network/interfaces and the VM configurations of the VMs you are trying to start.

I might be wrong, but my guess at this point is that you might have some network configuration issue, e.g. duplicated IP address.

 

[gothex]

Hello gothex! Do you find any relevant logs in /var/log/pveproxy/? You can also enable verbose logging, as explained in our documentation.

Also, please post the output of cat /etc/network/interfaces and the VM configurations of the VMs you are trying to start.

I might be wrong, but my guess at this point is that you might have some network configuration issue, e.g. duplicated IP address.

access.log seems useless, when i start getting "Connection Refused", there are no logs for that.

My /etc/network/interfaces file:

auto lo
iface lo inet loopback

iface enp4s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.7/24
        gateway 192.168.1.1
        bridge-ports enp4s0
        bridge-stp off
        bridge-fd 0

auto vmbr1
iface vmbr1 inet static
    address 10.99.99.2
    netmask 255.255.255.0
    bridge_ports wg0
    bridge_stp off
    bridge_fd 0


source /etc/network/interfaces.d/*

First VM config:

boot: order=scsi0; ide2;neta
cores: 2
cpu: x86-64-v2-AES
ide2: cdrom, media=cdrom
memory: 2048
meta: creation-qemu=9.2.0,ctime=1748617744
name: k3s-master
netO: virtio-BC:24:11:36:9B:8A, bridge=vmbr0, firewall=1
numa: 0
ostype: 126
scsil: local-1vm: vm-901-disk-0, iothread=1, size=166
scsihu: virtio-scsi-single
smbios1: uuid=d51180bd-3a33-4552-ab65-167aa4d0cBe8
sockets: 1
vmgenid: bac44a7d-07ee-4b0e-8d28-4b2964317ca0

Second VM config:

boot: order=scsi0; ide2;netO
cores: 2
cpu: x86-64-v2-AES
ide2: cdrom, media=cdrom
memory: 2048
meta: creation-qemu=9.2.0,ctime=1748618925
name: k3s-node-1
netO: virtio-BC:24:11:D2:C5:75, bridge=vmbr0, firewall=1
numa: 0
ostype: 126
scsi0: local-1vm: vm-902-disk-0, iothread=1, size=12G
scsihu: virtio-scsi-single
smbios1: uuid=8140592f-1697-403a-9faб-1679e50cb6a7
sockets: 1
vmgenid: 1c62de24-379e-4bb1-a931-e90460e017ba

Third VM config:

boot: order=scsi0; ide2;netO
cores: 2
cpu: x86-64-v2-AES
ide2: cdrom, media-cdrom
memory: 2048
meta: creation-qemu=9.2.0,ctime=1748619697
name: k3s-node-2
netO: virtio=BC:24:11:1B:28:98, bridge=vmbr0, firewall=1
numa: 0
ostype: 126
scsi0: local-1vm: vm-903-disk-0, iothread=1, size=12G
scsihu: virtio scsi-single
smbios1: uuid=ec6b2fa1-6ed3-4ede-806c-36b44e1b97d3
sockets: 1
vmgenid: cbc8be7b-5084-481d-80c5-43608046f02f

 

[Impact]

Since the VMs all use DHCP can you check which ip those have via ip a?
PVE does not use DHCP after installation and the ip is likely in DHCP range of the router. This can easily cause conflicts.
I like to pick an ip outside of range and still reserve it. This way I can also resolve my node's hostname through my router's DNS server.

 

[gothex]

Yeah, VM is overwriting main instance's ipv4.
So i managed to fix it:
1. Disabled network
2. Safely entered VM in Proxmox GUI
3. Edited /etc/netplan/50-cloud-init.yaml, where i disabled dhcp and entered static ip
4. Ran sudo netplan apply
5. Enabled network again

This is my /etc/netplan/50-cloud-init.yaml updated file:

network:
  version: 2
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - [new ip]/24
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]

The same process i did on all of VM's and now all works perfectly!

 

[Impact]

Respectfully, that's just a workaround instead of a real fix. Any other device in the same network could do the same. If not now then perhaps in the future.