8 saker du aldrig bör göra i Proxmox (om du inte vill att ditt homelab ska krasch)

Proxmox gör det enkelt att skapa ett homelab, men insikt om systemets gränser är avgörande för att undvika vanliga misstag och potentiella katastrofer.

Proxmox erbjuder en smidig lösning för att sätta upp ett homelab på en eftermiddag. Men denna enkelhet kan leda till missförstånd.

För att effektivt hantera en Proxmox-värd krävs insikt i vad Proxmox äger versus vad som tillhör lagring, nätverk och operativsystem. De följande 8 misstagen uppstår ofta på grund av att dessa gränser överskrids utan djupare förståelse.

Aldrig behandla /etc/pve som en normal mapp

Proxmox använder sitt eget filsystem för klusterkonfiguration

Linux-administratörer kan felaktigt anta att /etc/pve fungerar som en vanlig mapp. I verkligheten hanteras den av Proxmox Cluster File System, eller pmxcfs, som lagrar kritisk information om virtuella maskiner, containrar och klusterinställningar, samt hanterar åtkomstkontroll och certifikat.

Detta innebär att vanliga filsystemåtgärder kräver större försiktighet. Att ta bort gamla filer eller ersätta konfigurationsfiler kan leda till allvarliga problem, betydligt mer omfattande än vanliga Linux-konfigurationsfrågor.

Använd Proxmox egna verktyg för att göra ändringar. Vid direkta konfigurationsändringar, ha koll på pmxcfs och dess påverkan på hela klustret.

Aldrig ta bort VM-diskar direkt från lagring

Proxmox måste veta vad som hände med en virtuell disk

Varje virtuell disk har en motsvarighet i Proxmox och ett objekt på lagringsenheten. Beroende på din setup kan objektet vara en fil, en LVM-thin-volym, en ZFS-volym eller en Ceph RBD-bild.

Om du tar bort det underliggande objektet kommer VM-konfigurationen att referera till något som inte längre existerar. Problemet kan vara osynligt om VM är avstängd, vilket gör det lockande att rensa lagring manuellt. Men konsekvenserna visar sig när du försöker starta VM, justera hårdvarukonfigurationen, återställa snapshots eller utföra andra åtgärder.

Det samma gäller för diskar knutna till borttagna VMar. Innan du gör något, dubbelkolla Proxmox-konfigurationen och lagringsöversikten för att säkerställa att volymen verkligen är ensamt stående. Använd Proxmox GUI eller qm för att hålla virtualiserings- och lagringsoperationerna synkroniserade.

Aldrig köra zpool destroy utan att verifiera beroenden

ZFS utför destruktiva operationer utan varningar

ZFS ger kraftfulla lagringsalternativ, men destruktiva kommandon kan ge oväntade konsekvenser.

Att köra zpool destroy är ett exempel; att förstöra en pool tar bort lagringsgrunden under varje dataset och zvol i poolen. Om poolen används för Proxmox-lagring kan det få allvarliga följder för virtuella maskiner och containrar.

Innan du rör en pool, granska den noga med ZFS-verktyg. Kolla hur Proxmox nyttjar den: lagringskonfiguration, VM-diskar, containerrotfilsystem, datasets, zvols, snapshots och backup-lokationer. Det som verkar överflödigt från en ZFS-synvinkel kan fortfarande ha en roll i virtualiseringsmiljön.

Aldrig förstöra LVM-thin-volymer manuellt

LVM ser volymer som Proxmox hanterar som virtuella diskar

LVM-thin-lagring minskar risken för oavsiktliga fel genom att logiska volymer enkelt går att inspektera via kommandoraden. Kommandon som lvs och lvdisplay visar lagringsobjekten men inte hur Proxmox nyttjar dem.

En thin-volym kan representera en virtuell disk för en VM. Att ta bort den direkt med LVM resulterar i en VM-konfiguration med referenser till en saknad lagringsvolym. Det motsatta kan också skapa förvirring när gamla lagringsobjekt finns kvar efter att resurser tagits bort.

För vanliga VM-livscykeloperationer, låt Proxmox hantera lagringsoperationer. GUI och qm förstår att den virtuella disken är en del av en större VM-konfiguration och uppdaterar statusen i enlighet med det.

Aldrig omdesigna Corosync-nätverk slarvigt

Klustermeddelande förtjänar medveten nätverksplanering

Corosync ansvarar för kommunikationen mellan Proxmox-klusternoder, inklusive data för klustermedlemskap och majoritet. Dess nätverksväg är avgörande, betydligt mer än en vanlig tjänstekoppling.

Ett kluster kan verka friskt medan Corosync-nätverket fungerar optimalt, men problem kan snabbt uppstå efter en switchbyte, en förändring av gränssnitt eller VLAN-omkonfigurering.

En opålitlig Corosync-väg kan leda till att noder försvinner från klustret, påverkar majoriteten, stör migrationer och förhindrar förväntade hanteringsoperationer. Dessa problem kan framstå som Proxmox-specifika, men härstammar från kommunikationslagret. Behandla Corosync-nätverket som infrastruktur och överväg latens och fel-scenarier innan du gör ändringar.

Aldrig köra en tvånoderkluster utan att förstå majoritet

Två noder skapar ett obekvämt fel-scenario

Två-noderskluster frestar i homelabs, men att köra två är betydligt enklare än tre fysiska servrar. Utmaningen ligger i att ett distribuerat system behöver en pålitlig metod för att avgöra vilkas medlemmar som ingår i klustret vid kommunikationsfel.

Tänk på två Proxmox-noder som inte kan kommunicera. Den ena kan ha kraschat medan den andra är intakt. Båda kan se normala ut medan en switch mellan dem har misslyckats. Ur varje isolerad nods perspektiv verkar dessa situationer liknande.

Majoritet finns för att förhindra att båda sidor agerar som om de har kontroll över klustret. En överlevande nod kan begränsas efter att ha förlorat kontakten med en annan. En QDevice kan ge en ytterligare röst i lämpliga tvånoder-designs, vilket ger klustret en extra mekanism för att fastställa majoritet.

Aldrig installera Docker och slumpmässig infra-programvara på hypervisorn

Proxmox-värden bör förbli fokuserad på infrastruktur

Det finns alltid frestande skäl att installera en annan tjänst direkt på Proxmox-värden—en övervakningsagent, en Docker-behållare eller en liten webbservice. Men med tiden ackumuleras programvara som kan påverka nätverk, brandväggar, lagring, systemtjänster eller kärnkomponenter. Varje arbetslast ökar risken för störningar i plattformen som hanterar dina faktiska arbetslaster.

Docker är särskilt populärt i homelabs. Administratörer uppskattar bekvämligheten, men att köra applikationsbehållare i en dedikerad VM eller behållare separerar dessa arbetslaster från hypervisorns ansvar och förenklar underhållet.

Aldrig ändra Proxmox-nätverk på distans utan utanför-bandet tillgång

En nätverksfel kan ta bort den enda väg du har för att fixa det

Proxmox ger omfattande möjligheter för nätverkskonfiguration. Med Linux-bryggor, VLAN, flera fysiska gränssnitt och mer kan du skapa avancerade virtuella nätverk utan behov av extra hårdvara.

En felaktig bryggkonfiguration, otydliga gränssnittsnamn, VLAN-inställningar, gateways, adresser eller bond-konfigurationer kan göra Proxmox-värden otillgänglig direkt efter att nätverkstjänsten laddats om. Är du fysiskt närvarande kan du ofta åtgärda felet, men om servern finns på annan plats och din enda tillgång är via SSH eller webbgränssnittet, blir lösningen mycket svårare.

Innan du genomför större nätverksändringar:

Om du arbetar på distans, säkerställ att du har en alternativ åtkomstväg. IPMI, serieportkonsol eller fysisk konsol kan ge dig nödvändig kontakt med maskinen om nätverkskonfigurationen går fel.

Den säkraste Proxmox-inställningen är att respektera lagren

De flesta allvarliga Proxmox-misstag orsakas inte av sällsynta kommandon eller buggar. De uppstår ofta efter en åtgärd som tycks rimlig, eftersom administratören bara fokuserar på ett lager. Proxmox erbjuder kraftfulla verktyg för att hantera den komplexitet som finns. Bästa resultat får du genom att använda dessa verktyg med insikt om de underliggande systemen, istället för att gång på gång kringgå dem för enklare Linux-kommandon.

Nu när du har läst klart 8 saker du aldrig bör göra i Proxmox (om du inte vill att ditt homelab ska krasch), inbjuder vi dig att utforska kategorin Linux ytterligare. Där hittar du fler intressanta artiklar som kommer att utöka dina kunskaper och hålla dig informerad. Sluta inte läsa och upptäcka mer!