Search results

So ping 192.168.50.1 fails? Just to be sure, your router is 192.168.50.1, right? Can you ping any other devices on 192.168.50.0/24?

after ip addr flush dev enp2s0 ifreload -av enp2s0 still has two IPs assigned to it? If that's the case, I don't see how that is possible since PVE does not do any DHCP, so it does not matter what is set on the router. Could you also remove the entry for the PVE on your router.

Is the NUC where PVE runs on? PVE does not get its IP from DHCP, it is specified statically in /etc/network/interfaces. Did you do any network configuration aside from /etc/network/interfaces?

The picture does not match the text, which is the state right after the two commands? enp2s0 should not have an IP assigned to it, only vmbr0 should have one.

Hey, what is the output of ip a after ip addr flush dev enp2s0 ifreload -av ?

Hey, any idea how enp2s0 ended up with two IPs? It should have none, since vmbr0 has an IP. Could you run ip addr flush dev enp2s0 to remove the IP addresses assigned to the interface directly, and ifreload -av to reload everything. Does ifreload complain about anything?

Did you modify the code? You can reinstall the UI packages with apt install --reinstall pve-manager proxmox-widget-toolkit libjs-extjs that should fix the problem.

Hey, does the browser console show any errors/warnings? Do you have the same problem with different browsers?

Hey, have you tried using OVMF (UEFI) as BIOS with TPM and pre-enrolled keys?

Hey, leave it, it is self signed and will only be used if no other certificate is available. IIRC you can't even remove it through the UI.

Hey, nicht direkt im Task selbst, aber mit systemd kann man das so machen, dass nach dem Start/Restart vom pmgproxy.service auch nginx neu gestartet wird, heißt aber, dass nginx hin und wieder unnötig neugestartet wird, da ja nicht jeder pmgproxy Start mit einem neuen Zertifikat zusammenhängt...

Hey, bridge-vids should be space separated[1], the rest looks fine, if I didn't miss anything. IIRC ifreload -a -vv should yell at you for that, may be helpful to spot things like this. edit: actually doesn't [1] https://manpages.ubuntu.com/manpages/jammy/en/man5/interfaces-bridge.5.html

That is only the case if you login as the root user. But no, something like that is not on our roadmap, if you think you have a use-case for it, feel free to open feature request at [1], since that's where we track those things. [1] https://bugzilla.proxmox.com/

Hey, no, kickstart is not possible. But you can take a look at [1], should be what you are looking for. [1] https://pve.proxmox.com/wiki/Automated_Installation

Hey, no. Non-root users will have to login in the shell though.

Hey, die IP/hostname des ESXi, oder VCenter servers.

Hey, your data is fine, migration doesn't move the data, it stays in the same place(s), after the migration it is just used from somewhere else. If ceph has its own network you shouldn't really notice anything more than what you currently see performance wise.

Do you have physical access to the server? If yes, could you login on the console and post the output of cat /etc/network/interfaces and ip a? Can you ping your router and other devices on the network from there? And what is the output of systemctl status pveproxy?

Inside .chunks/? The <DATASTORE>/.chunks/ directory is part of a datastore. And if the creation task finished successfully it was created. Could you post the logs of the task when you created the datastore?

Hey, why, and how did you create .chunks manually? It is created and setup correctly on datastore creation. Is .chunks filled with directories? If yes make sure everything is owned by the backup user. You can check that with ls -la .chunks.