Proxmox VE 8.3 released!

[Remis]

You mean with the kernel module? FWIW, we got X540-AT2 in some of our test hardware, and it works fine there. E.g., I got a long-term three node test cluster that each has such a NIC, and it's configured as ceph cluster full-mesh network. Two nodes use the 6.8 kernel and one node uses the 6.11 kernel; the NIC work fine both kernels.

Maybe open a new thread and describe the rest of the hardware and the problems you're seeing.

Honestly, I have no idea how you managed to get that card working with Proxmox, because I've been at it for a week without any success. I was hoping the new version of Proxmox would finally fix the issue, but still no luck. I already opened a thread about this not long ago (https://forum.proxmox.com/threads/u...rk-card-on-proxmox-ve-8-2.157176/#post-720139), and the only suggestion I received was to run the version 7 kernel on Proxmox 8. It works, sure, but... it's far from ideal.

If needed, I can provide a dedicated server ready to go with IPMI/KVM access, to mount the latest Proxmox ISO for debugging purposes, so the issue can be seen firsthand.

 

[t.lamprecht]

Honestly, I have no idea how you managed to get that card working with Proxmox, because I've been at it for a week without any success.

Intel, like other vendors, sells many hardware revisions under the same model name; so this might be a revision specific issue, or related to the rest of the hardware. I'll answer in your thread.

 

[crandler]

This sounds like it could be an unintended effect of [1], which adjusts node.session.initial_login_retry_max to decrease an overly high default login timeout. Can you please open a new thread and provide:

• The content of /etc/pve/storage.cfg
• The output of the following commands:
  

  iscsiadm -m node
  iscsiadm -m session
  ls -al /dev/disk/by-path/*iscsi*

• The output of:
  

  journalctl -b -u open-iscsi -u iscsid -u pvestatd

• How do you adjust the node.session.initial_login_retry_max? Changing /etc/iscsi/iscsi.conf with new discovery, re-logins, rescans, reboots
• Before upgrading to PVE 8.3, did you have any custom config set in /etc/iscsi/iscid.conf? NOPE
• Can you clarify what you mean by "automatic login"? Do you mean the login to iSCSI storages performed by PVE on boot? EXACTLY
  Similarly, what do you mean by "manual login"? Do you mean manually running iscsiadm -m node --login? EXACTLY

Please mention me (@fweber) in the new thread.

[1] https://git.proxmox.com/?p=pve-storage.git;a=commit;h=e16c816f97a865a709bbd2d8c01e7b1551b0cc97

Hi @fweber,

You are likely correct in your assumption. When pvestatd activates the storage, it gets blocked during that time, which is indeed undesirable. In our case, the issue was caused by an active portal that didn’t have any allowed targets for the clients.

We have now removed that portal on all hosts, reset the node.session.initial_login_retry_max value in /etc/iscsi/iscsi.conf back to 8, and rebooted the system.

On our test system, all targets were automatically connected during boot, and everything seems to be working as expected now.

Thanks for pointing us in the right direction!

 

[Kevin Labécot]

https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_ct_change_detection_mode

In our tests it was a fraction of the old option. E.g. ~10min -> ~3min on one of my personal hosts. In other situations, the gain might be even more.

Thanks. Thats looks like a Major improvement! Does this work only with storage backend with snapshot support ?

 

[t.lamprecht]

Thanks. Thats looks like a Major improvement! Does this work only with storage backend with snapshot support ?

No, this is independent of the underlying storage.