Tag Archives: lvm

Mindske størrelsen på et lvm mount på Ubuntu kørende i VMware

En kunde havde fået tildelt lidt for meget plads til nogle virtuelle maskiner, og de ønskede at diskstørrelserne gjort mindre, så de ikke lige pludselig kom til at bruge alt pladsen.

Fremgangsmåden jeg benyttede er lånt fra Technogrip, og beskriver det til CentOS og for root-filsystemet. I mit tilfælde drejdede det sig om en ekstra disk, og derfor ser det lidt anderledes ud. F.eks. behøver jeg ikke at boote i rescue mode.

# df -h
  Filesystem                   Size  Used Avail Use% Mounted on
  /dev/mapper/ubuntu-root       19G  3,4G   15G  19% /
  udev                         3,0G  4,0K  3,0G   1% /dev
  tmpfs                        1,2G  260K  1,2G   1% /run
  none                         5,0M     0  5,0M   0% /run/lock
  none                         3,0G     0  3,0G   0% /run/shm
  /dev/sda1                    228M   47M  170M  22% /boot
  /dev/mapper/storage-storage 1000G  135G  815G  15% /storage

I bunden ses det store 1000GB drev, som der ønskes at laves til 200GB i stedet

Først skal drevet unmountes

# umount /storage

For en sikkerhedsskyld laver i et check på drevet

# fsck -fC /dev/mapper/storage-storage 
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity                                        
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
/dev/mapper/storage-storage: 461/65536000 files (9.8% non-contiguous), 35546593/262144000 blocks

Herefter ændre vi det logiske drev til 200GB

# lvresize -r /dev/storage/storage --size 200G
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
/dev/mapper/storage-storage: clean, 461/65536000 files, 35546593/262144000 blocks
resize2fs 1.42 (29-Nov-2011)
Resizing the filesystem on /dev/dm-0 to 52428800 (4k) blocks.
The filesystem on /dev/dm-0 is now 52428800 blocks long.

  Reducing logical volume storage to 200,00 GiB
  Logical volume storage successfully resized

Det fysiske drev er stadig den gamle størrelsen, men har nu +800GB tilgængelig

# pvs
  PV         VG      Fmt  Attr PSize    PFree  
  /dev/sda5  ubuntu  lvm2 a-     19,76g  16,00m
  /dev/sdb1  storage lvm2 a-   1023,99g 823,99g

Herefter kan vi ændre den fysiske drev sættes til lidt over hvad vi bruger på den logiske. Det kunne være 200.01, men jeg har valgt 1GB ekstra. (Den ekstra størrelse skyldes at man ikke kan sætte størrelsen i extents og 200G vil være 1 extent for kort)

# pvresize /dev/sdb1 --setphysicalvolumesize 201G
  Physical volume "/dev/sdb1" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

Vores fysiske drev i LVM ser nu sådan ud.

# pvs
  PV         VG      Fmt  Attr PSize   PFree   
  /dev/sda5  ubuntu  lvm2 a-    19,76g   16,00m
  /dev/sdb1  storage lvm2 a-   201,00g 1020,00m

Herefter er det tid til at rette partitonen. Først skal vi den nye størrelse på drevet i sektører.

# pvs --unit s
  PV         VG      Fmt  Attr PSize      PFree   
  /dev/sda5  ubuntu  lvm2 a-    41435136S   32768S
  /dev/sdb1  storage lvm2 a-   421519360S 2088960S

og herefter hvornår drevet starter.

# parted /dev/sdb unit s print
Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 2147483648s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End          Size         Type     File system  Flags
 1      63s    2147472809s  2147472747s  primary               lvm

Nu er det tid til at resize partionen. Først slettes den gamle partition 1, som vist herover. Bare vælg cancel til fejlen. Vi tilføjer den igen lige om lidt.

# parted /dev/sdb rm 1
Error: Partition(s) 1 on /dev/sdb have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.
As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
Ignore/Cancel? C                                                          
Information: You may need to update /etc/fstab.                           

Herefter opretter vi den nye partition, med den samme startposition og den nye slutposition, som er længden på de 421519360S+63S = 421519423s.

# parted /dev/sdb mkpart primary 63s 421519423s
Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? I                                                          
Error: Partition(s) 1 on /dev/sdb have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.
As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
Ignore/Cancel? C                                                          

Vi aktivere lvm for den nye partition.

# parted /dev/sdb set 1 lvm on
Error: Partition(s) 1 on /dev/sdb have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.
As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
Ignore/Cancel? C        

Den nye partition ser hermed sådan ud.

# parted /dev/sdb unit s print
Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 2147483648s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start  End         Size        Type     File system  Flags
 1      63s    421519423s  421519361s  primary               lvm                                                  

For en sikkerhedsskyld laver vi igen et check på storage.

# fsck -fC /dev/storage/storage 
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
/dev/mapper/storage-storage: 461/13107200 files (11.1% non-contiguous), 32252895/52428800 blocks

Den nye storage kan nu mountes. Tag evt en reboot for at sikre at det virker.

# mount /storage

# df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu-root       19G  3,4G   15G  19% /
udev                         3,0G  4,0K  3,0G   1% /dev
tmpfs                        1,2G  260K  1,2G   1% /run
none                         5,0M     0  5,0M   0% /run/lock
none                         3,0G     0  3,0G   0% /run/shm
/dev/sda1                    228M   47M  170M  22% /boot
/dev/mapper/storage-storage  200G  123G   67G  65% /storage

Rettelse af størrelse i VMware

SSH in på VMware hypervisor

Udregn den nye størrelse på drevet.

vmdk_shrunken = [x * (1024*1024*1024)] / 512

Hvor x er størrelsen i GB (i eksemplet 201GB)

Denne størrelse indsættes i vmdk-filen.

# vi /path/to/original_vmdk

Find den linje der ligner nedestående og tilpas tallet

# Extent description
RW 421527552 VMFS “foo-flat.vmdk”

Export til en ny VMDK. Dette kræver at maskinen er lukket ned imens dette sker. Kan tage nogle timer alt efter størrelse på drevet og hastigheden på de diske der benyttes.

# vmkfstools -d thin -i virtualname_1.vmdk virtualname_1mod.vmdk

( -d thin er valgfrit, men gør at drevet kun fylder den nuværende brugte mængde i den virtuelle maskine)

Log ind på ESX (vcenter), fjern drevet og tilføj den nye drev til maskinen. Fjern maskinen fra Inventory og tilføj den igen.

Herefter kan den virtuelle maskine startes igen, og jobbet er udført.

shrink / ext3 on a lvm2 setup

Jeg har en internt server i mit firma hvilket jeg havde fået acceptere et lidt for meget standard setup.
Dette betød at jeg havde en ubuntu med 50GB root mount, hvilket jeg gerne vil have gjort mindre til 15GB og flytte 30GB over på en anden mount.

Efter lidt søgen (tak google), så fandt jeg følgende løsning.

Bemærk at dette er ikke en helt sikker metode, så søg for at have backup

  • Boot ubuntu live cd
  • Start en root shell

Derefter kørte jeg følgende kommandoer, som fundet på dette link.


lvm vgscan (discover volume groups)
lvm vgchange -ay (activate all discovered VGs)
lvm lvscan (scan and return info about the LVs)
vgdisplay (display info about the VGs)
lvdisplay (display info about the LVs)
tune2fs -l /dev/volumegroup/rootvolume
e2fsck -f /dev/volumegroup/rootvolume (do a check of the current fs)
resize2fs /dev/mapper/volumegroup-rootvolume nnnG (resize the file system, where nnn is the number of gigabytes you want, and G tells resize2fs that nnn is in gigs).
lvreduce -L-xxG /dev/volumegroup/rootvolume (to reduce the size by xx Gigs).
e2fsck -f /dev/volumegroup/rootvolume (recheck the fs) Note: If the check fails, do an lvextend -L+xxG /dev/volumegroup/rootvolume to resize the LV back to where it was, and then re-run the e2fsck to confirm that it's ok. The most likely cause is using the wrong xx or nnn for the resizes.
  • Boot maskinen
  • lvextend -L +25G /dev/volumegroup/rootvolume
  • resize2fs /dev/volumegroup/rootvolume

Færdig, og nu har jeg flyttet mere plads over på mit backup storage.