Forum Linux.général Supprimer disque scsi

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
0
25
fév.
2020

Bonjour à tous,

J'ai une VM (vmware) redhat 5 (ou c'est vieux) comportant 3 disques :

# lsscsi 
[0:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
[0:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb
[0:0:2:0]    disk    VMware   Virtual disk     1.0   /dev/sdc
# fdisk -l    
Disque /dev/sda: 53.6 Go, 53687091200 octets
255 heads, 63 sectors/track, 6527 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        6527    52323705   8e  Linux LVM

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


Disque /dev/sdb: 177.1 Go, 177167400960 octets
255 heads, 63 sectors/track, 21539 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdb1               1       21540   173015039+  ee  EFI GPT

Disque /dev/sdc: 177.1 Go, 177167400960 octets
255 heads, 63 sectors/track, 21539 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdc1               1       21540   173014016   83  Linux

Disque /dev/dm-0: 49.3 Go, 49358569472 octets
255 heads, 63 sectors/track, 6000 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Disque /dev/dm-0 ne contient pas une table de partition valide

Disque /dev/dm-1: 4194 Mo, 4194304000 octets
255 heads, 63 sectors/track, 509 cylinders
Unités = cylindres de 16065 * 512 = 8225280 octets

Disque /dev/dm-1 ne contient pas une table de partition valide

Je souhaite supprimer le disque sdb (le disque n'est pas monté ou utilisé par LVM). Je détache le disque correspondant à 0:0:0:1 et je lance les commandes suivantes :

echo "- - -" > /sys/class/scsi_host/host0/scan
echo 1 > /sys/block/sdb/device/delete

Pas de plainte du système et sdb n’apparaît plus dans fdisk. Je pousse le truc jusqu'au bout, je reboot le serveur et là c'est le drame. La VM ne démarre plus car il ne trouve plus sdb :(

Si j'attache de nouveau le disque et que je reboot tout rentre dans l'ordre.

Est-ce que j'ai loupé une étape ?

  • # trop simple

    Posté par  (site web personnel) . Évalué à 1.

    Bon ça pourrait servir à d'autres.

    Avant détachement du disque

    Linux

    • vérifier qu'aucun process n'allait avoir besoin d'accéder à sdc1;
    • modifier fstab pour pas que sdc1 monte au boot;
    • démonter manuellement sdc1;
    • arrêt de la VM.

    VmWare

    • détachement du disque 0:0:1:0 (sdb)
    • attribution du disque 0:0:2:0 (sdc) à 0:0:1:0.

    Un reboot, tout est ok.

    • monter manuellement l'ex sdc qui est devenu sdb.

    J'ai toute les données et pas d'erreurs.

    • modifier fstab pour qu'il monte automatiquement sdb1;
    • reboot pour tester.

    Tout est ok.

    Désolé pour tout ce bruit… ;)

    Born to Kill EndUser !

    • [^] # Re: trop simple

      Posté par  . Évalué à 4.

      autre piste, le montage par UUID des disques plutôt que /dev/sdXY
      ainsi le disque peut se balader dans l'arbre /dev, il reste montrable normalement.

      pour connaitre les UUID des disques/partitions, faire
      blkid

      puis la ligne de montage de fstab passe de

      /dev/sdXY /point/de/montage filesystem options ...

      à

      UUID=fdsfsqf-fdsqdfsq-fdfezgrezekjg /point/de/montage filesystem options ...
      • [^] # Re: trop simple

        Posté par  (site web personnel) . Évalué à 1.

        Effectivement sur des OS plus modernes j'utilise les UUID mais sur une redhat 5 je suis pas certain que cela marche.

        Born to Kill EndUser !

        • [^] # Re: trop simple

          Posté par  . Évalué à 3.

          ca se tente, non ?

          et ca résoudrait pas mal de tes soucis.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.