Far entrare un file in una macchina virtuale, quando Proxmox non ha un gestore di file

Avete un file sul vostro computer e deve finire dentro un ospite. Cercate nell'interfaccia un pulsante di caricamento rivolto in quella direzione, e non c'è.

Quell'assenza è una scelta progettuale, non una dimenticanza, e capirne il motivo rende ovvio tutto il resto. Proxmox VE gestisce la macchina, non l'interno della macchina. Da fuori, lo spazio di un ospite è un'immagine disco: un grosso blocco opaco. Lo strato di virtualizzazione non legge il filesystem che contiene, ed è proprio per questo che può ospitare qualunque sistema operativo senza saperne nulla.

Quindi ogni via d'ingresso è un modo di attraversare quel confine di proposito, e ognuna lo attraversa diversamente.

La risposta noiosa, di solito quella giusta

Copiate via rete, esattamente come fareste verso qualunque altra macchina. Una copia di file su SSH, una condivisione, uno spazio a oggetti, uno scaricamento dall'interno dell'ospite.

Questa via viene scartata sorprendentemente spesso perché sembra troppo ordinaria, come se la virtualizzazione dovesse offrire qualcosa di meglio. Non lo fa, e non dovrebbe. L'ospite è una macchina sulla vostra rete; trattatelo come tale. Questa via regge qualsiasi dimensione, mantiene i propri permessi e non coinvolge affatto lo strato di virtualizzazione.

I casi qui sotto valgono per quando questa via non è disponibile.

Quando l'ospite è irraggiungibile ma acceso

L'agente ospite vi dà un canale che non usa la rete, perché passa da un dispositivo virtuale tra host e ospite.

Sa davvero leggere e scrivere file. Le due operazioni esistono come punti di accesso distinti, ed è esattamente ciò che serve per depositare un file di configurazione o una chiave in una macchina che ha perso la rete.

Il limite da conoscere prima di farci affidamento: una singola scrittura è limitata a circa 60 KB, e la lettura di file più grandi torna marcata come troncata. Questo canale è nato per le cose piccole. Ottimo per un file di configurazione, inutile per un'immagine di installazione, e scoprirlo durante un guasto è peggio che leggerlo qui.

Sull'host usato per verificare questo, sette macchine virtuali su otto avevano l'agente attivo, quindi per la maggior parte delle persone questa via è già disponibile e semplicemente sconosciuta.

Quando l'ospite è spento

Con l'ospite fermo, la sua immagine disco può essere montata sull'host e il filesystem esplorato direttamente. È l'opzione più potente: accesso completo, qualsiasi dimensione, nessun agente necessario.

Ha anche lo spigolo più tagliente di questo testo.

La scorciatoia che distrugge in silenzio

Non montate dall'host il filesystem di un ospite acceso.

Spesso sembra funzionare. Montate l'immagine, vedete i file, ne copiate uno dentro, nessuno protesta. Nel frattempo anche l'ospite ha quel filesystem montato e tiene in cache la propria idea di cosa c'è sul disco. Due scrittori indipendenti, un filesystem, nessuno dei due consapevole dell'altro. Il risultato è una corruzione che salta fuori dopo e sembra un problema di disco anziché qualcosa che avete fatto voi.

Se l'ospite è acceso, usate la rete o l'agente. Se vi serve il disco, prima fermate l'ospite.

Quando l'ospite non si avvia proprio

È il momento in cui più desiderate far uscire un file, e tutte le opzioni precedenti hanno fallito.

Passate da un backup. I backup si possono ispezionare e se ne possono estrarre singoli file senza ripristinare l'intero ospite. È più lento di tutto il resto qui, ed è l'unica via che funziona ancora quando la macchina stessa è inutilizzabile.

Da notare: questo è un altro motivo per cui un backup che non avete mai aperto non è ancora un backup. Il giorno in cui vi serve un singolo file da una macchina morta è un brutto giorno per scoprire che l'archivio non si ripristina.

I contenitori sono un altro problema

Un contenitore non ha un'immagine disco con dentro un filesystem opaco. I suoi file stanno sullo spazio dell'host, quindi dall'host ci sono semplicemente.

Quell'asimmetria spiega perché la versione per contenitori di questa domanda è una ricerca a sé. Stesso compito, difficoltà completamente diversa, e un consiglio scritto per l'uno spesso è sbagliato per l'altro.

Cosa fa Atlas, e i suoi limiti

Atlas offre un esplora file per un ospite, e la scelta progettuale al suo interno è la parte che vale la pena dire.

Gira dentro l'ospite e ascolta solo sull'indirizzo di loopback dell'ospite stesso, quindi dalla vostra rete non è raggiungibile affatto. Ci arrivate tramite Atlas. Significa che aggiungere un esplora file non aggiunge un servizio esposto a tutto il resto della rete locale, che è di solito il costo silenzioso di mettere un gestore file web su una macchina.

I limiti, detti chiaramente: funziona per singolo ospite e deve essere presente in quello che volete esplorare; è una comodità per guardare e spostare singoli file, non un meccanismo di trasferimento per grandi quantità di dati; e non sostituisce i backup. Per i volumi, la via di rete qui sopra resta la risposta giusta, e per una macchina che non si avvia, la strada del backup resta l'unica.