Faire entrer un fichier dans une machine virtuelle, quand Proxmox n'a pas de gestionnaire de fichiers

Vous avez un fichier sur votre propre ordinateur et il doit se retrouver dans un invité. Vous cherchez dans l'interface un bouton d'envoi allant dans cette direction, et il n'y en a pas.

Cette absence est un choix de conception et non un oubli, et en comprendre la raison rend tout le reste évident. Proxmox VE gère la machine, pas l'intérieur de la machine. Vu de l'extérieur, le stockage d'un invité est une image disque : un gros bloc opaque. La couche de virtualisation ne lit pas le système de fichiers qu'il contient, et c'est précisément pour cela qu'elle peut héberger n'importe quel système d'exploitation sans rien en savoir.

Chaque chemin d'entrée est donc une façon de franchir cette frontière volontairement, et chacun la franchit autrement.

La réponse ennuyeuse, généralement la bonne

Copiez par le réseau, exactement comme vers n'importe quelle autre machine. Une copie de fichier par SSH, un partage de fichiers, un stockage objet, un téléchargement depuis l'intérieur de l'invité.

Ce chemin est étonnamment souvent écarté parce qu'il paraît trop ordinaire, comme si la virtualisation devait offrir mieux. Ce n'est pas le cas, et ce ne devrait pas l'être. L'invité est une machine de votre réseau ; traitez-le comme telle. Ce chemin encaisse n'importe quelle taille, conserve ses propres permissions et n'implique pas du tout la couche de virtualisation.

Les cas ci-dessous concernent les situations où ce chemin n'est pas disponible.

Quand l'invité est injoignable mais en marche

L'agent invité vous donne un canal qui n'utilise pas le réseau, car il passe par un périphérique virtuel entre l'hôte et l'invité.

Il sait réellement lire et écrire des fichiers. Les deux opérations existent comme points d'accès distincts, et c'est exactement ce qu'il faut pour déposer un fichier de configuration ou une clé dans une machine qui a perdu son réseau.

La limite à connaître avant de compter dessus : une écriture unique est plafonnée à environ 60 Ko, et la lecture de fichiers plus gros revient marquée comme tronquée. Ce canal a été construit pour les petites choses. Excellent pour un fichier de configuration, inutile pour une image d'installation, et le découvrir en plein incident est pire que le lire ici.

Sur l'hôte ayant servi à vérifier ceci, sept machines virtuelles sur huit avaient l'agent activé, donc pour la plupart des gens ce chemin est déjà disponible et simplement méconnu.

Quand l'invité est éteint

L'invité arrêté, son image disque peut être montée sur l'hôte et son système de fichiers parcouru directement. C'est l'option la plus puissante : accès complet, n'importe quelle taille, aucun agent requis.

C'est aussi celle qui a l'arête la plus tranchante de ce texte.

Le raccourci qui détruit en silence

Ne montez pas depuis l'hôte le système de fichiers d'un invité en marche.

Cela semble souvent fonctionner. Vous montez l'image, vous voyez les fichiers, vous en copiez un, rien ne proteste. Pendant ce temps l'invité a lui aussi ce système de fichiers monté et garde en cache sa propre idée de ce qui est sur le disque. Deux écrivains indépendants, un système de fichiers, aucun au courant de l'autre. Le résultat est une corruption qui apparaît plus tard et ressemble à un problème de disque plutôt qu'à quelque chose que vous avez fait.

Si l'invité tourne, passez par le réseau ou par l'agent. Si vous avez besoin du disque, arrêtez d'abord l'invité.

Quand l'invité ne démarre plus du tout

C'est le moment où vous voulez le plus faire sortir un fichier, et toutes les options précédentes ont échoué.

Passez par une sauvegarde. Les sauvegardes peuvent être inspectées et l'on peut en extraire des fichiers isolés sans restaurer tout l'invité. C'est plus lent que tout le reste ici, et c'est le seul chemin qui fonctionne encore quand la machine elle-même est inutilisable.

À noter : c'est une raison de plus pour laquelle une sauvegarde que vous n'avez jamais ouverte n'est pas encore une sauvegarde. Le jour où vous devez sortir un seul fichier d'une machine morte est un mauvais jour pour découvrir que l'archive ne se restaure pas.

Les conteneurs sont un autre problème

Un conteneur n'a pas d'image disque contenant un système de fichiers opaque. Ses fichiers reposent sur le stockage de l'hôte, donc depuis l'hôte ils sont simplement là.

Cette asymétrie explique pourquoi la version conteneur de cette question fait l'objet d'une recherche distincte. Même tâche, difficulté totalement différente, et un conseil écrit pour l'un est souvent faux pour l'autre.

Ce que fait Atlas, et ses limites

Atlas propose un explorateur de fichiers pour un invité, et le choix de conception qu'il contient est la partie qui mérite d'être dite.

Il tourne à l'intérieur de l'invité et n'écoute que sur l'adresse de bouclage de celui-ci, il n'est donc pas du tout joignable depuis votre réseau. Vous y accédez via Atlas. Autrement dit, ajouter un explorateur de fichiers n'ajoute pas un service exposé à tout le reste du réseau local, ce qui est d'ordinaire le coût silencieux d'un gestionnaire de fichiers web posé sur une machine.

Les limites, franchement : il fonctionne par invité et doit être présent dans celui que vous voulez parcourir ; c'est une commodité pour regarder et déplacer des fichiers isolés, pas un mécanisme de transfert de grandes données ; et il ne remplace pas les sauvegardes. Pour du volume, le chemin réseau ci-dessus reste la bonne réponse, et pour une machine qui ne démarre plus, la voie de la sauvegarde reste la seule.