- Can you only not connect to the GUI, or is the server entirely unreachable?
- Why would you obtain an IP address with DHCP, when there is a statically configured address?
- Is the statically configured address and gateway correct?
- Check before and after the DHCP request (after a reboot):
ip a and ip r
- is there a before/after difference?
- What differs?
- If the problem persists: please provide the output of
pveversion -v
1. Can you only not connect to the GUI, or is the server entirely unreachable?
The server is reachable. For a Datacenter with two nodes (e.g., node1 and node2), if I reboot node2, I
CANNOT access node2 through
node2 web interface. However, I
CAN still access to node2 through
node1 web interface.
2. Why would you obtain an IP address with DHCP, when there is a statically configured address?
I simply use the default settings during pve installation. I have not changed any configurations in my /etc/network/interfaces file.
Since I cannot access to the web interface of the rebooted node, I searched on the internet, found and followed
this solution (i.e., the two dhclient commands).
3. Is the statically configured address and gateway correct?
Yes, it is correct. I did not configure it mannuly. It is automatically accquired during installation.
4.
Check before and after the DHCP request (after a reboot): ip a and ip r
- is there a before/after difference?
- What differs?
Yes, there is a difference. I have highlighted the difference below:
- before DHCP request (i.e., after reboot and cannot access to web GUI)
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3c:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.xx.xx.xxx/17 brd 10.xx.xxx.xxx scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::3eec:efff:fe5c:f4c1/64 scope link
valid_lft forever preferred_lft forever
default via 10.xx.xxx.xxx dev vmbr0 onlink
10.xx.x.x/17 dev vmbr0 proto kernel scope link src 10.xx.xx.xxx
- after DHCP request (i.e., can access to web GUI)
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 3c:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
inet 10.xx.xx.xxx/17 brd 10.xx.xxx.xxx scope global dynamic vmbr0
valid_lft 86381sec preferred_lft 86381sec
inet6 fe80::3eec:efff:fe5c:f4c1/64 scope link
valid_lft forever preferred_lft forever
default via 10.xx.xxx.xxx dev vmbr0
10.xx.x.x/17 dev vmbr0 proto kernel scope link src 10.xx.xx.xxx
5. If the problem persists: please provide the output of pveversion -v
The output is as follows:
proxmox-ve: 6.3-1 (running kernel: 5.4.73-1-pve)
pve-manager: 6.3-2 (running version: 6.3-2/22f57405)
pve-kernel-5.4: 6.3-1
pve-kernel-helper: 6.3-1
pve-kernel-5.4.73-1-pve: 5.4.73-1
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.4-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.16-pve1
libproxmox-acme-perl: 1.0.5
libproxmox-backup-qemu0: 1.0.2-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.2-6
libpve-guest-common-perl: 3.1-3
libpve-http-server-perl: 3.0-6
libpve-storage-perl: 6.3-1
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.3-1
lxcfs: 4.0.3-pve3
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.5-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-3
pve-cluster: 6.2-1
pve-container: 3.3-1
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.1-3
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.1.0-7
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-1
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 0.8.5-pve1
