Search results

I've found what was eating the RAM, had nothing to do with the upgrade... maybe the behavior is different or available RAM lower which is causing the reboot. Sorry for this false alarm

I've upgraded my Proxmox server from v8 to v9 a few days ago. It rebooted several times since the upgrade and it looks like it is caused by some RAM exhaust problem. Total RAM is 256GB. All my CT+VM are using roughly 64GB of RAM and their proxmox graphs do not show any increase use by them...

Got the same error on my Proxmox v8 host, without VM running on it.

I'm using ZFS for my storage, and found that "pct delsnapshot" does not delete snapshots on replicated storages in my cluster. Is this a know bug ?

I'm using ZFS encryption on some LXC subvol storage, but found that proxmox replication does not natively support them. A single option needs to be added here ...

It looks like zfs 2.0.3 in now in the stable proxmox repo :) Is there anything published about this upgrade ?

The network interface file does not seem to have any link with this issue. This part of ifupdown2 scans the available devices, without using the interfaces file. More details with a new node impacted... I just got the same problem on a second server, also using a melanox adapter (same as the...

Was 2.0.1-1+pve2, now 2.0.1-1+pve3 Same error message: "error: main exception: Length of MACAddress attribute not supported: 24" It comes from https://github.com/CumulusNetworks/python-nlmanager/blob/master/nlmanager/nlpacket.py#L591 I've replaced the raise.exception with a simple...

Same problem for me since a hard reboot of one of my servers which completely lost network :( I used ifupdown2 previously on this server and had no trouble, so it must be linked with some update. On another node, infiniband does not causes trouble with ifupdown2. The IB adapters are different...

Non corosync problem in my syslog... the fix seems good so far :)

Meanwhile... why not ask systemd to restart corosync when it crashed ? Restart=on-failure To my knowledge, link0 was not down Here is a full syslog during the same period: Aug 22 12:29:00 proxmox72 systemd[1]: Starting Proxmox VE replication runner... Aug 22 12:29:00 proxmox72 systemd[1]...

One more corosync crash (with 1.10_pve2)... I hope the upcoming bug fixes will help ! ● corosync.service - Corosync Cluster Engine Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor preset: enabled) Active: failed (Result: signal) since Thu 2019-08-22 12:29:22 UTC; 2h...

corosync got killed (again) on one of my 3 nodes cluster root@r510a:~# systemctl status corosync ● corosync.service - Corosync Cluster Engine Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor preset: enabled) Active: failed (Result: signal) since Sun 2019-08-11...

I also have instability in my 3 nodes cluster recently upgrade from 5.4 to 6.0. corosync got killed on two nodes during the past days. This morning, one of the node got out of the cluster. The log showed a "TOTEM FAILED RECEIVED". It got back it in by adding a second ring (on my infiniband...

I'm currently migrating an old server (debian 6 + openvz) to proxmox 5. The old vzdump script generates .tgz files that are not recognized by proxmox 5 pct restore command. Simply rename them to .tar.gz !

After some more investigation, it looks like my old vzdump (1.2.x) does not create a dump file compatible with today's pct restore... How can I do some conversion ?

I have an old openvz based setup which I want to migrate to proxmox 4 (and LXC). I've backuped a test VM using vzdump, but when I restore on my proxmox 4 node, I get the following: root# pct restore 101 vzdump-openvz-101-2016_02_21-15_40_41.tar unable to create image: qemu-img: Image size must...