[Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

Mercredi · 16-04-2017 17:39:43

Bonjour,
J'essaye de mettre en place un dossier partagé entre une machine virtuelle et son hôte via les outils lib-virt.

La VM est générée avec Virt-manager, elle contient un serveur sous Debian Stretch.
En suivant cette doc : http://www.linux-kvm.org/page/9p_virtio : je parviens à créer le dossier de partage (en Mapped) et à le monter + y accéder sans souci depuis la VM mais seul Root peut écrire dans le dossier de l'hôte (un fichier ou dossier créer par Root depuis la Vm dans apparaît sur l'hôte avec Libvirt-qemu comme propriétaire).

Je coince sur les droits pour que l'utilisateur www-data de la VM puisse écrire dans le dossier situé sur l'hôte (à la place de Root donc).
Un lien symbolique depuis /var/www/html (sur la VM) qui renvoie vers les fichiers d'une appli web (sur l'hôte) fonctionne, le site est bien visible dans le navigateur mais avec des problèmes de droits pour créer des fichiers (pour une installation par exemple).

Les différentes options (Mapped - Passthrough - Squash) tentées n'y change rien.
Mettre le dossier sur l'hôte en plein accès lecture/écriture non plus.

J'ai aussi tenté d'ajouter rw à la commande pour monter le partage dans la VM comme suggéré ici : http://troglobit.github.io/blog/2013/07 … h-libvirt/ mais toujours sans succès.
Sur ce tuto, il est aussi dit de «chowner» le 9p file system à son utilisateur sur l'hôte mais je ne comprend pas à quoi correspond "jocke" dans la commande :

Please note that 9P file systems simply pass-through the owner UID/GID and directory permissions from the host to the guest. This can be a bit confusing, but just make sure to use the same for all guests that share the same directory. I chowned it to my account on the host:
host# chown jocke:users /var/lib/libvirt/share

Le but de la manœuvre (au cas où ça puisse aider à comprendre ce que je veux faire) :
Avoir un serveur local dans un machine virtuelle (en stable pendant que l'hôte est en Testing) pour y faire tourner entre autre l'ERP Dolibarr qui me sert à des fins professionnelles tout en ayant les fichiers de Dolibarr sur mon disque dur (dans le dossier partagé situé sur mon /home/utilisateur) et pas dans un fichier image Qcow2, ceci pour faciliter la sauvegarde de ces données vitales et pouvoir les remonter facilement sur un autre pc qui ne supporte pas la virtualisation en cas de gros plantage et d'urgence - parce que quand ça plante, c'est toujours quand il ne faut pas .

Dernière modification par Mercredi (30-04-2017 18:11:59)

kyodev · 18-04-2017 00:47:15

bonsoir

j'ai survolé rapidement.

joke correspond au propriétaire (uid), groupe user (gui), comme c'est un système traversant (pass-through), cet utilisateur doit exister tel quel des 2 côtés. Dans ton cas, tu pourrais remplacer joke par mercredi par exmple. mais il faut que le compte existe aussi dans la VM. Ou utiliser/créer un groupe www-data des 2 côtés (par exemple: mercredi:www-data). ce groupe doit exister dans la VM j'imagine.

attention, dans le tuto

Mode: change to Mapped This is the most important step in this blog, or you will not get read/write support!

il est bien dit de choisir mapped.

pour la manœuvre, j'ai pas tout compris, tu es sous stretch, et tu crées un serveur sous stretch dans la VM? (peut-être une erreur sur ta 3e ligne).

anonyme · 18-04-2017 01:51:16

https://fr.wikipedia.org/wiki/Hôte
https://fr.wikipedia.org/wiki/Hôte_(informatique)

l hôte est en "testing" Stretch
la VM en "stable" Jessie

je le comprend comme cela (bien qu'en général l hôte est en "stable" et la VM en "testing" .........

)

Mercredi · 18-04-2017 12:14:46

Bonjour,

Kyodev merci de m'avoir remis les yeux en face des trous : je ne sais pas pourquoi je cherchais compliqué avec ce "joke"

si il avait écrit user:group j'aurai capté tout de suite

une bonne blague joke au final, à moins que les anglophones utilisent joke comme nous on utilise toto.

J'ai bien choisi Mapped.
Mêmes utilisateurs pour hôte et VM.
Je viens d'essayer avec www-data:mercredi et même www-data:www-data (en redémarrant tout le bazar entre les 2 pour être sûre que ce soit bien pris en compte partout) mais www-data n'a toujours pas le droit de créer un fichier sur le dossier de l'hôte. J'ai aussi fait un chmod à 755 sur le dossier comme je le fais pour les dossiers/fichiers sur mon serveur local "normal" (c'est à dire pas virtualisé et "en prod").

Je viens de trouver ça : https://eklitzke.org/fedora-qemu-and-9p … assthrough je pense qu'il y a une piste, faut que je lise correctement et que je teste. Je vous redis quoi après.

Sinon pour clarifier l'installation :
Hôte = Testing Stretch mais qui deviendra Testing Buster après le dégel (sources.list avec Testing et non Strectch ... sais pas si je suis claire

)
VM = Testing Stretch qui restera Stretch après le dégel, c'est à dire Stable.
Cette VM est un test destiné à remplacer mon serveur local actuellement installé sur l'hôte parce qu'un serveur en Testing c'est moyen. Là ça va que Testing est quasi stable mais dans quelques mois ça risque d'être plus sportif

, en plus ça alourdi mon système un peu inutilement car je n'ai pas besoin du serveur en permanence.

kyodev · 18-04-2017 12:55:13

joke = blague, pas jocke

maintenant, je vois... la manœuvre, mais l'hôte rapidement en buster, ça peut être chaud, voir remarque anonyme.

je suis pas sûr de comprendre, quand tu dis www-data:mercredi, c'est user www-data, groupe mercredi??

amha, il faudrait que le groupe www-data existe de chaque côté, vérifier avec

cat /etc/group | grep www-data

et

chown -R mercredi:www-data /leDossierQui/vaBien

sur l'hôte. mercredi étant ajouté au groupe user, s'il n'y est pas encore

tu confonds pas chmod avec chown par hasard?
d'ailleurs il manque l'option -R (récursif) dans le premier tuto.

anonyme · 18-04-2017 13:53:49

pour buster ça va aller , je pense aussi rester en "testing" et "sid" pour les 4 machines trés récentes (matériel mal reconnu ) , le reste en "stretch".
par contre je saisi pas pour l hôte en testing et la VM en stretch .
si l hôte plante on perd la VM non ? ( j'aurai vu plutôt l'inverse )

kyodev · 18-04-2017 14:16:40

buster au dégel, ça risque d'être un peu "débâcle", pour une machine de production?

Mercredi · 18-04-2017 18:05:00

kyodev a écrit :

joke = blague, pas jocke
maintenant, je vois... la manœuvre, mais l'hôte rapidement en buster, ça peut être chaud, voir remarque anonyme.

je suis pas sûr de comprendre, quand tu dis www-data:mercredi, c'est user www-data, groupe mercredi??https://debian-facile.org/img/smilies/xtras/scratchhead.gif

amha, il faudrait que le groupe www-data existe de chaque côté, vérifier avec
cat /etc/group | grep www-data
et
chown -R mercredi:www-data /leDossierQui/vaBien
sur l'hôte. mercredi étant ajouté au groupe user, s'il n'y est pas encore

tu confonds pas chmod avec chown par hasard?
d'ailleurs il manque l'option -R (récursif) dans le premier tuto.

Oui jocke, écrit vite fait ce midi
www-data existe des 2 côtés, avec mon user ajouté au groupe ww-data également
Le -R récursif ajouté par habitude et le chmod -R 755 par habitude aussi (donne les droits lecture, écriture, exécution au proprio + lecture et exécution aux autres, pas besoin de restreindre plus en local).

kyodev a écrit :

buster au dégel, ça risque d'être un peu "débâcle", pour une machine de production?

Y'a un risque, j'ai ceinture, bretelles et parachute, soit une procédure de sauvegarde drastique et bien rodée avec de temps à autre un test de restauration des choses critiques sur ma machine de secours (pour vérifier que la procédure est toujours fonctionnelle).
Qu'est-ce qu'on ne ferait pas pour ne pas avoir 3 Gnomes de retard et profiter des dernières avancées Wayland (et non je ne veux pas changer de distrib)

anonyme a écrit :

pour buster ça va aller , je pense aussi rester en "testing" et "sid" pour les 4 machines trés récentes (matériel mal reconnu ) , le reste en "stretch".
par contre je saisi pas pour l hôte en testing et la VM en stretch .
si l hôte plante on perd la VM non ? ( j'aurai vu plutôt l'inverse )

La VM c'est juste pour la partie serveur.
J'ai un /home séparé et ma VM est stockée dedans
Le dossier partagé dans le /home aussi (comme ça juste le /home à sauvegarder)

J'ai noté à mesure mes essais, si ça peut aider à comprendre (et puis ça peut être intéressant ensuite de recopier tout ça dans un wiki perso quand ça fonctionnera) :

Partage d'un dossier avec le système Plan9 : l'utilisateur doit être identique entre hôte et invité
Éteindre la vm
Afficher les détails et ajouter un nouveau matériel : choisir système de fichiers
Pilote = default, mode = Mapped
chemin source : dossier sur hôte /home/il/vmpart
chemin cible : un nom au choix, par exemple = partagehote

Droits écriture - utilisateur - groupe du dossier :
Sur hôte
chmod -R 755 /home/il/vmpart
chown -R www-data.www-data /home/il/vmpart

Démarrer la vm
Créer un dossier où monter le partage sur l'invité, exemple /var/www/html/mnt et lui donner l'utilisateur www-data
En root (toujours sur invité) lancer la commande :
mount -t 9p -o trans=virtio,version=9p2000.L,rw /partagehote /var/www/html/mnt

Test fonctionnement :
Archive Dolibarr dézipée dans le dossier vmpart de l'hôte
Partage monté dans la VM -> accès ok, www-data est propirétaire des dossiers et fichiers avec les droits de création et suppression, lecture et écriture partout.
Ouverture du navigateur de l'hôte avec l'url ipdelavm/mnt/ -> tout est là
Je lance la procedure d'installation de Dolibarr, ça roule au début et ça merdoie à la création du fichier de configuration : pas le droit de le créer.
Vous devez créer un fichier htdocs/conf/conf.php et donner les droits d'écriture dans celui-ci au serveur web durant le processus d'installation.

Vérification du dossier où le fichier de conf doit se créer : /var/www/html/mnt/dolibarr/htdocs/conf propiétaire www-data, droit de création suppression, etc ...

Sur hôte et invité www-data à les mêmes n° uid gid groupes : 33 donc le souci n'est pas là. (id www-data)
Qu'à cela ne tienne, je crée le fichier à la main et je donne les droits - propriété à www-data -> recharge la page du navigateur -> ok

Je continue la procédure d'installation ça coince encore à la création d'un répertoire -> Je le crée à la main avec les bons droits
Je recharge la page :
Le répertoire n'existe pas ou n'est pas accessible. Vous devez créer ce dossier et permettre au serveur web d'écrire dans celui-ci. Chemin, orthographe, droits, etc vérifiés et corrects.

Test avec le cms Dotclear :
Erreurs :
Impossible d'écrire le fichier /var/www/html/mnt/dotclear/admin/install/../../inc/config.php.

Meuharghhh ! je pense qu'il y a bien un souci de droits avec www-data côté VM mais je n'identifie pas quoi.

Ps une installation de Dolibarr ou Dotclear sur un serveur “classique” avec des droits et permissions identiques données à www-data se passe les doigts dans le nez.

Testé aussi de préciser l'utilisateur www-data dans le fichier qemu.conf comme expliqué dans le lien donné plus haut même si sur Debian ce n'est pas configuré pareil que sur Fedora, sans succès.
Note mon user fait aussi partie du groupe libvirt, je ne sais pas si ça peut interférer.

Ps : mon vrai user c'est "il" pas "mercredi", juste pour éviter que vous grattiez la tête

Mercredi · 18-04-2017 22:15:16

Suite des tests :
Si je fais un chmod -R 777 sur le répertoire -> tout fonctionne (mais même si ça reste en local c'est pas super zoli le 777).

J'ai pas mal fouillé sur le oueb aussi et j'ai trouvé ça intéressant : http://rabexc.org/posts/p9-setup-in-libvirt

Don't forget that at the end of the day a Virtual Machine is just another process on your host operating system. This process is running with the privileges of a particular user, and only able to change and touch the files that the specific user is given access to.

If you run ps aux |grep kvm or ps aux |grep qemu on your host system, you will most likely see that a system VM is running as user libvirt-qemu on Debian, while it is running as yourself if it is a session VM. If you are confused about system or session VMs, you should read this article.

This means that kvm/qemu will be able to read or write files or directories either as you, or as the libvirt-qemu user. Make sure that file privileges and directories are set accordingly.

Entre l'anglais et mes notions de droits/utilisateurs qui sont limites je n'ai pas encore bien tout saisi (ça ira sûrement mieux demain matin avec un neurone reposé )
En attendant j'ai fait un test :
Depuis la VM j'ai créé un fichier bidule.php dans /var/www/html/mnt avec un chown www-data.www-data (vu qu'avec le full 777 je peux )
Dans le répertoire "relié" sur l'hôte, le même fichier appartient à ... roulements de tambours ... Libvirt Qemu

Je poursuivrai les tests demain, là je vais répondre à l'appel de la couette

kyodev · 18-04-2017 22:25:34

lu rapidement, mais ce passage dois te concerner

This means that kvm/qemu will be able to read or write files or directories either as you, or as the libvirt-qemu user. Make sure that file privileges and directories are set accordingly.
To change the uid under which system VMs are run, you need to:
edit /etc/libvirt/qemu.conf
modify the parameters user and group to have the desired value.

avec il:www-data, par exemple?
ce que je supputais, tu as plusieurs users (quemu) & www-data (serveur), d'où le fait de mettre les permissions à all débloque le smillblick.

Mercredi · 20-04-2017 12:17:37

Juste pour tenir au jus : tout un tas d'essais avec tous les users/groupes possibles et un chmod à 775 pour que le groupe ait les mêmes droit que l'user mais

ça veut pas encore.
Ce week-end je regarderais les fichiers de conf plus en détail, voir si y'a pas un truc autre que ceux déjà tentés.

Mercredi · 23-04-2017 20:57:53

Bonsoir,
Y'a un peu de progrès :
En faisant un chown libvirt-qemu.mon user + mode squash au lieu de mapped, la création du fichiers de conf de dolibarr est possible, par contre ça bloque sur la suite car ce fichier n'est pas modifiable.
Sur Dotclear l'installation se passe bien mais ensuite le serveur ne peut pas écrire dan le dossier "cache" ... donc encore des problème de droits quelque part.

D'après différentes lectures sur le oueb, le fait d'utiliser Virt-manager avec mon user au lieu de root pourrait être la source de tous ces tracas. Je vais poursuivre les tests ... je l'aurai non mais

Edit à toto :
Utilisation des balises commande du forum :

chown libvirt-qemu.mon user

Voir par Modifier au bas de ce post comment que c'est écrit pour être si joli à lire pour tout le monde...

Mercredi · 28-04-2017 15:58:46

Bonjour,
Testé d'utiliser Virt-manager en tant que root (comme c'est par défaut sous Debian), ça solutionne presque tout en choisissant le mode Mapped + pilot path.
Presque car c'est dans l'autre sens que j'ai des soucis de droit, mon utilisateur n'a pas accès aux nouveaux fichiers créés via l'interface web de Dolibarr : ces fichiers sont propriété de Libvirt-qemu avec groupe libvirt-qemu.

J'ai tenté de déployer les droits/propriétés de différentes façons mais ça veut pas

.
/me jette l'éponge au profit d'un partage moins pratique mais plus classique

Mercredi · 30-04-2017 18:11:40

Bonjour,
J'ai ramassé mon éponge

et j'ai réussi à tout faire fonctionner

En gros y'a un truc qui m'a fait tilt : sur certains tutos il était question de mettre utilisateur groupe à toto:users. Et si users était un vrai groupe plutôt qu'a le remplacer par libvirt ou www-data ou autre ?
Et bien oui, il existe un groupe users sur Debian. Et dans ce groupe on peut bien évidemment y mettre tous les users qu'on veut.
Donc :

chown -R 775 monuser:users /mon-repertoire-partage

chmod -R 775 /mon-repertoire-partage

Sur l'invité ajout de mon user et de www-data au groupe users
Cette action m'a levé le problème de création et d'écriture du fichier de conf de Dolibarr et permet d'utiliser Virt-manager en simple utilisateur.

Reste le problème que les fichiers créés par le serveur sur la VM appartiennent à libvirt-qemu et groupe libvirt-qemu en lecture seule (sans possibilité de modifier les fichiers en ajoutant mon user au groupe libvirt-qemu donc).
Autre révélation : lorsque on modifie le fichier qemu.conf fermer et rouvrir Virt-manager ne suffit pas. Il faut stopper et redémarrer les processus libvirt pour que le changement soit prit en compte. Dans ce fichier j'ai modifié user=monuser et groupe=users.

Il faut que je refasse un essai en partant sur une base propre pour voir ce qui est strictement nécessaire car à force de faire des tests en tous sens il y a du superflu qui s'incruste, par exemple j'ai un doute sur la nécessité d'ajouter libvirt-qemu au groupe users.

Bref je fais un topo plus tard sur «the final bonne procédure» pour les futurs lecteurs que ça intéressera.

Mercredi · 05-05-2017 15:51:39

Bonjour,
Ayé j'ai démélé mon sac de nœuds, finalement c'était pas compliqué, fallait juste pas oublier l'essentiel

/me m'aurait mis des baffes quand j'ai compris

Donc pour que ça marche avec un serveur (Apache) il faut :

Côté VM :
- La créer avec le même utilisateur que celui de l'hôte et ajouter www-data au groupe de l'utilisateur.
- À la création du partage, choisir pilote = default mode = mapped.
- Le répértoire de la VM qui sert de point de montage doit appartenir au Grand Manitou Apache www-data (propriétaire et groupe).

Côté hôte :
- L'utilisateur est ajouté au groupe libvirt (évite d'avoir à donner le mot de passe root lorsqu'on lance Virt-manager).
- Dans le fichier /etc/libvirt/qemu.conf chercher les lignes user et groupe, les dé-commenter et inscrire son utilisateur (user=moi group=moi).
Ne pas oublier de redémarrer le service pour que le fichier soit pris en compte (si j'y avais pensé je n'aurais point tant tourné en rond

) avec la commande :

systemctl restart libvirtd

- Le répertoire qui accueille les données partagées doit appartenir à l'utilisateur (propriétaire et groupe), très important le groupe doit avoir les droits d'écriture (chmod 775), rapport à www-data qui fait parti du groupe de l'utilisateur côté VM.

Ouf it works !

Debian-facile

#1 16-04-2017 17:39:43

[Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#2 18-04-2017 00:47:15

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#3 18-04-2017 01:51:16

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#4 18-04-2017 12:14:46

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#5 18-04-2017 12:55:13

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#6 18-04-2017 13:53:49

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#7 18-04-2017 14:16:40

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#8 18-04-2017 18:05:00

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#9 18-04-2017 22:15:16

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#10 18-04-2017 22:25:34

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#11 20-04-2017 12:17:37

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#12 23-04-2017 20:57:53

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#13 28-04-2017 15:58:46

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#14 30-04-2017 18:11:40

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

#15 05-05-2017 15:51:39

Re : [Résolu] partage 9p entre hôte et machine virtuelle kvm Virt-mananger

Pied de page des forums