Een bestand in een virtuele machine krijgen, als Proxmox geen bestandsbeheerder heeft

U hebt een bestand op uw eigen computer en het moet in een gast terechtkomen. U zoekt in de interface naar een uploadknop die die kant op wijst, en die is er niet.

Die afwezigheid is een ontwerpkeuze en geen verzuim, en wie de reden begrijpt, vindt de rest vanzelfsprekend. Proxmox VE beheert de machine, niet de binnenkant van de machine. Van buitenaf is de opslag van een gast een schijfimage: een grote ondoorzichtige klomp. De virtualisatielaag leest het bestandssysteem daarin niet, en juist daarom kan zij elk besturingssysteem huisvesten zonder er iets van te weten.

Elke weg naar binnen is dus een manier om die grens bewust over te steken, en elke weg steekt anders over.

Het saaie antwoord dat meestal het juiste is

Kopieer het over het netwerk, net zoals u naar elke andere machine zou doen. Een bestandskopie via SSH, een bestandsdeling, een objectopslag, een download vanuit de gast zelf.

Deze weg wordt verrassend vaak overgeslagen omdat hij te gewoon voelt, alsof virtualisatie iets beters zou moeten bieden. Dat doet zij niet, en dat hoort ook niet. De gast is een machine in uw netwerk; behandel hem zo. Deze weg verdraagt elke omvang, behoudt zijn eigen rechten en betrekt de virtualisatielaag er helemaal niet bij.

De gevallen hieronder gelden wanneer deze weg niet beschikbaar is.

Wanneer de gast onbereikbaar is maar wel draait

De gastagent geeft u een kanaal dat geen netwerk gebruikt, want het loopt via een virtueel apparaat tussen host en gast.

Hij kan werkelijk bestanden lezen en schrijven. Beide bewerkingen bestaan als eigen eindpunten, en dat is precies wat u nodig hebt om een configuratiebestand of een sleutel neer te zetten in een machine die haar netwerk kwijt is.

De grens die u moet kennen voordat u erop leunt: één schrijfbewerking is begrensd op ongeveer 60 KB, en het lezen van grotere bestanden komt terug met de aanduiding afgekapt. Dit kanaal is voor kleine dingen gebouwd. Uitstekend voor een configuratiebestand, nutteloos voor een installatie-image, en dat middenin een storing ontdekken is erger dan het hier lezen.

Op de host waarmee dit is gecontroleerd hadden zeven van de acht virtuele machines de agent ingeschakeld, dus voor de meeste mensen is deze weg al beschikbaar en simpelweg onbekend.

Wanneer de gast uit staat

Met de gast gestopt kan zijn schijfimage op de host worden aangekoppeld en het bestandssysteem rechtstreeks worden doorgenomen. Dat is de krachtigste optie: volledige toegang, elke omvang, geen agent nodig.

Hij heeft ook de scherpste rand van dit stuk.

De kortere weg die stilletjes vernielt

Koppel het bestandssysteem van een draaiende gast niet vanaf de host aan.

Het lijkt vaak te werken. U koppelt de image aan, u ziet bestanden, u kopieert er een naar binnen, niets klaagt. Ondertussen heeft de gast dat bestandssysteem óók aangekoppeld en bewaart hij zijn eigen beeld van wat er op schijf staat in het geheugen. Twee onafhankelijke schrijvers, één bestandssysteem, geen van beide op de hoogte van de ander. Het resultaat is beschadiging die later opduikt en eruitziet als een schijfprobleem in plaats van als iets wat u hebt gedaan.

Draait de gast, gebruik dan het netwerk of de agent. Hebt u de schijf nodig, stop dan eerst de gast.

Wanneer de gast helemaal niet meer opstart

Dit is het moment waarop u het liefst een bestand naar buiten wilt, en alle vorige mogelijkheden zijn mislukt.

Neem de route via een back-up. Back-ups kunnen worden bekeken en losse bestanden eruit gehaald zonder de hele gast terug te zetten. Het is trager dan al het andere hier, en het is de enige weg die nog werkt wanneer de machine zelf onbruikbaar is.

Het opmerken waard: dit is nog een reden waarom een back-up die u nooit hebt geopend nog geen back-up is. De dag dat u één bestand uit een dode machine nodig hebt, is een slechte dag om te ontdekken dat het archief niet terugzet.

Containers zijn een ander probleem

Een container heeft geen schijfimage met daarin een ondoorzichtig bestandssysteem. Zijn bestanden staan op de opslag van de host zelf, dus vanaf de host zijn ze er gewoon.

Die scheefheid verklaart waarom de containerversie van deze vraag een eigen zoekopdracht is. Dezelfde taak, volstrekt andere moeilijkheid, en advies geschreven voor de een is vaak fout voor de ander.

Wat Atlas doet, en de grenzen ervan

Atlas biedt een bestandsverkenner voor een gast, en de ontwerpkeuze daarin is het deel dat het zeggen waard is.

Hij draait in de gast en luistert alleen op het loopbackadres van die gast, dus vanaf uw netwerk is hij helemaal niet bereikbaar. U komt erbij via Atlas. Dat betekent dat een bestandsverkenner toevoegen geen dienst toevoegt die openstaat voor al het andere op het lokale netwerk, en dat is normaal juist de stille prijs van een webbestandsbeheerder op een machine.

De grenzen, ronduit: hij werkt per gast en moet aanwezig zijn in de gast die u wilt doorzoeken; hij is een gemak om losse bestanden te bekijken en te verplaatsen, geen overdrachtsmechanisme voor grote hoeveelheden; en hij vervangt back-ups niet. Voor volume blijft de netwerkweg hierboven het juiste antwoord, en voor een machine die niet opstart blijft de back-uproute de enige.