At få en fil ind i en virtuel maskine, når Proxmox ikke har en filhåndtering
Der findes ingen upload-knap, der peger ind i en gæst, og det fravær er tilsigtet og ikke en forglemmelse. Der er fire ægte veje ind, hver med sin pris, og en populær genvej, der stille ødelægger filsystemer.
AtlasPVE ·
Denne artikel besvarer
- proxmox kopiere fil til vm
- proxmox filhåndtering
- proxmox hente fil fra vm
- proxmox filstifinder
- proxmox copy file to vm
Du har en fil på din egen computer, og den skal ind i en gæst. Du leder i grænsefladen efter en upload-knap den vej, og den findes ikke.
Det fravær er en designbeslutning og ikke en forglemmelse, og forstår man grunden, bliver resten indlysende. Proxmox VE styrer maskinen, ikke maskinens indre. Udefra er en gæsts lager et diskbillede: en stor uigennemsigtig klump. Virtualiseringslaget læser ikke filsystemet indeni, og netop derfor kan det huse et hvilket som helst styresystem uden at vide noget om det.
Hver vej ind er altså en måde at krydse den grænse med vilje, og hver krydser den forskelligt.
Det kedelige svar, der som regel er det rigtige
Kopiér over netværket, præcis som du ville til enhver anden maskine. En filkopi over SSH, en fildeling, et objektlager, en download indefra gæsten.
Denne vej springes overraskende ofte over, fordi den føles for almindelig, som om virtualisering burde tilbyde noget bedre. Det gør den ikke, og det bør den ikke. Gæsten er en maskine på dit netværk; behandl den sådan. Vejen klarer enhver størrelse, bevarer sine egne rettigheder og inddrager slet ikke virtualiseringslaget.
Tilfældene nedenfor gælder, når denne vej ikke er til rådighed.
Når gæsten er uopnåelig, men kører
Gæsteagenten giver dig en kanal, der ikke bruger netværket, fordi den går via en virtuel enhed mellem vært og gæst.
Den kan faktisk læse og skrive filer. Begge handlinger findes som egne endepunkter, og det er præcis det, der skal til for at lægge en konfigurationsfil eller en nøgle ind i en maskine, der har mistet sit netværk.
Grænsen, der er værd at kende, før du læner dig op ad den: en enkelt skrivning er begrænset til omkring 60 KB, og læsning af større filer kommer tilbage mærket som afkortet. Kanalen blev bygget til små ting. Fremragende til en konfigurationsfil, ubrugelig til et installationsbillede, og at opdage det midt i en hændelse er værre end at læse det her.
På værten, der blev brugt til at tjekke dette, havde syv ud af otte virtuelle maskiner agenten slået til, så for de fleste er vejen allerede til rådighed og ganske enkelt ukendt.
Når gæsten er slukket
Med gæsten stoppet kan dens diskbillede monteres på værten og filsystemet gennemses direkte. Det er den stærkeste mulighed: fuld adgang, enhver størrelse, ingen agent nødvendig.
Den har også den skarpeste kant i denne tekst.
Genvejen, der ødelægger i stilhed
Montér ikke en kørende gæsts filsystem fra værten.
Det ser ofte ud til at virke. Du monterer billedet, du ser filer, du kopierer en ind, ingen brokker sig. Imens har gæsten også det filsystem monteret og holder sin egen forestilling om, hvad der ligger på disken, i mellemlageret. To uafhængige skrivere, ét filsystem, ingen af dem klar over den anden. Resultatet er ødelæggelse, der dukker op senere og ligner et diskproblem frem for noget, du gjorde.
Kører gæsten, så brug netværket eller agenten. Har du brug for disken, så stop gæsten først.
Når gæsten slet ikke starter
Det er øjeblikket, hvor du allerhelst vil have en fil ud, og alle de forrige muligheder er slået fejl.
Tag vejen om en sikkerhedskopi. Sikkerhedskopier kan gennemses, og enkelte filer kan hentes ud af dem uden at gendanne hele gæsten. Det er langsommere end alt andet her, og det er den eneste vej, der stadig virker, når selve maskinen er ubrugelig.
Værd at bemærke: det er endnu en grund til, at en sikkerhedskopi, du aldrig har åbnet, endnu ikke er en sikkerhedskopi. Den dag du har brug for en enkelt fil ud af en død maskine, er en dårlig dag at opdage, at arkivet ikke kan gendannes.
Beholdere er et andet problem
En beholder har ikke et diskbillede med et uigennemsigtigt filsystem indeni. Dens filer ligger på værtens eget lager, så fra værten er de der bare.
Den skævhed forklarer, hvorfor beholderudgaven af dette spørgsmål er en søgning for sig. Samme opgave, helt anden sværhedsgrad, og råd skrevet til det ene er ofte forkerte for det andet.
Hvad Atlas gør, og dets grænser
Atlas tilbyder en filstifinder til en gæst, og designvalget indeni er den del, der er værd at sige.
Den kører inde i gæsten og lytter kun på gæstens egen tilbageløbsadresse, så fra dit netværk er den slet ikke tilgængelig. Du når den gennem Atlas. Det betyder, at det at tilføje en filstifinder ikke tilføjer en tjeneste, der er åben mod alt andet på det lokale net, og det er ellers den stille pris ved at sætte en webbaseret filhåndtering på en maskine.
Grænserne, lige ud: den virker per gæst og skal være til stede i den gæst, du vil gennemse; den er en bekvemmelighed til at se på og flytte enkelte filer, ikke en overførselsmekanisme til store datamængder; og den erstatter ikke sikkerhedskopier. Til mængder er netværksvejen ovenfor stadig det rigtige svar, og til en maskine, der ikke starter, er vejen om sikkerhedskopien stadig den eneste.
Kilder
Proxmox’ egen dokumentation. På engelsk, og den har det sidste ord i dette spørgsmål.