Cum repari eroarea Proxmox VE 9: „The current guest configuration does not support taking new snapshots”

Dacă Proxmox VE 9 afișează „The current guest configuration does not support taking new snapshots” pe un VM aflat pe LVM thick, cauza obișnuită nu este o funcție de snapshot defectă. Cauza obișnuită este că acel VM încă nu este eligibil pentru noul flux snapshot-as-volume-chain. În practică, asta înseamnă aproape întotdeauna unul dintre trei lucruri: storage-ul LVM nu are snapshot-as-volume-chain 1 activat, discul VM-ului este încă raw în loc de qcow2, sau guest-ul are un dispozitiv ori un element de configurație nesuportat care face interfața să refuze snapshot-uri noi.

Din experiența noastră administrând medii Proxmox, acesta este exact genul de problemă care irosește timp pentru că mesajul din UI este tehnic corect, dar operațional incomplet. Îți spune că configurația guest-ului nu este suportată. Nu îți spune ce parte nu este suportată. Asta îi face pe mulți să urmărească buguri de storage, buguri de cluster și buguri de permisiuni, când răspunsul real este de obicei în /etc/pve/storage.cfg sau în linia de disc a VM-ului din qm config.

Acest runbook este pentru LVM thick pe Proxmox VE 9, nu pentru LVM-thin și nici pentru o prezentare generală a snapshot-urilor. Scopul este simplu: identifici de ce UI-ul refuză snapshot-urile, repari blocajul exact și verifici că guest-ul este acum eligibil.

Ce verifică de fapt Proxmox

Cu noul suport pentru snapshot-uri pe LVM thick din Proxmox VE 9, snapshot-urile nu sunt implementate prin revenirea la vechile snapshot-uri native LVM pentru discul guest-ului. Proxmox a adăugat suportul snapshot-as-volume-chain pentru a evita penalizările de performanță și operaționale ale snapshot-urilor LVM native. Asta contează pentru că noua funcție are condiții clare. Dacă layout-ul de storage și de disc nu respectă acele condiții, butonul de snapshot rămâne indisponibil și primești mesajul „The current guest configuration does not support taking new snapshots”.

Traducerea practică este aceasta:

• Storage-ul trebuie să fie LVM thick, cu snapshot-as-volume-chain activat.
• Discul VM-ului trebuie să fie în formatul așteptat de acel flux.
• Configurația guest-ului nu trebuie să includă un dispozitiv care încă blochează noua cale de snapshot.

Dacă oricare dintre aceste condiții eșuează, UI-ul refuză întregul guest.

Cele mai frecvente două cauze

Cei mai mulți operatori se lovesc mai întâi de una dintre acestea:

• Lipsește flagul de storage. Storage-ul LVM există și discul se află acolo, dar snapshot-as-volume-chain 1 nu este prezent în /etc/pve/storage.cfg.
• Discul este încă raw. VM-ul a fost creat sau migrat anterior ca format=raw, iar noua cale de snapshot pentru LVM thick nu este disponibilă pentru acel layout de disc.

Un al treilea blocaj apare suficient de des încât merită menționat separat:

• Guest-ul are TPM atașat. Rapoarte recente din teren arată că VM-urile cu TPM pot afișa în continuare aceeași eroare „unsupported” chiar și după ce flagul de storage este activat și discul este qcow2.

Ultimul punct este important pentru că produce un fals negativ în timpul depanării. Repari storage-ul, convertești discul, iar UI-ul încă spune nu. În acel moment mulți administratori presupun că au înțeles greșit funcția. Uneori blocajul real este pur și simplu că VM-ul încă are configurat un disc TPM.

Pasul 1: inspectează definiția storage-ului

Începe cu stratul de storage. Nu ghici din GUI. Citește configurația reală a clusterului.

cat /etc/pve/storage.cfg

Pentru storage-ul LVM țintă, vrei să vezi ceva de genul:

lvm: lunlvm
        vgname vg_lun
        content images,rootdir
        shared 1
        snapshot-as-volume-chain 1

Dacă acea ultimă linie lipsește, refuzul din UI are sens. Ai activat sau ai crezut că ai activat „LVM snapshots in Proxmox 9”, dar nu exact proprietatea de storage cerută de noul mecanism.

O problemă comună pe care o vedem în producție este că administratorii creează un storage nou în GUI, presupun că toggle-ul a rămas salvat, apoi compară mai târziu comportamentul între noduri sau clustere și descoperă că flagul nu a ajuns niciodată în configurația reală a clusterului. Primul lucru pe care îl verificăm este întotdeauna fișierul de cluster, nu memoria despre cum a fost creat storage-ul.

Pasul 2: inspectează formatul discului VM-ului

După ce ai confirmat flagul de storage, inspectează guest-ul propriu-zis.

qm config 104

Cauți linia discului. Pe un guest care încă eșuează, ea arată adesea așa:

scsi0: lunlvm:vm-104-disk-0,format=raw,size=20G

Acesta este indiciul esențial. Pe LVM thick cu snapshot-as-volume-chain, blocajul real din teren este frecvent faptul că discul este încă raw. Thread-uri recente ale operatorilor arată exact același tipar: suportul pentru snapshot a fost activat pe storage, dar snapshot-urile au continuat să eșueze până când discul virtual a fost convertit în qcow2. De aceea UI-ul refuză. Storage-ul suportă funcția. Layout-ul de disc al guest-ului încă nu o suportă.

Pe un guest aliniat corect, calea de disc ar trebui să reflecte un flux bazat pe qcow2, nu un disc raw rămas din decizii mai vechi de plasare sau migrare.

Pasul 3: convertește discul în loc să refaci VM-ul

De obicei nu este nevoie să refaci guest-ul. Remedierea normală este să muți discul și să îl convertești în qcow2. În interfața Proxmox, folosește acțiunea de move disk a VM-ului, mută discul către același storage LVM și alege qcow2 ca format țintă, dacă opțiunea este disponibilă.

Aici ratează de obicei administratorii. Ei presupun că „același storage” înseamnă „nicio schimbare reală”. În practică, mutarea discului către același storage țintă poate fi cea mai curată metodă de a forța o conversie de format și de a alinia guest-ul la noul model de snapshot.

După mutare, rulează din nou qm config și verifică faptul că definiția discului nu mai reflectă vechiul layout raw.

Pe LVM thick, asta explică și de ce funcția există în forma actuală. Proxmox nu pretinde că LVM thick a devenit brusc thin-provisioned. Lanțul de snapshot-uri este creat prin volume suprapuse, în timp ce qcow2 gestionează metadatele necesare acelui lanț. De aceea documentația descrie volumele de snapshot ca volume logice LVM thick-provisioned și explică în același timp că abordarea bazată pe chain evită penalizările snapshot-urilor LVM native.

Pasul 4: verifică TPM și alte blocaje la nivel de guest

Dacă flagul de storage este prezent și discul este qcow2, dar UI-ul încă refuză snapshot-urile, inspectează restul configurației guest-ului. Cel mai vizibil edge case actual este TPM.

qm config 104 | grep -Ei 'tpm|efidisk|scsi|virtio|sata|ide'

Dacă vezi un dispozitiv TPM atașat, testează având acest lucru în minte înainte să continui să modifici setările de storage. Rapoarte curente ale operatorilor arată că un VM cu TPM poate păstra opțiunea de snapshot inactivă chiar și atunci când storage-ul LVM și discul qcow2 sunt altfel corecte.

Asta nu înseamnă „șterge funcțiile de securitate la întâmplare”. Înseamnă să izolezi blocajul. Dacă este un VM de laborator, poți testa prin eliminarea temporară a TPM și verificarea faptului că disponibilitatea snapshot-ului revine. Dacă este un guest Windows de producție sau orice guest legat de BitLocker, workflow-uri secure boot sau cerințe de conformitate, nu trata eliminarea TPM ca pe un simplu toggle fără consecințe. Înțelege mai întâi dependența guest-ului.

De ce UI-ul refuză complet în loc să permită parțial

Partea aceasta îi derutează pe mulți, pentru că guest-ul poate părea simplu. Un disc. Un nod. Nicio complexitate evidentă. Totuși panoul de snapshot refuză întregul VM.

Motivul este logic din punct de vedere operațional. Proxmox nu îți evaluează intenția. Evaluează dacă întreaga configurație a guest-ului suportă în siguranță un snapshot nou în modelul actual de storage. Dacă o singură piesă necesară nu se aliniază, UI-ul nu oferă un flux de snapshot pe jumătate funcțional. Blochează acțiunea.

Cu alte cuvinte, mesajul este general pentru că și verificarea de eligibilitate este generală. De aceea trebuie să inspectezi ambele straturi:

• eligibilitatea storage-ului
• eligibilitatea formatului de disc
• eligibilitatea dispozitivelor guest-ului

Administratorii pierd timp aici pentru că se opresc după prima remediere parțială. Activează flagul de storage și presupun că funcția ar trebui acum să meargă pentru toate discurile aflate deja acolo. Comportamentul actual nu funcționează așa.

O secvență practică de validare

Când un client deschide un tichet de tipul „de ce snapshot-ul este încă gri”, aceasta este secvența pe care o folosim:

1. Citește /etc/pve/storage.cfg și confirmă că snapshot-as-volume-chain 1 este prezent pe storage-ul LVM corect.
2. Rulează qm config <VMID> și inspectează linia reală a discului.
3. Dacă discul este raw, mută-l sau convertește-l în qcow2 pe storage-ul LVM țintă.
4. Rulează din nou qm config <VMID> și confirmă noul layout.
5. Verifică TPM și alte dispozitive ale guest-ului dacă snapshot-urile sunt încă indisponibile.
6. Reîncearcă snapshot-ul doar după ce toate cele trei straturi se aliniază.

Ordinea aceasta contează. Dacă începi cu editări ale guest-ului făcute la întâmplare înainte să confirmi storage-ul și formatul discului, creezi zgomot. Dacă începi prin a da vina pe storage înainte să citești configurația VM-ului, creezi iar zgomot. Cea mai rapidă remediere este o secvență disciplinată.

Ce se strică de obicei în timpul remedierii

• Ai activat flagul pe storage-ul greșit. Discul VM-ului este pe un alt backend LVM decât cel pe care l-ai editat.
• Ai presupus că vechile discuri raw vor deveni eligibile automat. De obicei nu se întâmplă asta.
• Ai verificat GUI-ul, nu configurația de cluster. Adevărul este în /etc/pve/storage.cfg.
• Ai convertit un disc, dar ai uitat că guest-ul mai are un alt disc sau dispozitiv nesuportat.
• Ai ignorat TPM ca blocaj. Apoi continui să reverifici storage-ul, deși problema reală este layout-ul de dispozitive al VM-ului.

Un insight de producție aici: motivul cel mai frecvent pentru care acest tichet se prelungește nu este că remedierea este grea. Este că echipele presupun că poate exista un singur blocaj. În Proxmox, eligibilitatea de storage și eligibilitatea guest-ului sunt verificări separate care pot conta în același timp.

Când snapshot-urile pe LVM thick nu merită să devină o obsesie

Fii sincer în legătură cu întrebarea mai mare de design. Dacă mediul tău se bazează puternic pe snapshot-uri, clone, rollback rapid și lucru frecvent cu template-uri, LVM-thin sau un alt backend de storage poate fi în continuare alegerea operațională mai curată. Suportul pentru snapshot pe LVM thick din Proxmox VE 9 este util, dar este un flux specific cu cerințe specifice. Nu este un permis gratuit de a trata orice vechi layout thick LVM ca pe un design orientat în primul rând spre snapshot-uri.

Aici pierd de obicei timp echipele fără expertiză dedicată de virtualizare. Ele nu depanează doar o singură eroare. Încearcă să forțeze decizii vechi de storage să se comporte ca un model de platformă diferit.

Pentru echipele care nu vor să piardă ore urmărind flaguri de storage, nepotriviri de format de disc și edge case-uri la nivel de guest, serviciul ServerSpan de management Proxmox este alternativa practică. Dacă problema de fond este că stack-ul tău de virtualizare a depășit mentenanța ad hoc, de obicei are mai mult sens să repari stratul operațional decât să continui să stingi un tichet de storage după altul.

Dacă problema este mai mare decât un singur VM și regândești unde ar trebui să trăiască workload-urile suport, un deployment curat pe infrastructura potrivită de servere virtuale este de obicei mai valoros decât să forțezi încă un trimestru de excepții pe un design de storage îmbătrânit.

Pentru context mai larg, vezi Dincolo de Proxmox: Peisajul virtualizării în 2026 și ce urmează și CVE-2025-11234: Vulnerabilitatea QEMU-KVM VNC WebSocket use-after-free permite DoS înainte de autentificare.

Runbook-ul scurt

1. Deschide /etc/pve/storage.cfg.
2. Confirmă că storage-ul LVM țintă are snapshot-as-volume-chain 1.
3. Rulează qm config <VMID>.
4. Dacă discul VM-ului este format=raw, mută-l sau convertește-l în qcow2.
5. Verifică din nou qm config <VMID>.
6. Dacă snapshot-urile sunt încă blocate, inspectează guest-ul pentru TPM și alte dispozitive nesuportate.
7. Reîncearcă doar după ce storage-ul, formatul de disc și configurația guest-ului se aliniază toate.

Dacă parcurgi pașii în acea ordine, eroarea din UI încetează să mai fie vagă. Devine o listă de verificare.