Montage répertoire sur disque différent

Bonjour,

Système : Debian squeeze

J’ai un disque dur 80Go et un disque de stockage de 500 Go montés sur ma machine.
Sur le disque de 80Go tourne mon serveur web, et j’ai beaucoup d’images dessus…
Mon dossier images se situe dans /home/nom_site/public_html/images.

Dans mon arborescence, mon disque dur de stockage est monté comme suit : /stock

je voudrais en somme que le répertoire soit monté comme ça /home/nom_site/public_html/images, mais que ce dossier images soit réellement dans /stock.

Je ne gère pas trop le fstab et la commande mount… quelqu’un pourrait me donner la solution svp ?

Merci

Ouvre le fichier /etc/fstab, ce n’est pas vraiment compliqué à comprendre et tu apprendra bien mieux que si on te donnait une solution toute faite.

Sinon pourquoi s’embêter avec mount alors qu’un lien symbolique suffit ?

+1

Pour répondre à ton besoin, jette donc un œil à “ln -s” :023

Ouep, j’ai déjà testé le lien symbolique, ça fonctionne bien, mais j’ai un peu triché…

en fait, la base, c’est proxmox, et mon répertoire images est dans une VM sur le disque 1, tandis que /stock/ est dans le superviseur et monté sur le disque 2.
Donc le lien symbolique depuis le superviseur fonctionne, mais depuis la VM ça ne marche pas si je veux y coller un fichier dedans…

Alors la solution de dire : cherche… c’est pas cool du tout ! De la recherche j’en ai fait, mais là je sèche c’est pourquoi je demande une solution… Sinon je ne viendrais pas sur le support pour poser la question.

J’ai regardé des article en utilisant le NFS… Mais… S’il y a une solution sans passer par le NFS, je suis assez preneur.

Merci

[quote=“Colt22”]Ouep, j’ai déjà testé le lien symbolique, ça fonctionne bien, mais j’ai un peu triché…

en fait, la base, c’est proxmox, et mon répertoire images est dans une VM sur le disque 1, tandis que /stock/ est dans le superviseur et monté sur le disque 2.
Donc le lien symbolique depuis le superviseur fonctionne, mais depuis la VM ça ne marche pas si je veux y coller un fichier dedans…
[/quote]
Déjà avec le contexte on comprend un peu mieux la problématique.

[quote=“Colt22”]
Alors la solution de dire : cherche… c’est pas cool du tout ! De la recherche j’en ai fait, mais là je sèche c’est pourquoi je demande une solution… Sinon je ne viendrais pas sur le support pour poser la question.

J’ai regardé des article en utilisant le NFS… Mais… S’il y a une solution sans passer par le NFS, je suis assez preneur.

Merci[/quote]
Tu connais la métaphore du poisson et de l’apprentissage de la pêche ?
C’est un peu la même chose, là je te proposais de regarder le fichier et de revenir avec des questions précises. Là tu arrive avec “donnez moi la solution” pas très didactique tu admettras :wink:
Donc dis moi ce que tu ne comprends pas dans le fichier, où mieux ce que tu as tenté et je t’aiderais dans la résolution du problème :smiley:

ça fait des heures que je me casse la tête sur ce machin… Alors les théories desfois… Chuis pas un poisson rouge et j’apprends vite.
Alors vu que tu te donnes la peine de me répondre (même si je commence à virer chèvre,je vais tenter de te décrire ce que j’ai fait mais je te promets rien…

dans mon fstab,mes vm sur le disque 1
/dev/pve/data /var/lib/vz ext3 defaults 0 2

pour mon stock qui est sur le disque 2 :
/dev/pvz/stock /stock ext3 defaults 0 2

voilà pour les éléments du fstab

Ma VM se situe sur le disque 1 à cet emplacement (je vais jusque là ou je veux mettre mon répertoire) :
/var/lib/vz/private/100/home/tartempion/public_html/images (image étant le répertoire que je veux dans mon stock)

Je voudrais que le répertoire images soit dans /stock/images

Dans le fstab, j’ai donc essayé de rajouter celle ligne :
/stock/images /var/lib/vz/private/100/home/tartempion/public_html/images ext3 defaults 0 2

Ensuite j’ai créé mes répertoires d’un côté et de l’autre, en changeant le propriétaire et le groupe pour que le user puisse l’utiliser.

J’ai fait un mount /stock/images
Et ça me répond un truc bizarre dans le style que ce n’est pas un device valide, avec une histoire d’hyperblock. J’imagine qu’il faudrait que je crée une partition virtuelle ??? comme ça il l’aurait son device ???

Vu que je ne suis pas du tout calé en fastab et montage de machins… je pédale dans la choucroute ! D’autant plus que ça a déjà été galère de faire ces montages à partir de tutos sur le web… Le plus drôle dans tout ça (après coup) c’est que tu te rends compte qu’il te faut lire une dizaine de tutos pour arriver à un truc qui marche !!!
Minux, ça me passionne, mais il y a desfois, j’ai envie de foutre mon écran par la fenêtre, comme maintenant par exemple !
Et sérieux, je pense que si tu me donnes la solution avec des explications, personne ne t’en voudra… surtout pas moi !

Merci de ton implication en tout cas

Je n’arrive pas à démêler les /etc/fstab de l’un et de l’autre, le /var de l’un et de l’autre, les services courants sur la machine maître …
Ton exposé est trop confus pour que je m’y retrouve (il me faudrait un dessin…).
De ce que je comprends, tu cherches à faire partager les fichiers contenus en une machine virtuelle avec le système l’abritant ?

Fais abstraction du fait que la machine soit virtuelle et qu’elle se trouve stockée sur la machine maître.
Ce n’est pas un «disque différent» sur la même machine que tu cherches à mettre en commun.
Il ne s’agit pas de monter des périphériques,/dev n’est pas commun aux deux machines.
Il ne s’agit pas de «remonter» ailleurs. Avant de remonter, il faudrait avoir monté auparavant.
Aborder les machines comme des systèmes étanches, étrangers l’un à l’autre.
Comment ferait-on pour partager des fichiers entre deux systèmes ?
La voie habituelle, par le réseau : NFS, smb, sshfs …

Client/Serveur.
L’un offrira un service (NFS, smb, sshfs …) l’autre en sera client.
Les réglages du serveur et du client dépendent du service.
Installe et règle le service voulu sur la machine virtuelle. Le serveur mettra à diposition les fichiers auxquels il a accès.
Le client accèdera à ces fichiers définis.

Lorsque tu auras réussi à monter par le réseau, il sera temps de s’intéresser aux liens symboliques.

Je reprends…

Côté hardware : j’ai physiquement 4 disques, 2 de 80 Go et 2 de 500 Go, les 2x80 Go sont en raid soft 1, et les 2x500 Go aussi. Donc pour simplifier les choses, on va dire que j’ai un disque de 80Go et un disque de 500 Go.

Sur mon 80Go, il y a le superviseur + mes VM.
Sur mon 500Go, il y a le stockage des données et le snapshot.

Sur une de mes VM il y a un serveur web qui est situé à cet emplacement depuis l’hyperviseur : /var/lib/vz/private/100/home/tartempion/public_html
ou si je fais un vzctl enter 100, je me retrouve en / et le serveur est en /home/tartempion/public_html.

Dans ce ~/tartempion/public_html se trouve le répertoire images (environ 60Go), qui est très volumineux et qui me pose un problème de stockage (plus beaucoup de place sur mon raid 1 de 80 Go.

Ce que je voudrais, c’est que le dossier images se situe dans /stock/images qui lui est sur mon disque 500Go.

Pour les tentatives, la première exposée ci-dessus, n’a pas fonctionné. Donc ensuite :


1ère tentative :

J’ai créé un lien symbolique depuis /stock/images/ vers /var/lib/…/tartempion/public_html.
J’ai changé les droits de mes dossiers de façon à ce que images appartiennet à tartempion.

Résultat :
Connecté en root depuis mon hyperviseur, ça marche impeccable. Mais si je me connecte sur la VM, le bash me dit que le dossier est inexistant. Donc le problème est réglé, ça ne fonctionne pas avec les liens symboliques.


2ème tentative :

J’essaye la solution NFS.
précision : nfs-common est déjà installé, mais pas de répertoire /etc/exports

je fais un aptitude install nfs-kernel-server

Voici la fin du log à la fin de l’install :

Creating config file /etc/default/nfs-kernel-server with new version Starting NFS common utilities: statd. FATAL: Error inserting nfsd (/lib/modules/2.6.32-19-pve/kernel/fs/nfsd/nfsd.ko): Invalid module format Not starting NFS kernel daemon: no support in current kernel. ... (warning).

Je fais une uname -a :

J’en discute avec un copain, qui lui a installé les 2 (kernel-server et common), mais parcontre sa version est 2.6.32-18-pve.
J’en conclus donc qu’il y a un bug avec ma version et j’ai fait un aptitude purge nfs-kernel-server.

J’ai quand même activé le nfs dans le fichier de conf de ma VM, puis je l’ai redémarrée.

J’ai tenté un :

voici le message d’erreur qui a suivi :

mount: wrong fs type, bad option, bad superblock on mon_hyperviseur:/stock/images, missing codepage or helper program, or other error (for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program) In some cases useful info is found in syslog - try dmesg | tail or so

Voilà, j’en suis là…

Mon pote m’a dit qu’il me restait une solution : le bind mount.
C’est quoi ste bête ???

J’ai trouvé quelques tutos explicatifs sur bind mount, je vais essayer comme ça et je donnerai le soluce si ça fonctionne.
Si en attendant, quelqu’un arrive à me dépatouiller avec le nfs, que je comprenne, ce serait sympa ! Et encore plus sympa si j’avais le soluce avec bind mount :smiley: mais là je crois que je rêve…

Merci !


En KVM on manipule des disques virtuels cow ou autres types tels les disques virtuels *.vdi de virtualbox  ... pas des sous-dossiers qu'il serait possible de (re)monter en bind. La voie du réseau comme je te la suggérais serait préférable.
Reste openvz ... que je ne connais pas.
[quote]
OpenVZ is an Operating System-level server virtualization solution, built
on Linux. OpenVZ creates isolated, secure virtual private servers on a single
physical server enabling better server utilization and ensuring that
applications do not conflict. Each VPS performs and executes exactly like a
stand-alone server; VPSs can be rebooted independently and have root access,
users, IP addresses, memory, processes, files, applications, system libraries
and configuration files
... 
 You need a Linux kernel patched with openvz support.
[/quote]

Voilà qui explique l'échec des liens symboliques.
Les serveurs virtuels sous openvz sont relativement* étanches ([i]isolated, secure[/i] virtual [i]private[/i] servers, not conflict, stand alone, independently ...)
 Depuis les serveurs virtuels, les éléments externes ne sont pas accessibles.
Lorsque tu crées le lien symbolique vers /stock/images, cette adresse est hors d'atteinte du serveur virtuel. 
L'avantage du montage bind est qu'il ne fera pas référence à une adresse hors d'atteinte. Le montage bind mettra les fichiers à sa portée.

Commande 
# mount --bind /stock/images /var/lib/vz/private/100/home/tartempion/public_html

Dans la courte doc que j'ai consultée, je remarque ceci : 
[wiki.openvz.org/Mounting_filesystems](http://wiki.openvz.org/Mounting_filesystems)
[quote]
 Mounting filesystems

To mount a file system inside a container, you have several choices:

    NFS, when container as an NFS client
    FUSE (filesystem in userspace)
    Bind mounts from Hardware Node 

Also, you can grant a container an access a physical block device, and use that device from inside the container. Not all file systems are working inside a container; check /proc/filesystems inside a container to find out. 
[/quote]
Outre les déjà évoqués NFS, FUSE (sshfs), bind, il est fait mention de l'accès direct à un périphérique (grant a container an access a physical block device) sans en expliquer la méthode. Je pense que des indices de ce réglage devraient se trouver en /etc/vz/conf* ? À vérifier ...
/proc/filesystems :  affiche les systèmes de fichiers (/ext2ext3/ext4/jfs/xfs/btrfs/ufs/ntfs/hfs+ ...) gérés par le noyau. 

* relativement étanches : Je comparerais ça à chroot. Étanche entre serveurs virtuels, complètement transparent vis à vis du système maître.
Pour déplacer des données depuis /var/lib/vz/private/100/home/tartempion/public_html* vers /stock/images*, il serait plus facile d'opérer hors de tout semblant de chroot, depuis le système maître.

En KVM on manipule des disques virtuels cow ou autres types tels les disques virtuels *.vdi de virtualbox … pas des sous-dossiers qu’il serait possible de (re)monter en bind. La voie du réseau comme je te la suggérais serait préférable.
Reste openvz … que je ne connais pas.

Voilà qui explique l’échec des liens symboliques.
Les serveurs virtuels sous openvz sont relativement* étanches (isolated, secure virtual private servers, not conflict, stand alone, independently …)
Depuis les serveurs virtuels, les éléments externes ne sont pas accessibles.
Lorsque tu crées le lien symbolique vers /stock/images, cette adresse est hors d’atteinte du serveur virtuel.
L’avantage du montage bind est qu’il ne fera pas référence à une adresse hors d’atteinte. Le montage bind mettra les fichiers à sa portée.

Commande

mount --bind /stock/images /var/lib/vz/private/100/home/tartempion/public_html

Dans la courte doc que j’ai consultée, je remarque ceci :
wiki.openvz.org/Mounting_filesystems

Outre les déjà évoqués NFS, FUSE (sshfs), bind, il est fait mention de l’accès direct à un périphérique (grant a container an access a physical block device) sans en expliquer la méthode. Je pense que des indices de ce réglage devraient se trouver en /etc/vz/conf* ? À vérifier …
/proc/filesystems : affiche les systèmes de fichiers (/ext2ext3/ext4/jfs/xfs/btrfs/ufs/ntfs/hfs+ …) gérés par le noyau.

  • relativement étanches : Je comparerais ça à chroot. Étanche entre serveurs virtuels, complètement transparent vis à vis du système maître.
    Pour déplacer des données depuis /var/lib/vz/private/100/home/tartempion/public_html* vers /stock/images*, il serait plus facile d’opérer hors de tout semblant de chroot, depuis le système maître.

Merci pour tes explications…

J’avais déjà le lien que tu me proposais et même fabriqué le fichier CTID.mount. àpréciser que j’ai été obligé de le modifier car dans le fichier vz.conf, je n’ai pas de VE_CONFFILE présent donc j’ai indiqué le chemin de conf de ma VM pour être tranquille.

J’ai fait la commande que tu me proposais mais ça ne fonctionne quand même pas… à savoir

Quand je tape cette commande, dans le mtab j’ai ça qui sort :

Seulement, si je copie un fichier dans le /home/tartempion/images en user et connecté sur la VM, je ne vois rien apparaître dans le /stock/images

J’ai essayé de chmoder en 777, de chown avec le numéro de user le dossier… rien n’y fait…

Quant à /proc/filesystems, ça me renvoit un Bash : Permission denied alors que je suis en root lollll

Je vais donner mon fstab, le vz-conf, et le CTID.conf… Peut-être tu détecteras quelque chose d’anormal…

fstab :

/dev/md1 / ext3 errors=remount-ro 0 1 /dev/pve/data /var/lib/vz ext3 defaults 0 2 /dev/sda3 none swap defaults 0 0 /dev/sdb3 none swap defaults 0 0 /dev/pvf/vz /var/lib/vz/dump ext3 defaults 0 2 /dev/pvf/stock /stock ext3 defaults 0 2 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0

vz.conf :

[code]## Global parameters
VIRTUOZZO=yes
LOCKDIR=/var/lib/vz/lock
DUMPDIR=/var/lib/vz/dump
VE0CPUUNITS=1000

Logging parameters

LOGGING=yes
LOGFILE=/var/log/vzctl.log
LOG_LEVEL=0
VERBOSE=0

Disk quota parameters

DISK_QUOTA=yes
VZFASTBOOT=no

Disable module loading. If set, vz initscript does not load any modules.

#MODULES_DISABLED=yes

The name of the device whose IP address will be used as source IP for CT.

By default automatically assigned.

#VE_ROUTE_SRC_DEV=“eth0”

Controls which interfaces to send ARP requests and modify ARP tables on.

NEIGHBOUR_DEVS=detect

Fail if there is another machine in the network with the same IP

ERROR_ON_ARPFAIL=“no”

Template parameters

TEMPLATE=/var/lib/vz/template

Defaults for containers

VE_ROOT=/var/lib/vz/root/$VEID
VE_PRIVATE=/var/lib/vz/private/$VEID

Filesystem layout for new CTs: either simfs (default) or ploop

#VE_LAYOUT=ploop

Load vzwdog module

VZWDOG=“no”

IPv4 iptables kernel modules to be enabled in CTs by default

IPTABLES=“ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length”

IPv4 iptables kernel modules to be loaded by init.d/vz script

IPTABLES_MODULES="$IPTABLES"

Enable IPv6

IPV6=“yes”

IPv6 ip6tables kernel modules

IP6TABLES=“ip6_tables ip6table_filter ip6table_mangle ip6t_REJECT”
[/code]

le 100.conf :

[code]ONBOOT=“yes”

PHYSPAGES="0:4096000"
SWAPPAGES="0:1024000"
KMEMSIZE="7625244672:8388608000"
DCACHESIZE="3812622336:4194304000"
LOCKEDPAGES="2048000"
PRIVVMPAGES="unlimited"
SHMPAGES="unlimited"
NUMPROC="unlimited"
VMGUARPAGES="0:unlimited"
OOMGUARPAGES="0:unlimited"
NUMTCPSOCK="unlimited"
NUMFLOCK="unlimited"
NUMPTY="unlimited"
NUMSIGINFO="unlimited"
TCPSNDBUF="unlimited"
TCPRCVBUF="unlimited"
OTHERSOCKBUF="unlimited"
DGRAMRCVBUF="unlimited"
NUMOTHERSOCK="unlimited"
NUMFILE="unlimited"
NUMIPTENT=“unlimited”

Disk quota parameters (in form of softlimit:hardlimit)

DISKSPACE="41943040:46137344"
DISKINODES="8000000:8800000"
QUOTATIME="0"
QUOTAUGIDLIMIT=“0”

CPU fair scheduler parameter

CPUUNITS="1000"
CPUS="8"
HOSTNAME="web.mondomaine.com"
SEARCHDOMAIN="mondomaine.com"
NAMESERVER=“127.0.0.1 213.186.33.99"
IP_ADDRESS=“10.0.0.27"
VE_ROOT=”/var/lib/vz/root/$VEID"
VE_PRIVATE=”/var/lib/vz/private/100"
OSTEMPLATE="debian-6.0-standard_6.0-6_amd64.tar.gz"
FEATURES=“nfs:on”[/code]

J’aime apprendre des trucs, mais il y a desfois, quand on ne comprend pas le problème, c’est chiant !

Merci en tout cas !

Bon, j’ai finalement réussi ! Enfin… mais vla la grosse galère…

Ce que j’ai fait :

Sur une autre VM, j’ai installé nfs-kernel-server et nfs-common

j’ai modifié le fichier exports comme il se doit et fait un reload de nfs-kernel-server

Je suis allé sur l’autre vm, et j’ai retenté la commande mount -t nfs ip_VM:/home/tete_de_pioche/images /home/tartempion/images
Et bing, j’ai eu droit à un beau message d’erreur mount.nfs : requested NFS version or transport protocol is not supported.

J’ai eu la moutarde qui commençait à me monter au nez, alors j’ai laisser tomber un moment, pour boire un ptit café trankilou.

Je suis revenu devant ma bécane, et puis je me suis retenté l’installation sur l’hyperviseur, et là… Devinez quoi ? plus d’erreur FATALE… Va comprendre Charles…

J’ai donc modifié le fichier export comme suit :

/stock/image    IP_VM(rw,root_squash)

Puis un petit

# /etc/init.d/nfs-kernel-server reload

Je change le propriétaire de mon répertoire /stock/images en 1001:1001

Puis

# vzctl enter 100
# chown tartempion:tartempion /home/tartempion/public_html
# mount -t nfs ip_hyperviseur:/stock/images /home/tartempion/public_html/images

Et là…
Pas de réponse d’erreur du prompt (j’en reviens pas !)

Je fais un test, toujours sur ma VM

[code]

su tartempion

$ cd
$ cp fichier_volumineux public_html/images
$ logout

df -h -m[/code]

Et là j’en crois pas mes yeux… ça marche ! :041 Un ptit exit pour aller contrôler que le fichier est bien présent dans /stock/images… mais oui mais oui ! :033
Temps passé sur le problème : environ 15 heures à fouiner partout pour voir ce qui n’allait pas :smiley:

Si par hasard il y en a qui ont la même aventure que moi, j’ose espérer que ça marchera tout de suite chez eux !

Merci à vous pour votre aide ! ça m’a permis de comprendre des choses !

Parfait :023 comme quoi les voix de l’informatique sont impénétrable :mrgreen:

Merci d’avoir détaillé ta solution, ça servira surement à quelqu’un :smiley:

Je sais pas ! mais en tout cas c’est pratique en virtualisation cette démarche.

Puis je suis pour le principe du partage… C’est pas beau de faire de la rétention d’infos :018