Search results

not directly, what you can do is to change the original MAC address: ip link set <tap-tinterface-name> address <new-mac-address> When performing the above by a script you have the effect you request.

ad 1.) Only vg "pve" and lv "data" in it is configured implicitly as Storage. Other LVM Storages have to configured by GUI with "Datacenter" -> "Storage" -> "Add" -> "LVM" ad 2.) No, since sda and sbd have quite different physical attribues ad 3.) No problem: first delete the Storage by...

What exactly did you do what is called in your first post "File Restore"? I assumed restoring a VM at a PVE host but maybe I am wrong.

Looks fine and there is nothing which indicates that Proxmox should not work. Just a remark regarding disks: since you use a RAID controller do not use ZFS!

Try to boot via an external live media and investigate the file from previous Proxmox installation then. NAS is used as data storage only (or?), therefore it cannot cause the problem of Proxmox crash you reported. In order to exclude any inflince from NAS I suggest to run Proxmox for the moment...

Works in principle with flash/USB drives too, the question is reliability (for productive use not recommended, however, everybody has to decide what his needs are). Sometimes for boot the option "rootdelay=5" is required.

You did not mention CPU, amount of RAM and which kind of storage you have. 16GB RAM is sufficient in most cases. In principle Proxmox VE works with almost any amd64 environment (i.e. also with the mentioned one I assume), if resources are sufficient depends on the needs of the VMs.

Ja Im Prinzip ist ohne SWAP besser, bei 8GB RAM muss man aber aufpassen, dass es nicht zu oom kommt (hängt vom Bedarf der VMs ab), nochmal 8GB RAM wäre gut, ansonsten halt beobachten, man kann swap ja auch später ergänzen. Ob zram als Alternative tauglich ist, kann man nicht vorhersagen, siehe...

Most probable a hardware error (disk? controller?). AFAIU lvm pve is corrupt after a while. It may help to have a look into lvm's history, shown by archive and backup file: cat /etc/lvm/archive/* cat /etc/lvm/backup/*

Timeout does not happen because of a "too large" disk, something else happened. What exactly can be figured out by studying the respective tasklog. You can find the tasklog file (for e.g. VM 199) by: ls /var/log/pve/tasks/*/*qmrestore:199*

Select "Edit Thread" and then in "Title:" "[SOLVED]"

Mal ohne QEMU Guest Agent versuchen (in "Options" disablen, dnach die VM aus und wieder eingeschalten).

Settings as described should work, for details post current settings seen by iptables-save

renew the certificates and restart pveproxa service by rm /etc/pve/priv/pve-root* pvecm updatecerts --force systemctl restart pveproxy.service

The above setup in particular I never tried, but more than once I experienced problem with nested virtualization when having an AMD Ryzen CPU in host. Try using different kernels in host and/or specify a specific CPU as well as SVM flag, in one case the following (adding in .conf file) helped...

Upgrade to octopus is not a mystery - see https://pve.proxmox.com/wiki/Ceph_Nautilus_to_Octopus . Has to be done before upgrade to PVE7. Of course, also possible; finally it depends on your current situation what is more convenient for you.

Da ist kein Problem erkennbar. Home-NAT router listen nicht unbedingt alles auf, was am LAN hängt, vor allem, wenn die nicht mit DHCP arbeiten.

Da sollte man sich das mal im LANtrace (tcpdump) ansehen (d.h. welche Pakete kommen von extern an, wo werden sie weitergeleitet, selbiges dann für die Antworten aus dem Container). Mögliche Fehlerquelle ist ein Firewall irgendwo auf dem Weg. Ist auf Basis der obigen Anweisungen keiner erkennbar.

Was genau wurde gelöscht (Eine Datei mit dem Namen /etc/pve-cluster gibt es normalerweise nicht)? Wenn es das gesamte /etc/pve Verzeichnis war würde ich vorschlagen: - auf einem anderen Rechner (oder VM) Proxmox installieren - die bekannten CTs und VMs dort erstellen (mit leeren Disks - die...

Nochmal genau ins syslog des host schauen, vor allen darauf was unmitztelbar vor den boot passiert ist. Würde auch mal probieren, die Uhr auf 3 Uhr zu stellen (den ntp server abkopplen, damit das nicht gleich wieder zurückgestellt wir) und dann direkt beobachten was passiert. Auch interessant...