pve新建guest時

如果TPM State的disk 是開在local

是不能移到別的storage上的

要移動只能備份

還原時再選目的storage

昨天 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

早上死掉一台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

promox mail gateway 9 這次的進展真的快

Beta出來沒几天 正式版就出來了

而且之前都要等好久 才會有 LXC 的template

今天早上就已經看到了

既然看到 就升吧

一直以來都是直安裝新版再重設config

官方雖然有升版的文件

但以往的經驗是直接原几升都會有問題

https://forum.proxmox.com/threads/proxmox-mail-gateway-9-0-released.173158/

前不久提到可以使用 zap docker 相當方便

但今天使用時有一些狀況

首先是如果不限制 docker 的 cpu ram 會把宿主几的資源全部吃完導致當几

必須使用 --cpu --memory 來設定

範例如下

--cpus="18" --memory 20000MB

接續以上的問題

在LXC就算增加2個以上的core 依然無法設定 --cpus 大於一

所以要使用vm才能設定多個cpu

另外硬碟使用率會隨著被scan的網站規模變大而變大

所以要有足夠的硬碟空間 否則也會有掃到一半當几的問題

要特別注意

今天要把vsz轉到pve

不管是直接import或先tar 解開 使用 vmdk 都出現以下二個問題

首先是沒有 serial port

要加上去

再來是無法正常開几

試了很多方法

最後是把vmdk轉成 qcow2才成功開機

qemu-img convert -f vmdk -O qcow2 vscg-5.2.2.0.1161-disk1.vmdk abc.qcow2

almalinux 10 几天前release

今天在proxmox (PVE) 上安裝時 用iso開几就出現 kernel panic

 

解決的方法就是cpu不要使用預設的 x86-64-v2-AES

也不要用  x86-64-v2

使用  x86-64-v3  或 x86-64-v4 就沒問題了

不過要注意的是 比較舊的host 可能無法支援這二個type 而無法 migrate

官方網站有提到

With RHEL 10, Red Hat will only support x86-64-v3 and higher

不過也有提到

AlmaLinux OS 10 has followed Red Hat’s decision to ship x86-64-v3 optimized binaries by default, but we will also provide an additional x86-64-v2 architecture, allowing users on that older hardware to continue to receive security updates for another 10 years.

所以如果一定要使用 x86-64-v2

就要下載另一個iso

https://mirrors.almalinux.org/isos/x86_64_v2/10.0.html

https://almalinux.org/blog/2025-05-27-welcoming-almalinux-10/

今天再度測試了一下PVE的firewall功能

發現只要打開cluster的firewall

預設就會載入很多firewall的rule 而且無法刪除

但在測試過程中發現竟然有 guest 原本提供服務的https 打不開了

而且原本使用 nmap做的一些測試也被擋了

最後決定在每台host直接下iptables 指令

#!/bin/bash

######## 以下是防護 host ##############

/usr/sbin/iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT

/usr/sbin/iptables -A INPUT -p tcp -s 0/0 --dport 22 -j DROP

/usr/sbin/iptables -A INPUT -p tcp -s 0/0 --dport 8006 -j DROP

######## 以下是防護 guest  視需求新增  port #############

/usr/sbin/iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT

/usr/sbin/iptables -A FORWARD -p tcp -s 0/0 --dport 22 -j DROP

/usr/sbin/iptables -A FORWARD -p tcp -s 0/0 --dport 8006 -j DROP

/usr/sbin/iptables -A FORWARD -p tcp -s 0/0 --dport 8007 -j DROP

記得寫在 crontab  @reboot

在PVE中撈出所有guest的 cpu使用率並在超過上限值時發出告警

#!/bin/bash

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

cat /tmp/all_guest_cpu | awk  '$3 > 80 {print $0}' > /tmp/guest_cpu_high

if [ -s /tmp/guest_cpu_high ]; then

        sed -i '1i network guest cpu high' /tmp/guest_cpu_high

        sed -i '2i ==========' /tmp/guest_cpu_high

        cp /tmp/guest_cpu_high /tmp/guest_cpu_high_network

        /usr/bin/lftp ftp://user:pwd@10.0.0.1 -e "put /tmp/guest_cpu_high_network; bye"

        mutt -s guest_cpu_high user@abc.com < /tmp/guest_cpu_high

fi

PVE 的 LXC 使用 almalinux 9 時

把 開几需要啟動的指令下在 /etc/rc.local 沒有作用

因為 rc-local 這個daemon 一直起不來 有問題

改用 @reboot

如果還是一直不成功的話

會需要在之前先 sleep 一下

如

@reboot sleep 5;/root/some_thing_need_start 

延續昨天的問題

昨天修好後當下沒問題

但今天管理介面打不開了

直接倒回去颱風前一天的備分

目前看來運作正常

持續觀察

順便看看還有那些有問題

dmesg|grep "fsck"|grep dm

[   82.486238] EXT4-fs (dm-6): warning: mounting fs with errors, running e2fsck is recommended

[  139.304759] EXT4-fs (dm-11): warning: mounting fs with errors, running e2fsck is recommended

[  398.955415] EXT4-fs (dm-6): error count since last fsck: 2

[  464.490594] EXT4-fs (dm-11): error count since last fsck: 3769411

[55841.695354] EXT4-fs (dm-12): error count since last fsck: 2

[88379.937761] EXT4-fs (dm-6): error count since last fsck: 2

[88547.518964] EXT4-fs (dm-6): warning: mounting fs with errors, running e2fsck is recommended

[88871.451957] EXT4-fs (dm-6): error count since last fsck: 3

共三台

先到 /dev/mapper 查看是那個guest

lrwxrwxrwx  1 root root       7 Oct  7 23:45 pve-vm--116--disk--0 -> ../dm-6

lrwxrwxrwx  1 root root       8 Oct  8 00:08 pve-vm--124--disk--0 -> ../dm-11

lrwxrwxrwx  1 root root       8 Oct  8 09:04 pve-vm--140--disk--0 -> ../dm-12

一起倒備分吧

不想修了

PVE host 修好換裡面的LXC guset 有問題

guest 先關几

找出那個disk

繼續修

fsck /dev/mapper/pve-vm--124--disk--0

几次的不正常斷電後

PVE開不起來了

修吧

xfs_repair /dev/mapper/pve-root

修好後正常了

再觀察看看

一直在處理almalinux 9 live migrate的問題

目前得到的結果是

使用 x86-64-v2-AES 這個cpu type 就沒有問題

而且這個type 也是 PVE目前新建guest使用的預設值

但graylog使用這個type 能開機 但無法執行

目前改成 x86-64-v3 能開機 能執行

試了一下 live migrate 也沒問題

使用 host 是一定有問題的

在支援相同cpu type 的host live migrate是沒問題的

檢查 cpu 支援那些 type

#!/bin/sh -eu

flags=$(cat /proc/cpuinfo | grep flags | head -n 1 | cut -d: -f2)

supports_v2='awk "/cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/ {found=1} END {exit !found}"'

supports_v3='awk "/avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/ {found=1} END {exit !found}"'

supports_v4='awk "/avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/ {found=1} END {exit !found}"'

echo "$flags" | eval $supports_v2 || exit 2 && echo "CPU supports x86-64-v2"

echo "$flags" | eval $supports_v3 || exit 3 && echo "CPU supports x86-64-v3"

echo "$flags" | eval $supports_v4 || exit 4 && echo "CPU supports x86-64-v4"

https://www.modb.pro/issue/26425

這陣子PVE 在live migrade 時

有几台在migrade到新host後

就自動關几了

出現以下錯誤

2024-07-19 07:55:24 ERROR: tunnel replied 'ERR: resume failed - VM 103 qmp command 'query-status' failed - client closed connection' to command 'resume 103'

目前觀察到都是almalinux 9 

cpu type 是host

但又不是所有的almalinux 9 都會有問題

還在找問題

 proxmox 8 安裝後修正apt source 並更新

#!/bin/bash

sed -i '1s/^/#/' /etc/apt/sources.list.d/ceph.list

sed -i '1s/^/#/' /etc/apt/sources.list.d/pve-enterprise.list

echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" >> /etc/apt/sources.list

echo "export http_proxy=http://10.1.1.1:3128" > /root/update

echo "apt-get update" >> /root/update

echo "apt-get upgrade -y" >> /root/update

echo "apt-get autoremove -y --purge" >> /root/update

chmod +x /root/update

/root/update

朋友介紹的好用免費 P2V 軟体

https://www.starwindsoftware.com/starwind-v2v-converter

昨天有朋友問我說proxmox的guest開不了几

不知是什麼問題

連進去看了一下

發現一個guest開了好几個HD

而且每個HD都開到2T

而且還做了好几個snapshot

導致實際上guest的HD 膨脹 到5T或更大

把空間全部吃滿了

所以無法開几

因為是使用qcow2格式

所以snapshot會長在原來的檔案上

我是覺得奇怪

guest開那麼多個2T的檔案

user不會覺得效能不好嗎

解決的方式就是把舊的snapshot砍一砍

再觀察看看

今天在檢查 pbs 時又出現 GC (garbage collection) warning 的log

再去看前一天的備分

是顯示備份完成且沒有錯誤的

不知道為什麼備分完成沒有錯誤但GC時會出現如下的錯誤

2023-02-02T00:00:22+08:00: WARN: warning: unable to access non-existent chunk 4d9f87572f2ff8d9f324aef1263e1ab47181a764aac801918b6dd5567fdfdde9, required by "/mnt/nfs418/ct/112/2023-01-31T16:00:47Z/catalog.pcat1.didx"

2023-02-02T00:00:22+08:00: WARN: warning: unable to access non-existent chunk e82ad3ac9b4b29c55420a44c29029c1a69ebd2cae156994c7e6a4f6a3b44524d, required by "/mnt/nfs418/ct/112/2023-01-31T16:00:47Z/catalog.pcat1.didx"

2023-02-02T00:00:22+08:00: WARN: warning: unable to access non-existent chunk 7eeadcfafebe86f0244ab4b07167644784be8485da119208d91e078efb48a7de, required by "/mnt/nfs418/ct/112/2023-01-31T16:00:47Z/root.pxar.didx"

而且問題來了

再接下來每一次備分都會顯示備分完成無異常

但GC就會一直錯誤

而且一旦GC有錯誤這個備分就無法還原

目前pbs在GC有錯誤時無法主動發mail 告警

所以解決方法就是寫個程式每天檢查GC是否有錯誤

如果有

就要把有錯誤相關的備分砍了

讓接下來的備分能正常

前一陣子發生了一件很OX的事

試了很久 現在做個記錄

因為有幫別的部門架了一台proxmox

而且那個部門也有一台nas

因此我就在那台nas上開了nfs然後用pbs備份

他老兄在某一天竟然進到nas把我備分用的那個nfs裡的資料砍了

然後第二天就出現了如下的error

ProxmoxBackup Server 2.3-2

2022-12-29T00:00:00+08:00: starting garbage collection on store nfs418

2022-12-29T00:00:00+08:00: task triggered by schedule 'daily'

2022-12-29T00:00:00+08:00: Start GC phase1 (mark used chunks)

2022-12-29T00:01:03+08:00: marked 5% (1 of 17 index files)

2022-12-29T00:04:14+08:00: marked 11% (2 of 17 index files)

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk c3fe251560dcd2cc5aef7cfbd6669d0dd9ca7491c455f537efc6d319b09892ec, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 6dc29793341c20c7c80910a73893501b034a0e29c14a444d214d835ccffc0d16, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 1f81c244f9b7816ab37d3ef7ffdcd10443eb1bddb3fa44e036186b73f1fee33a, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 95c7e6747d43b5b516e1768a1f258f352aeb47b23fd46575440dc3d820d1b253, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 9513a7e5c650245d3344115115b21285cc8f426e5284fa04159ea96e49856535, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 68b2b40dd3bacba9e649c67862011934bc7f048d8ea2d35fbd95c39f9d5cf7c4, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 494608d49f57039fd7a8378e1a2a2cf6bb0688773a525addc2f54507a94cd11d, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 09eab384d5f3cbf657db1c0750ef52be2f1dbdf134f977a24dc095382b6e25ed, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx"

2022-12-29T00:04:14+08:00: WARN: warning: unable to access non-existent chunk 9c1208d43242276c75a4f65f41054e4bc0e7e1144a61c951902bb8df94f055c9, required by "/mnt/nfs418/vm/108/2022-12-27T15:45:38Z/drive-virtio0.img.fidx" 

..........................................

後面還一大堆

本來是想說把pbs上的datastore砍了重建應該可以解決問題

forum上也是醬說的

結果不是

我砍了datastore重建

甚至在nas上再開另一個nfs後再重建datastore

過沒几天又會出現如上的錯誤

最後的解決方法是直接重裝一台新的pbs

問題才解決

無言中