在使用 PVE 的這段時間以來其實也已經迎來了一次大版本的更新，所謂的大版本更新就是其前綴數字的更替，這次的更新版本是從 PVE 7 升級到 PVE 8，因此就藉由這次的 Server 更新實錄，讓我們看看 PVE 的版本與內容更新是應該如何操作的吧～

Server 的版本更新小故事

一般來說，一個服務都會經歷各式各樣的修正 / 更新 / 調整，那我們今天會從不同的角度分別看待更新這件事情。

首先，一般來說我們會把更新分成三種類型，分別是：

1. Major Update (大版本更新)
2. Minor Update (小版本更新)
3. Patch Update (修正版本更新)

那其中的差異基本上可以從更新的「項目」而有所區分，一般來說

1. 如果是針對版本中的「內容、功能、服務、介面」等等進行大幅度的更新調整，甚至是添加全新的元素，那就會被歸類為 Major Update
2. 如果是針對版本中的小元件進行更新，例如：修正某些功能的 Bug、調整某些功能的介面元素、調整某些功能的運作方式等等，那就會被歸類為 Minor Update
3. 如果是針對版本中的小元件錯誤 / 漏洞 / 或者是安全性問題進行修正，那就會被歸類為 Patch Update

而一般來說，為了確保環境與服務能夠提供最安全穩定的運作，其實是不會輕易針對版本還有環境進行更新的，甚至每次更新都需要異常的小心，但這樣就是對安穩的選擇嗎？

針對更新這個議題其實可以討論的非常深，因此我們直接抓兩個面向做討論

1. 穩定性
2. 安全性

一般來說，沒有絕對安全的程式碼，沒有絕對沒有的漏洞，不管是開源或者閉源服務都一定會有需要調整 / 更新 / 修正的地方，因此當今天我們使用環境時，就會需要考慮一個問題，今天就是我們更新環境是為了什麼？如果是為了全新的功能提供、更酷炫的畫面支援等等，我認為不會是一個正在提供服務的環境應該貿然嘗試的，因為當今天新的功能與元素被添加時，往往會對於系統架構與程式碼有大量的調整，甚至一些驅動邏輯會有所更新，這時候是否對於原本正在運行的服務有所影響就全部都是一個未知數，在這樣的情況下，我們就會需要考慮是否要更新環境。

但如果今天是針對漏洞 / 安全性問題進行修正，那就是一個必須要更新的情況，因為當今天有漏洞存在時，就代表著我們的環境就有可能被攻擊，而這樣的情況下，我們就必須要進行更新，因為這是一個必須要做的事情。

因此回歸到上面所討論的，一般來說，我們會針對小版本 / 補丁版本的版本更新做基本的維護與更新，因為這些更新可能都是為了解決某些既有元件的問題，因而裡因不會對於環境造成太大的影響，但如果是大版本更新，那就需要考慮是否要進行更新了。我們直接講一個關於虛擬化的例子來說明。

QEMU 的血淚更新史

我目前正在使用 MacBook 作為我的工作用機器，但因為晶片架構的問題，目前的 Mac 針對 amd64 的程式基本上都會需要經過虛擬化工具的轉換與模擬，方能使用，雖然有所不方便，但還好我們有 QEMU 這個好用的虛擬化工具正在協助我們進行相關轉換（Apple 本身也有羅賽塔可以幫忙轉換），而我有些服務也是基於 QEMU 這個虛擬化工具作為基底去額外運作包裝的，因此可以說雖然是不同的應用程式，但卻都是基於 QEMU 這個虛擬化工具在運作。

由於 Apple 社群的推廣與進化，相關支援其實迭代的非常快速與活躍，從 Apple 第一次將 AARM 晶片架構推出後無法使用任何虛擬機到現在已經算是百家爭鳴的今天，相關社群的努力功不可沒，但這樣快速努力的開發也造成了一些問題，那就是穩定性並沒有如我們預期的那樣好。

在 QEMU 近期的一次大版本更新時，就造成了虛擬化硬碟的獲取有嚴重的錯誤，並且在環境初始化上也有所影響，一時間我電腦中的所有環境都無法再做使用，並且由於我的版本更新其實跨度有點大，因此完全無法定位問題所在，在歷經各種版本的調整與修正後，才終於在最後給予特定的 QEMU 版本來緩解服務的問題，這就是一個活生生關於環境更新的例子。

更新的好習慣

雖說剛剛好像都只有在大版本更新時才會遇到這個問題，但其實關於更新後服務打不開的故事屢見不鮮，絕對不會因為是 patch / minor update 就可以隨意更新並且都不會有問題發生，因此我們一定常常聽到各種警告要我們在更新前做好備份，並且確認一定要確認備份文件是否可以正常還原，才能確保當問題發生時，能在最短的時間內恢復服務。這也正是包含 PVE 的官方更新說明中，一定會提到的事情。

PVE 的版本更新

那這次我們會分成兩個部分的解說來說明 PVE 的版本更新，分別是：

1. PVE 的小版本更新
2. PVE 的大版本更新

PVE 的小版本更新

我們有提過 PVE 其實是 Debian Base 的應用服務，因此在更新上其實也是直接使用 apt 套件做更新，那一般來說

apt update
apt upgrade -y

上述指令組合會是我們一般使用 Debian Base OS 的基本工具更新指令，那上述指令只會針對 PVE 中的工具套件進行更新，可以想像成 Patch Update 的概念，也就是說這樣的更新並不會造成任何大/小版本的更新迭代，只會針對錯誤的相關問題進行修正，因此當我們更新完服務後，我們 PVE 的版本本身是不會有任何更替的。

apt upgrade 指令只會更新現有檔案，並不會有解除安裝後再安裝的動作發生，因此不會有元件消失或者是新增的情況發生，因此這樣的更新方式是最安全的更新方式。

那當今天我們希望幫我們的 PVE 進行更全面且跨版本的更新時，我們就需要使用到 dist-upgrade 指令，這個指令會針對所有的套件進行更新，並且會有解除安裝後再安裝的動作發生，因此這樣的更新方式是較為不安全的更新方式，但也是最全面的更新方式。

apt update
# 官方文件所述
apt dist-upgrade -y
# 但實際上我們會使用 full-upgrade 這個指令
apt full-upgrade -y

full-upgrade 跟 dist-upgrade 其實差異很模糊，一般來說 full-upgrade 算是 dist-upgrade 的別名，但在部份解釋文件中，可以看到 full-upgrade 相比 dist-upgrade 是一個更加激進的更新方式。
但我們依照 AskUbuntu 的說明討論可以看到，dist-upgrade 跟 full-upgrade 屬於別名的關係，因此上述操作時，我們可以就參考 PVE 官方文件說明，或者依照用新不用舊的原則，選擇使用 full-upgrade 指令即可。

PVE 的大版本更新

那這樣的版本更新是不會造成大版本的版本更替的，原因是因為當今天有一個全新的版本釋出時，一般來說為了避免造成原本環境的影響，是會直接將整個支援的環境另外安裝準備的，而不會與目前的環境進行共用，因此當我們希望針對環境版本進行調整時，會需要更改之前有提到的 sources.list 檔案，並且將其更改為新的版本，之後再運行的更新將會是大版本更新了。

在後續說明更新之前，PVE 其實有提供 PVE 7 升級成 PVE 8 的說明文件 / 檢查指令等等，這邊我們先附上官方說明文件，大家可以對照觀看，另外也請在執行後續步驟前，先利用下面所提供的指令檢查環境是否已經準備好可以進行更新了。

• PVE 7 升級成 PVE 8 官方說明文件

PVE 7 升級成 PVE 8 的檢查指令

pve7to8
# for all checks enabled
pve7to8 --full

請注意，在進行大版本更新前，PVE 官方文件有說明需要先在 PVE 7 中更新到最新版本，才能進行 PVE 8 的更新，因此請先確認 PVE 7 是否已經更新到最新版本。

• 可以直接運行 apt update && apt dist-upgrade -y 進行第一次 PVE 7 內的小版本更新

因此舉例來說，這次我們要將 PVE 7 更新到 PVE 8，我們就會需要將 sources.list 檔案中的版本更改為 PVE 8 的版本，並且運行 dist-upgrade 指令，這樣的更新方式就會是大版本更新，而更新的項目就是將原本的 bullseye 目標點更新成 bookworm 目標點，而更新方式可以利用 sed 指令來進行替換。

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

這個時候我們重新運作

apt update
apt dist-upgrade -y

就會看到我們的版本直接更新到 PVE 8 了。

小結

版本更新往往會有很多好處，確保環境不會過舊也能提高服務的安全性，但往往我們無法猜測這次的環境更新是否會對我們的服務造成影響，因此在更新前一定要先做好備份，並且確認備份文件是否可以正常還原，才能確保當問題發生時，能在最短的時間內恢復服務。