今天在升PVE 9 版的 kernel

要移guset的時候出現訊息

conntrack state migration not supported or disabled, active connections might get dropped

guest有搬成功 而且session也沒斷

查了一下說是bug

但已經解決

使用 web ui搬是不會出現 但下指令會 真是怪

試了加上 --with-conntrack-state 1 預設是 0

qm migrate 172 pve150 --online --with-conntrack-state 1

也不會出現 

沒影響 先不改了 再觀察看看

https://forum.proxmox.com/threads/warning-cannot-migrate-conntrack-state-target-node-is-lacking-support.172068/

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1

之前提到在 lxc 跑 docker的問題

昨天出了一版更新

lxc-pve 6.0.0-2

解決docker guest 無法啟動的問題了

昨天 pbs 出了 4.1.0 版

release note 有一點 感覺有點有趣 

Allow to control parallelism of verify jobs.

Backup snapshot verification is both an IO- and CPU-heavy workload, as it needs to read chunks from disk and verify their checksums.

The number of threads used for reading from disk and for checksum verification can now be customized.

In some setups, customizing the number of threads can significantly decrease the overall runtime of the verify job.

升級後 跑了一下 竟然省了一半的時間

該期間cpu使用率如下

預設是 read 1 verify 4 

找時間再來調大看看會不會效果更好

https://pbs.proxmox.com/wiki/Roadmap#Proxmox_Backup_Server_4.1

有關 debian 13 剛發現的ipv6問題

在12版時要disable ipv6是在

/etc/sysctl.conf 加上

net.ipv6.conf.all.disable_ipv6 = 1  

net.ipv6.conf.default.disable_ipv6 = 1

但升級後檔案被改名成 /etc/sysctl.conf.dpkg-bak

重新再改回來 重開几還是沒作用

只能重新產生以下檔案 

/etc/sysctl.d/99-disable-ipv6.conf

內容相同

net.ipv6.conf.all.disable_ipv6 = 1  
net.ipv6.conf.default.disable_ipv6 = 1

debian 升到 13 版後發生很奇怪的事

同樣使用 nfdump -r $f 'flags S and not flags AFRPU'

目的是找出有syn 但沒有其他回應的ip

在12版時撈出的資料計算ip筆數的最大值大約都在100以下

因此是設100為臨界值

但升到13版後 最大值 暴升到數千

因為程式沒改

導致很多ip被block

目前改為 1000

再觀察看看

又一個升到pve 9 後的怪問題

guest的ram會持續在 100% 的狀態

但此時到 search去看 反而是 0

要解決這個問題 就要把 virtio win 的 guest tool 裝上去

以上是另一台裝好後的情況

可是在 pve 8 沒裝 guset tool 雖然ram也會高 但不會到 100%

大約會在 90多%

是不會影響操作 就觀感問題

以上是在guest os 是win才會發生

https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

升到pve9後

pvesh get /cluster/resources 的欄位有變

修正如下

pvesh get /cluster/resources|awk '{print $46" "$2" "$36" "$8}'|grep -E "lxc|qemu"|sed 's/....$//' > /tmp/all_guest_cpu

原來是

pvesh get /cluster/resources|awk '{print $41" "$2" "$33" "$8}'|grep -E "lxc|qemu"|sed 's/....$//' > /tmp/all_guest_cpu

主要是要拿 host name,guest id,guest name,guest cpu

今天把PVE升到9

guest移過去 boot 出現以下訊息

netdev net0: not adding 'host_mtu' parameter for migration compat

QEMU: kvm: warning: Machine type 'pc-i440fx-5.1' is deprecated: old machine version is subject to deletion during current major Proxmox VE release

migration listens on unix:/run/qemu-server/103.migrate

WARN: current machine version 'pc-i440fx-5.1+pve0' is deprecated - see the documentation and change to a newer one

TASK WARNINGS: 1

全部改為 q35 version 10.1

今天 pf_ring 釋出 9.2.0 版

終於解決了在新版kernel無法使用的問題 

https://github.com/ntop/PF_RING/releases/tag/9.2.0

再延續之前 docker 的問題

今天 pve 9 更新到

lxc-pve    6.0.5-3

docker 升到

docker-ce-29.0.1-1.el9.x86_64

docker 都正常了

但check了一下 pve 8

lxc-pve 停留在 

lxc-pve_6.0.0-1_amd64.deb  

pve-no-subscription

pve-test

都是相同的版本

感覺是不是8版沒什麼心力在做了 2026/8 EOL

http://download.proxmox.com/debian/pve/dists/

https://forum.proxmox.com/threads/proxmox-ve-support-lifecycle.35755/

之前反應的 docker 無法啟動的問題

到今天升到 docker ce 29.0.1 還是沒解決

看了一下systemctl status docker 發現

Nov 15 05:21:45 n8n-almalinux9 dockerd[160]: time="2025-11-15T05:21:45.778838547+08:00" level=error msg="failed to start container" container=52ba4237fbaed18fdb341674d6569b331080be432ca7bb70d5237719417d40ac error="failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied"

然後再找了一下資料 發現不是 docker的問題

原因出在 pve的lxc

https://github.com/opencontainers/runc/issues/4968

討論串上是說用 pve-test 裡的版本能解決

再等等吧 目前不打算使用 pve-test

今天把另一台graylog也轉到 7 版了

目前狀況

datanode.conf 裡

opensearch_heap = 16g

目前全部ram是給32G 文件上是說要給到一半的 ram

所以

opensearch_heap 如果不調到  16G  進web介面後會有告警

/etc/sysconfig/graylog-server

以下這行最好調到 8g 如下

 

GRAYLOG_SERVER_JAVA_OPTS="-Xms8g -Xmx8g -server -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow"

8G以下 buffers 很容易塞住

調整完剩下 8G 再觀察看看會不會有什麼問題

user 反應信件寄不到 單位的M365信箱有一段時間了

昨天連絡經銷商

問題竟然是出在 M$ 把設定改了

導致mail傳送錯誤

原來的設定是

要求改成

要改也完全沒有通知

反正M$做事就是這種鳥樣

有人反應捉不到ip

我第一反應是會不會dhcp ip 滿了

所以先查 log

grep -i free /var/log/messages

並沒有找到反應段有出現 no free leases

再來查捉不到ip 的pc mac

出現很多如下的 log

Nov  6 10:27:44 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:28:16 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:28:20 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:28:29 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:28:46 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:34:00 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:34:05 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:34:12 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:34:28 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:35:01 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:35:06 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:35:14 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

Nov  6 10:35:30 dhcp dhcpd[599]: DHCPDISCOVER from 9c:7b:ef:53:7f:e3 via 192.168.12.254

表示pc有送封包到 dhcp server 但 dhcp server 沒回應

正常的log應該是如下

Nov  6 13:27:40 dhcp dhcpd[619]: DHCPDISCOVER from 48:9e:bd:db:28:bd via 192.168.12.254

Nov  6 13:27:41 dhcp dhcpd[619]: DHCPOFFER on 192.168.12.221 to 48:9e:bd:db:28:bd (LAPTOP-RGQR6GL6) via 192.168.12.254

Nov  6 13:27:41 dhcp dhcpd[619]: DHCPREQUEST for 192.168.12.221 (10.0.0.3) from 48:9e:bd:db:28:bd (LAPTOP-RGQR6GL6) via 192.168.12.254

Nov  6 13:27:41 dhcp dhcpd[619]: DHCPACK on 192.168.12.221 to 48:9e:bd:db:28:bd (LAPTOP-RGQR6GL6) via 192.168.12.254

於是我把dhcp再加大範圍 加了五個ip

就正常了

所以為什麼沒出現 no free leases 的訊息

這個再查看看

早上把 almalinux 9上的docker 版本更新後

n8n就起不來了

不知道是不是有bug

只好先還原備分

過几天再看看

試了別台 也一樣

果然是這個版本的docker有問題

docker-ce-cli-1:28.5.2-1.el9.x86_64

docker-compose-plugin-2.40.3-1.el9.x86_64

docker-ce-3:28.5.2-1.el9.x86_64

docker-ce-rootless-extras-28.5.2-1.el9.x86_64

早上死掉一台synology的nas

因為是mount nfs 給pbs 備分用

所以要先把備分移到別台nas

然後在pbs上disable datastore

指令如下

Set to Offline (Disables all access)

proxmox-backup-manager datastore update <datastore-name> --maintenance-mode offline

Set to Read-Only (Allows restores, no new backups)

proxmox-backup-manager datastore update <datastore-name> --maintenance-mode read-only

Re-enable (Go Online)

proxmox-backup-manager datastore update <datastore-name> --delete maintenance-mode

再來修改 /etc/fstab 先把該nfs mount point 註解

重開几

讓pbs繼續運作

PVE上的storage也要先disable 然後把備分改到其他storage

等修好後再 enable

graylog 7 昨天發布

比較大的改變是不再使用 opensearch 而改用 graylog-datanode

照著官方文件安裝沒什麼問題

如果是在PVE上安裝

因為 mongodb 必須使用到cpu的 avx 功能

所以cpu type 至少要選 x86-64-v3 以上

這個在graylog 5 安裝時就有這個要求了

特別要注意的是以下流程跟之前不同

安裝完後必須 cat /var/log/graylog-server/server.log

找到首次進入系統的帳號密碼及連結

如下範例

http://admin:ghWgeIAkKl@10.0.0.1:9000

按照畫面上的流程步驟 使用預設值一直下一步即可

目前先把netflow轉到新版了 觀察一陣子看看

https://go2docs.graylog.org/current/setting_up_graylog/web_interface.htm#Prefligh

https://graylog.org/

https://go2docs.graylog.org/current/downloading_and_installing_graylog/red_hat_installation.htm

ruckus AP 訊號調整

最近因為常有user捉到別間房間的AP訊號

因此需要把AP可連線範圍調小

就是調整最差連線的db值

把db值調大

只要小於這個db值

AP就不給連線

如何調整

登入vsz後

拉到最下方

目前先調到 -65db 再觀察看看