Salut à tous,
 
Un problème que je rencontre et je suis débutant en Linux : comment agrandir la partition systeme d'un RedHat 5 virtuel ?
 
J'ai augmenté la taille de ma VM depuis vSphere Client pour passer de 80 Go à 160
Je redémarre ma VM
Je lance le Gestionnaire de Volume Logique et je vois mes 80 Go de bonus  
 

 
Comment faire en sorte que ma racine soit étendue ?
 

 
 
Attention : système virtuel, pas de redémarrage sur LiveCD
 
Merci pour votre aide ...

Tu ne peut pas redimensionner un volume en utilisation, déduis en se que tu veux, ma phrase est claire.
Edit : petit indice : trouver un moyen de démonter "/boot" et "/" en gardant ton système actif, faire le redimensionnement et remonter "/" puis "/boot"

 
 
c'est drôle mais ce que tu dis est exractement ce que je craignais  

Indice : vSphere te permet de booter un environnement "live"
Tu cherche franchement mal. http://vsphere-land.com/tips-trick [...] tual-disks

 
 
je vais suivre ton lien
 
merci à toi ...  

J'ai téléchargé Gparted Live
J'ai associé le cd-rom avec mon fichier ISO de Gparted (avec "périphérique vu au démarrage" )
J'ai étendu mon volume avec les 79 Go du départ au 80 Go de bonus depuis Gparted
J'ai désactivé l'image Iso pour le démarrage de ma VM
J'ai relancé ma VM
 
Depuis l'interface graphique et Gestionnaire de Volumes Logiques ...
 * Groupe de Volumes
 ** VolGroup00
 *** VolGroup00 Vue Physique
 
J'ai bien
=> taille du Groupe de Volume à 159.88 G
=> Espace disponible 80 G
 
Mon volume est donc vu avec les 159 Go affectés ... mais ...
 
 * Groupe de Volumes
 ** VolGroup00
 *** VolGroup00 Vue Physique
 **** /dev/sda
 ***** Partition 2 fait 79.88 G
 
Ma question : comment redimensionner ma partition avec tout le volume disponible (79.88 + 80.00) ?

Soit tu es rendu avec 3 partitions et c'est un "vgextend" dont tu as besoin.
Soit tu en as toujours deux et c'est un "pvresize".

Que disent "fdisk -l /dev/sda" et "vgs" ?

   
 
Merci à Benweb83 de prendre le relais ....

en mode console, depuis le gestionnaire de volume logique
 
Vue logique
clic sur le volume
editer
agrandissement au max
 
maintenant
 

Bon, la bonne procédure :
 
a)  

• téléchargement de Gparted en ISO et mise à disposition dans le répertoire des ISO de vSphere
• avertir les utilisateurs/administrateurs d'application, ... que l'on va éteindre leur machine, demander que tous les accès soient arrêtés

b)

• au top des utilisateurs/administrateurs d'application, ...
• depuis vSphère, sur la VM, faire "Modifier les paramètres"
• ajouter un cd-rom (si besoin)
• activer le "connecter lors de la mise sous tension"
• le connecter sur l'ISO de Gparted
• activer le démarrage console sur le Bios (onglet "options" )
• Augmenter l'espace disque

c)

• passer en mode console
• rebooter le serveur
• depuis le Bios activer le démarrage depuis le cd-rom

d)

• depuis Gparted, modifier la taille du disque avec tout l'espace alloué plus haut
• restart

e)

• lancement de la VM
• connexion en root
• accéder à l'outil de "Gestion de Volume Logique"
• Groupe de Volumes\VolGroup00\Volgroup00\Vue logique\ sélectionner le graphe du disque
• bouton "éditer les propriétés" (en bas de l'écran)
• déplacer le curseur du milieu de la fenêtre à fond sur la droite
• reboot

f)

• vérifier en mode console (df -h)
• vérifier en mode graphique (Gestion de Volume Logique)
• confirmer aux utilisateurs/administrateurs d'application, ... que c'est OK

temps : 1/4 d'heure

Travailler avec des outils sur la machine (gparted installé plutôt que depuis une ISO) permet de faire toute la procédure sans aucune interruption de service.

Ça fait belle lurette qu'on ne coupe plus les serveurs/applis pour un simple agrandissement de FS.

 
Non, pas dans le sens dans lequel tu dit. Gparted sur la machine comme tu l'entend ne fonctionnera pas : il faut démonter un volume/FS pour le modifier, fait le autrement et tu cours au désastre. Il est donc bien dans la bonne pratique, a ceci prêt qu'en principe tu monte un minecrokernel dans tes images pour ne pas avoir a monter un autre média, mais tu le fait quand même "a froid". C'est simple une modification a chaud peut planter ton SAN/NAS (désynchro infos logiques/physiques) si ton FS est un peu bancal ( il faut des FS spécifiques pour le faire a chaud).
 
Edit : prouve moi le contraire, sort moi un tuto et film si tu y arrive sans planter un système de prod, parce que tu va intéresser plein d'admins :>

@ Benweb83
 
Comme indiqué tout en haut, lors du premier post, c'est le disque système qui était à l'étroit et avait besoin de plus de place.
 
D'autre part, j'ai 93 VM sur mon environnement et je trouve quand même plus simple d'avoir une iso de la dernière version de Gparted à disposition que d'avoir à l'installer sur chaque VM ... et à devoir peut-être le mettre à jour ! Je mets à jour un fichier ISO plus facilement que je ne déploie une MAJ sur 93 VM !
 
C'est un outil que l'on utilise à titre assez exceptionnel et je ne trouve pas utile de l'installer pour l'utiliser quand il est possible de mettre la VM en off quelques minutes. Pour ce serveur, on a pris de la marge et on n'aura plus besoin de revenir dessus.
 
Maintenant, un admin newbe de Linux Red Hat sait comment procéder avec ce tuto.  

j'pige pas trop là  
 
a priori j'aurais fais un truc du style:
- augmentation de la taille du vmdk avec le client vsphere
- un echo "- - -" > "/sys/bus/scsi/devices/0:0:0:0/rescan" (adapter selon la vm)
- normalement à ce moment là, un "fdisk -l /dev/sda" montrera que la nouvelle taille du disque est bien prise en compte
- un "pvresize /dev/sda2" pour mettre à jour la taille du PV (voir le dev du PV avec "pvs"
- un "vgs" qui devrait nous donner la nouvelle taille de VolGroup00
- un "lvextend -l+100%FREE -r /dev/VolGroup00/LogVol00"
- on attend que ça s'fasse et un p'tite "df -h" pour finir de nous rasssurer.
 
tout ça à chaud non
 
edit: j'ai réfléchi trop vite en fait    
dans le cas présenté, faudrait créer une nouvelle partition, en faire un PV (pvcreate), le rajouter au VG (vgextend) , et ensuite étendre le LV (plus le FS). Ceci dit, ça se ferait toujours à chaud pour autant que je sache

 
Non, ça ne peut pas être fait a chaud, relit bien se qu'il a comme partitions.
En gros dans son volume logique, il n'a que "/" rien d'autre, donc les outils pour gérer le FS sont sur /, comment veux-tu respecter la géométrie/etc du disque avec les outils propre du disque, les descripteurs de sécurité du FS etc ... C'est juste impossible.
 
-Donc l'augmentation dans le client vsphere, c'est fait
-Forcer le rescan servira a rien
-fdisk -l /dev/sda te dira "merde", le disque a bien sa taille totale (dans la VM c'est pas le soucis), mais fdisk refusera de modifier le FS puisqu'il est monté : il y aura une corruption
-c'est pas le problème (bis)
-c'est pas le problème (ter) : même si tu augmente le vg (vue par vsphere) ton FS sera toujours sur la moitié : il faut reformater. Double emploi en plus avec l'agmentation dans le client vsphere
-pareil qu'au dessus
-Raté, le FS sera toujours pas modifié.
 
Donc je le répète :
Sa question n'était pas "comment augmenter la taille d'un volume virtuel pour une VM dans vsphere" mais "comment augmenter la taille de la partition "/" (y Z lapin cochon, appelez là comme vous le voulez". La réponse est : tu démonte la partition, un coup de gparted pour modifier le FS, tu remonte la partition. Etant donnée que sa partition est "root" et qu'il a pas de /bin /usr /whatever séparés, il ne peut pas modifier sa partition "a chaud" (démonter la partoche impossible puisque rien que bash et les PID < 500 utilisent le disque et ne sont pas "tuables" sans planter le système) donc il doit monter en environnement live.
 
En gros :  
Il part de VG 80G
Boot100m
LV 80G
/ 80G
 
Il arrive a  
VG 160G
boot100m
LV 160
/ 80G
 
Donc autant les modifications VG/LV se font a chaud, sans soucis, autant dire a "/" de passer sur la totalité du disque demande de reformater/étendre la partition, "/" n'est pas au courant de l'espace utilisable, faut modifier les données meta du FS > tu doit démonter le FS avant de travailler dessus.

j'voulais pas paraitre désagréable  
Il me semblait juste avoir déjà fait ce genre de chose sur des machine en prod sur des esx, voilà tout.
 
Cependant, la mouche m'a piqué et j'ai entrepris de valider (ou pas) ma théorie.
Donc j'ai tenté l'opération sur une VM virtualbox que j'avais sur mon poste. Par contre, vu qu'apparement on ne peut pas augmenté ou ajouté à chaud un disque sur une VM avec virtualbox (mais j'ai pas chercher longtemps j'dois dire), j'ai simplement rajouté un nouveau disque de 2Go à froid.
 
Je boot la machine, mon volgroup-lv_root (aka mon "/" est à 14Go).
je ne fait pas de partition sur mon nouveau /dev/sdb et en fait de suite un PV via "pvcreate". Ensuite j'étend mon vg VolGroup avec ce nouveau pv.
Enfin, je fait direct un lvextend du lv_root avec l'option "-r" pour resize le FS en même temps.
 
Bah c'est ok apparement, mon / fait à present 16go  
voici la video (je suis aller au bout de ma connerie ): http://youtu.be/TREiRhzjkNs
ça dure 3 minutes boot et halt compris.
 
bon alors ensuite, dans mon cas c'etait du rhel6 mais ma main à couper que ce serait la même avec rhel5 et de l'ext3.
 
Du coup je persiste à dire que dans le cas de Ephmride, avec le vmdk de sa vm déjà augmenté, il lui aurait "suffit" de faire un rescan, d'utilise la place dispo pour créé son /dev/sda3, pvcreate de la nouvelle partition, vgextend, lvextend.
 

Négatif.
ESX accepte le dimensionnement a chaud.
En ce qui concerne la table des partitions, disque système ou pas, elle est modifiable a chaud. LVM est déjà present, donc l'utilisation des partitions se fait egalement à chaud (pvcreate, vgextend, lvextend).
Enfin, on ne démonte pas un FS pour le modifier (fsadm resize).
La seule chose qui pourrait nécessiter un redémarrage ici ça serait un noyau qui refuse catégoriquement de voir la nouvelle table de partition pour présenter les blocks devices. Mais c'est rare et anormal.
Je maintiens, tout ceci se fait a chaud. Disque système ou pas, c'est une opération basique de prod.

Merci pour la démo pédagogique.

Jusqu'au jour ou tu va avoir une merde, bref, l'usage recommandé est de démonter ses FS avant de bosser dessus, c'est la bonne pratique, et je vois pas pourquoi conseiller autre chose, vue toutes les merdes et les environnements critiques.

Revenons donc à la base ...

Les manuels d'utilisation du système d'exploitation dont il est question ici mentionnent évidemment le redimensionnement des filesystems à chaud.
Pour RedHat6 ça se trouve dans le Storage Administration Guide, Section 1, chapitres 6.3 et 8.4. Pour RedHat 5, ça se trouve dans le Deployment Guide, chapitre 4.5.

Au passage, les manuels RedHat sont des lectures intéressantes pour qui veut parfaire ses connaissances techniques.

Putain mais gros troll tu va stopper tes conneries oui ? REDIMENSSIONEMENT A FROID DU FS, point barre, marre de voir des gens se plaindre qu'ils peuvent plus booter, qu'ils perdent des informations, etc etc ... SURTOUT QUAND CA TOUCHE DES ENVIRONNEMENTS DE PROD.
 
M'en bat les nichons de savoir comment tu redimenssionne tes FS, je m'en fou de se que dit Red Hat, si un manuel me dit de tourner en rond autour de mon PC en chantant de l'Edith Piaf j'irai pas le faire non plus.
 
Là, t'arrive a le comprendre ? C'est bon ou tu va encore nous en rajouter une foutu couche de 10km de "oui mais on peu le faire" ON S'EN TAPE QU'ON PUISSE LE FAIRE, C'EST A CAUSE DE L'UTILISATION D'UN BUG KERNEL AVEC EXTENSION EXT3/EXT4, EN EXT2, REISERFS SUIVANT LA VERSION? CA MARCHE PAS, EXT3 C'EST UN BUG QUI PERMET LE BACKPORT A CAUSE DES INTERACTIONS. Moralité : la bonne pratique c'est "je démonte mon FS".
 
BTRFS j'en parle pas.
 
http://ubuntuforums.org/showthread.php?t=1173282
 

 
Et en plus tu te gourre totalement, c'est pas le redimensionnement c'est l'AUGMENTATION UNIQUEMENT, pour shrinker, faut démonter le FS.
 
ET BORDEL A CUL QUAND TU LINK DES DOCUMENTS, VERIFIE QU'ILS S'APPLIQUENT AU CAS DU MEC QUE T'AS EN FACE : tes putains de manuel c'est écrit en GROS : EXT4
 

 
Tu lit quoi la ? EXT3 Et j'ai mis quoi au dessus ? C'est un bug kernel qui marche quand il veux le resize a chaud de l'EXT3 (en augmentation uniquement)
 
Bref, les trolls, ca me lourde.

Faudrait penser à arrêter les produits excitant. Tout ce que tu dis peut être dit calmement, ça aura sûrement un meilleur effet. Pour la suite si les gens souhaitent prendre des risques pour leur environnement (dont tu ne connais pas le contexte et les risques acceptables), c'est leur problème, pas le tien. Tu exposes les soucis qu'ils risquent, ça suffit, les gens peuvent être obtus (cf. toi) et pas forcément de ton avis.

Bref, tu te calmes !

Quels sont les risques d'agrandir un SF a chaud? Honnetement je n'en connais pas en particulier, mais ca m'interesse s'il y en a. J'ai fait comme cela pour mon LVM dernierement.

Ca par contre ca m'a fait bien rire, mais je laisserai comprendre pourquoi  

Agrandir un FS a chaud, c'est par exemple avoir des risques au niveau des inodes (en vrac chevauchements, perte, disparitions ...) , avoir des desalignements de FS, des enregistrements journaux erronés, baisse de performance, chaque extension du FS réduit la taille maximum du dit FS (16PO en ext3, si tu agrandit le FS, tu doit rajouter un jump en fin de FS, ce jump prend de l'adressage mémoire, sur 32 bits, et donc a chaque fois tu que agrandit ton FS, tu rajouter un jump qui réduit l'espace ...)
Tu risque le dépassement de FS, la pertes des caches sur carte raid, la désynchro du raid et le blacklistage des disques (certaines versions de resize2fs a chaud peuvent occuper les disques et les faire ne pas répondre au contrôleur raid, qui les éjecte carrément, sur un san, ça le fait pas quand c'est 20 disques que tu doit foutre a la poubelle, surtout des cheetah a 600 balles le disque ?)
 
C'est non exhaustif.

Merci bien

Quelqu'un a quelque chose contre Edit Piaf ?
Moi, j'aime bien Edit Piaf    
 
Bon, restons calme. Cette procédure décrite plus haut que je reprends ici a le mérite d'être claire, énoncée en pas à pas, imprimable (la vidéo l'est rarement   ) et fonctionne dans l'environnement suivant :
Red Hat 5
vMware 5
 
C'est pas un tuto (il manque l'adresse ,où j'ai récupéré le Gparted, par exemple) mais c'est utilisable par d'autres newbe qui seraient dans la même situation que moi. En informatique, il est souvent possible de suivre différentes routes pour atteindre le même objectif. Cette route a montré son efficacité, dans mon cas au moins.
 
Je remercie MysterieuseX tant pour son aide que pour ses expressions imagées qui permettent de dédramatiser des situations ... même si je regrette qu'elle n'aime pas Edit Piaf.