Auto-update blog content from Obsidian: 2025-11-04 19:52:37
All checks were successful
Blog Deployment / Check-Rebuild (push) Successful in 6s
Blog Deployment / Build (push) Has been skipped
Blog Deployment / Deploy-Staging (push) Successful in 10s
Blog Deployment / Merge (push) Successful in 6s
Blog Deployment / Deploy-Production (push) Successful in 10s
Blog Deployment / Test-Production (push) Successful in 2s
Blog Deployment / Clean (push) Has been skipped
Blog Deployment / Test-Staging (push) Successful in 3s
Blog Deployment / Notify (push) Successful in 2s

This commit is contained in:
Gitea Actions
2025-11-04 19:52:37 +00:00
parent 0598cf2a5f
commit ef84e229b2

View File

@@ -14,25 +14,27 @@ categories:
## Intro ## Intro
My **Proxmox VE** cluster is almost one year old now, and it's been a while since I didn't update my nodes. Now is the time to move forward and bump it to Proxmox VE **9**. My **Proxmox VE** cluster is almost one year old now, and I havent kept the nodes fully up to date. Time to address this and bump it to Proxmox VE **9**.
I'm mainly interested in the new HA affinity rules, here what this version brings: I'm mainly after the new HA affinity rules, but here the useful changes that this version brings:
- Debian 13 "Trixie" - Debian 13 "Trixie".
- Snapshots for thick-provisioned LVM shared storage - Snapshots for thick-provisioned LVM shared storage.
- Fabrics feature for the SDN stack - SDN fabrics feature.
- Better mobile interface - Improved mobile UI.
- Affinity rules in HA cluster - Affinity rules in HA cluster.
In this article, I will walk you through the upgrade steps for my Proxmox VE highly available cluster supported by **Ceph** distributed storage. The goal is to upgrade the cluster while keeping the resources up and running. The official documentation can be found [here](https://pve.proxmox.com/wiki/Upgrade_from_8_to_9). The cluster is a threenode, highly available, hyperconverged setup using Ceph for distributed storage.
In this article, I'll walk through the upgrade steps for my Proxmox VE cluster, from 8 to 9, while keeping the resources up and running. [Official docs](https://pve.proxmox.com/wiki/Upgrade_from_8_to_9).
--- ---
## Prerequisites ## Prerequisites
Before jumping into the upgrade, let's review the prerequisites: Before jumping into the upgrade, let's review the prerequisites:
1. All nodes upgraded to the latest version of Proxmox VE 8.4. 1. All nodes upgraded to the latest Proxmox VE `8.4`.
2. Ceph: upgrade cluster to Ceph 19.2 Squid before. 2. Ceph cluster upgraded to Squid (`19.2`).
3. Proxmox Backup Server: upgrade to Proxmox BS 4. 3. Proxmox Backup Server upgraded to Proxmox BS 4.
4. Reliable access to the node. 4. Reliable access to the node.
5. A healthy cluster. 5. A healthy cluster.
6. backup of all VMs and CTs. 6. backup of all VMs and CTs.
@@ -42,11 +44,11 @@ Well, I have some homework to do before the major upgrade to Proxmox VE 9. My no
Then my Ceph cluster, for the distributed storage, is using Ceph Reef (`18.2.4`). After the update to Proxmox VE 8.4, I'll move from Ceph Reef to Squid. Then my Ceph cluster, for the distributed storage, is using Ceph Reef (`18.2.4`). After the update to Proxmox VE 8.4, I'll move from Ceph Reef to Squid.
I don't use Proxmox Backup Server in my homelab for now, I can skip that point. For the access to the nodes, it is better if I could reach the console (not from theProxmox WebGUI). I don't have direct access, In only have SSH. I don't use Proxmox Backup Server in my homelab for now, I can skip that point. For the access to the nodes, it would be better if I could reach the console (not from the Proxmox WebGUI). I don't have direct access, I only have SSH. If a node fails, I'd have to take it off the rack.
The last points are checked, all my nodes have more than 10GB on the `/` mount point. The last points are checked, all my nodes have more than 10GB on the `/` mount point.
One of my VM is using the host's processing unit of the APU via PCI pass-through. As this prevents the VM from hot migration, I remove the device at the beginning of this procedure to avoid having to restart the VM each time. One of my VM is using the host's processing unit of the APU via PCI passthrough. As this prevents the VM from hot migration, I remove the device at the beginning of this procedure to avoid having to restart the VM each time.
Also, until the end of the upgrade to Proxmox VE 9, I set the Ceph OSDs as "no out", to avoid the CRUSH algorithm to try to rebalance the Ceph cluster during the upgrade: Also, until the end of the upgrade to Proxmox VE 9, I set the Ceph OSDs as "no out", to avoid the CRUSH algorithm to try to rebalance the Ceph cluster during the upgrade:
```bash ```bash
@@ -67,7 +69,7 @@ apt-get update
apt-get dist-upgrade -y apt-get dist-upgrade -y
``` ```
At the end of the update, I'm aksed to remove a bootloader, which I execute: At the end of the update, I'm asked to remove a bootloader, which I execute:
```plaintext ```plaintext
Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it! Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command: Run the following command:
@@ -125,7 +127,7 @@ Once all monitors are restarted, they report the latest version, with `ceph mon
- Before: `min_mon_release 18 (reef)` - Before: `min_mon_release 18 (reef)`
- After: `min_mon_release 19 (squid)` - After: `min_mon_release 19 (squid)`
Now I can restart the OSD, still one node at a time. I have one OSD per node: Now I can restart the OSDs, still one node at a time. I have one OSD per node:
```bash ```bash
systemctl restart ceph-osd.target systemctl restart ceph-osd.target
``` ```
@@ -400,7 +402,7 @@ For the VM which I removed the host mapping at the beginning of the procedure, I
- Add privileges for the Terraform role - Add privileges for the Terraform role
During the check phase, I was advised to remove the privilege `VM.Monitor` from my custom role for Terraform. Now that new prileges have been added with Proxmox VE 9, I can assign them to that role: During the check phase, I was advised to remove the privilege `VM.Monitor` from my custom role for Terraform. Now that new privileges have been added with Proxmox VE 9, I can assign them to that role:
- VM.GuestAgent.Audit - VM.GuestAgent.Audit
- VM.GuestAgent.FileRead - VM.GuestAgent.FileRead
- VM.GuestAgent.FileWrite - VM.GuestAgent.FileWrite