Solution 1 :
Vous devez envoyer la commande rescan à votre bus SCSI.
Dans VMware, le contrôleur SCSI peut se trouver à un endroit inhabituel. Trouvez-le d'abord :
find /sys -iname 'scan'
Pour moi c'est revenu
/sys/devices/pci0000:00/0000:00:07.1/host0/scsi_host/host0/scan
/sys/devices/pci0000:00/0000:00:07.1/host1/scsi_host/host1/scan
/sys/devices/pci0000:00/0000:00:10.0/host2/scsi_host/host2/scan
Ensuite, lancez simplement la commande rescan
echo "- - -" >/sys/devices/pci0000:00/0000:00:07.1/host0/scsi_host/host0/scan
echo "- - -" >/sys/devices/pci0000:00/0000:00:07.1/host0/scsi_host/host1/scan
echo "- - -" >/sys/devices/pci0000:00/0000:00:10.0/host0/scsi_host/host2/scan
Cela devrait aider. :)
Solution 2 :
J'ai dû faire face à un problème similaire, sur un serveur SLES 11. Le LVM a été construit avec des disques bruts, fonctionnant sur VMWare ESXi
# pvcreate /dev/sdd; vgextend ....
Au bout d'un moment, j'ai eu besoin d'augmenter la taille de LVM, mais je n'ai pas ajouté de disque supplémentaire, puis pvcreate + vgextend comme je l'ai déjà fait, mais j'ai choisi d'augmenter la taille d'un disque existant (/dev/sdd dans ce cas ). Après avoir fait l'augmentation de VMWare, j'ai exécuté un
# rescan-scsi-bus.sh
Mais pvdisplay affichait toujours l'ancienne taille de disque. Il fallait faire un
# echo 1 > /sys/block/sdd/device/rescan
pour que le noyau apprenne la nouvelle taille de disque de /dev/sdd
Solution 3 :
après avoir fait echo 1 > /sys/block/sda/device/rescan
pvresize /dev/sda a fait l'affaire pour moi
Solution 4 :
Si la table de partition est directement utilisée (par exemple, vous avez monté le système de fichiers à l'aide d'une partition de base), le noyau continuera à utiliser l'ancienne table de partition jusqu'à ce que ce ne soit plus le cas. Quelqu'un m'a dit un jour que si vous utilisez LVM, vous pouvez contourner ce problème...
Solution 5 :
Mise à jour : Centos 6 - impossible de mettre à jour la table de partition du disque actif en ligne, Centos 7 - il est possible d'étendre la dernière partition avec growpart ou créez une nouvelle partition avec fdisk et rendez-la visible sans redémarrage avec partprobe . Probablement la même chose sur ubuntu/debian. - À un moment donné, après que le noyau 2.6 a commencé à prendre en charge la relecture en ligne de la table de partition du disque actif. Puisque la question est pour Centos 5, je dirais non.
Si vous utilisez des partitions, vous devez redémarrer pour utiliser le nouvel espace. Je n'ai pas trouvé de moyen d'éviter cela. Si quelqu'un me l'a fait savoir.
Cependant, le redémarrage doit être effectué après avoir étendu la dernière partition sur le disque ou ajouté une nouvelle partition. Redémarrer avant n'a aucun sens.
La première chose que vous devriez remarquer après la nouvelle analyse est la plus grande taille de disque dans fdisk et dans lsblk. Si vous ne le voyez pas, vous devez jouer avec ces commandes echo 1 et echo - - -.
Après avoir vu plus d'espace, vous pouvez étendre/ajouter une partition, puis redémarrer, étendre vg, étendre lv et fs.
Si vous voulez éviter le redémarrage, vous devez attribuer un disque brut sda/b/c au groupe de volumes sans le partitionner en sda1/2/3. Ensuite, il n'est pas nécessaire de redémarrer.
Le partitionnement était nécessaire il y a quelque temps lorsque Linux ne pouvait pas démarrer à partir de LVM, mais maintenant c'est possible.
Si vous utilisez lsblk, vous verrez des partitions ou des lvms selon que vous utilisez des partitions ou lvm, vous pouvez avoir toutes les parties si vous n'utilisez pas lvm ou tous les lvms si vous n'utilisez pas de partitions. Voici un exemple :
[email protected] ~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 7.3T 0 disk
├─sda1 8:1 0 500M 0 part /boot
└─sda2 8:2 0 7.3T 0 part
├─vg_srv4-LogVol13 (dm-0) 253:0 0 7.1T 0 lvm /
├─vg_srv4-LogVol05 (dm-1) 253:1 0 100G 0 lvm /var/log
├─vg_srv4-LogVol04 (dm-2) 253:2 0 20G 0 lvm /var
├─vg_srv4-LogVol01 (dm-5) 253:5 0 20G 0 lvm /opt
├─vg_srv4-LogVol00 (dm-6) 253:6 0 20G 0 lvm /home
├─vg_srv4-LogVol03 (dm-7) 253:7 0 20G 0 lvm /usr
└─vg_srv4-LogVol02 (dm-8) 253:8 0 8G 0 lvm /tmp