Search results

Hi, Did you see anything related to the network in `dmesg`?

Hi, I would check if the SAS disks are connected to the RAID controller.

Hi, No, Ceph will work as long as the MONs and OSDs on the 4 nodes are functional and maintain quorum. However, maybe the performance will be limited to the 4 nodes with SSDs. Additionally, I would ensure that you set noout flag during maintenance to prevent unexpected rebalancing. Only...

Please provide us more information. e.g., the network configuration `cat /etc/network/interfaces` and the output of `ip a` as well as `cat /etc/hosts`.

Hi, Could you please provide us with the output of the following commands: zpool get cachefile stat /etc/zfs/zpool.cache systemctl status zfs-import.service zfs-import-cache.service zfs-import-scan.service

Hi, know what happens exactly could you please provide us with the network configuration `cat /etc/network/interfaces` and the output of `ethtool -i <NIC>`. Additionally, i would check the syslog or `dmesg` looking for any interesting message.

you will not lose data, but you may have to install the VirtIO if not installed in your Windows VM. to do that just detach the disk and re-attach it as SCSI. I would make a backup before doing that!

We recommend to use SCSI instead of SATA since it gives more performance [0]. [0] https://pve.proxmox.com/wiki/Windows_2022_guest_best_practices

Could you please provide with more details?

Indeed, adjusting the startup delay dependency on the CephFS should help resolve this.

Yes, using `ifreload -a` is recommended in Proxmox VE over `systemctl restart networking` since it reloads interfaces in a way that aligns with Proxmox VE

Hi, May you try first `pwconv` and then issue the `passwd` again? see `man pwconv` for more information.

Hi, I would check the syslog + if possible, test the memory using `memtest86+` tool.

Hi, How about with `ifreload -a` instead of systemctl restart networking?

To investigate the issue further, could you please check the Syslog during the LXC startup? The Syslog from the PVE host should give us more information and help us understand the root cause.

Thank you for the output! Could you please try to get rid of the hook from the LXC config espeically the `modprobe tun`. You can copy the LXC config as a backup `cp /etc/pve/lxc/111.conf /root/111.conf-backup` And try to start the LXC, and run the `modprobe tun` manually? Can you also please...

Thank you for the syslog! In the syslog I see the following: Nov 12 08:02:11 pve kernel: perf: interrupt took too long (3962 > 3942), lowering kernel.perf_event_max_sample_rate to 50000 Before the reboot, this message interrupt took too long indicate CPU interrupt delays, which can imply...

Try to give `startup delay` you can do that in the Web UI -> LXC -> Options -> Start/Shutdown order.

Hi, Can you please post the container config pct config 111 and the output of pveversion -v?

Thank you for the output. The NIC names look ok not changed after the proxmox-kernel updated. Could you please post the output of `pveversion -v`? Do you have a atlantic.conf in the `/etc/modprobe.d/`?