How to increase/resize vMA Disks

How to increase/resize vMA Disks

Summary:

If you're extensively using vMA's vi-logger functionality or storing lots of content on the default 5gb VMDK, you can easily fill up the disks. This document will provide the steps in resizing and increasing the disk sizes using LVM.

Environment:

vMA 4.0 or VIMA 1.0 (not testing on VIMA 1.0, but steps should be exactly the same)

SSH and/or vSphere Client console access

Operation:

Increase /var/log from 500MB to 10GB

Steps:

1. Here is a default vanilla installation of vMA

Last login: Sat Aug  8 15:00:31 2009 from 172.30.0.225

Welcome to vMA
run 'vma-help' or see http://www.vmware.com/go/vma4 for more details.

[vi-admin@vMa-resize ~]$ cat /etc/vima-release | head -1
vMA 4.0.0 BUILD-161992

[vi-admin@vMa-resize ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      3.3G  1.5G  1.7G  48% /
/dev/mapper/VolGroup00-var
                      496M   19M  452M   4% /var/log
/dev/sda1              99M   16M   79M  17% /boot
tmpfs                 250M     0  250M   0% /dev/shm

2. Notice /var/log has total of 452MB free and I will attempt to fill it up to 98%

[vi-admin@vMa-resize ~]$ sudo dd if=/dev/zero of=/var/log/big_ass_file bs=1M count=440
440+0 records in
440+0 records out
461373440 bytes (461 MB) copied, 9.64461 seconds, 47.8 MB/s

[vi-admin@vMa-resize ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      3.3G  1.5G  1.7G  48% /
/dev/mapper/VolGroup00-var
                      496M  461M  9.9M  98% /var/log
/dev/sda1              99M   16M   79M  17% /boot
tmpfs                 250M     0  250M   0% /dev/shm

OH NO! Smiley Sad /var/log is full, what to do! Let's increase the size of /var/log to 10GB, that should be plenty for logs.

3. Shutdown the vMA and edit the VM configurations and change the disk from 5gb to 15GB (increase of 10GB)

[vi-admin@vMa-resize ~]$ sudo shutdown -h now

4. Power back on vMA

5. As you can see we've grown the virtual disk from 5gb to 16gb

[vi-admin@vMa-resize ~]$ sudo fdisk -l
Password:

Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14         652     5132767+  8e  Linux LVM

6. Next we'll be creating a new partition with the new space

[vi-admin@vMa-resize ~]$ sudo fdisk /dev/sda

The number of cylinders for this disk is set to 1958.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 3
First cylinder (653-1958, default 653):
Using default value 653
Last cylinder or +size or +sizeM or +sizeK (653-1958, default 1958):
Using default value 1958

Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Note: The options were: n,p,3,<enter>,t,3,8e,w

7. We now verify the new partition has been created:

[vi-admin@vMa-resize ~]$ sudo fdisk -l

Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14         652     5132767+  8e  Linux LVM
/dev/sda3             653        1958    10490445   8e  Linux LVM

/dev/sda3 is our new partition which has been formatted with LVM, we now need to reboot vMA before continuing.

vi-admin@vMa-resize ~]$ sudo reboot

8. We need to add a physical volume before LVM can access the partition

[vi-admin@vMa-resize ~]$ sudo pvcreate /dev/sda3
  Physical volume "/dev/sda3" successfully created

9. Now we need to extend the existing volume group to the physical volume which was found by doing (df -h)

[vi-admin@vMa-resize ~]$ sudo vgextend VolGroup00 /dev/sda3
  /dev/hda: open failed: No medium found
  Volume group "VolGroup00" successfully extended

10. Now we'll want to extend the logical volume into the new space, but we want to make sure how much the system will give us in terms of free space

[vi-admin@vMa-resize ~]$ sudo vgdisplay | grep -i free
  Free  PE / Size       320 / 10.00 GB

As you can see, that is the additional 10GB we've added on top of the already existing 5GB

11. Now we extend the LV to /var and not to another mount point and we'll increase that to 10GB

[vi-admin@vMa-resize ~]$ sudo lvextend -L+10G /dev/VolGroup00/var
  Extending logical volume var to 10.50 GB
  Logical volume var successfully resized

12. Last step is to make this space available to the OS, on general RHEL systems you have access to ext2online but since vMA is a stripped down version of RHEL, that is not available. We'll make uses of resize2fs to accomplish the same task

[vi-admin@vMa-resize ~]$ sudo resize2fs -p /dev/VolGroup00/var
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/var is mounted on /var/log; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/var to 11010048 (1k) blocks.
The filesystem on /dev/VolGroup00/var is now 11010048 blocks long.

Note: This task can take a few minutes depending on the disk size increase

13. Now we verify the new disk increase for /var/log for 10GB

[vi-admin@vMa-resize ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      3.3G  1.5G  1.7G  48% /
/dev/mapper/VolGroup00-var
                       11G  462M  9.2G   5% /var/log
/dev/sda1              99M   16M   79M  17% /boot
tmpfs                 250M     0  250M   0% /dev/shm

voilà! you've just increased the disk space on the default installation of vMA.

Comments

Unfortunately, Now with vMA 4.1, it doesn't quite work like this, as it doesn't use LVM:

Could you perhaps update your wonderful guide on how to do it for vMA4.1?

Note: I already increased the raw diskspace of the vmdk from 5 to 7 GB in a quick futile attempt to use the gparted live CD to increase the Logspace:

[root@vma ~]#fdisk -l

Disk /dev/sda: 7516 MB, 7516192768 bytes
255 heads, 63 sectors/track, 913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14         144     1052257+  82  Linux swap / Solaris
/dev/sda3             145         209      522112+  83  Linux
/dev/sda4             210         652     3558397+   5  Extended
/dev/sda5             210         652     3558366   83  Linux

[root@vma ~]# mount
/dev/sda5 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda3 on /var/log type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

[root@vma ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5             3.3G  1.4G  1.8G  44% /
/dev/sda3             494M   15M  454M   4% /var/log
/dev/sda1              99M   12M   82M  13% /boot
tmpfs                 250M     0  250M   0% /dev/shm

Yes, it's unfortunate that VMware did not use LVM but even so, you can easily increase both / and /var/log partition using gparted. Ensure that you resize the partition inside extended partition first, else you will not have room to shrink and expand say /var/log

I recommend you do a search online on how to resize a linux partition, there are plenty of guides and tutorials that walk you through the steps.

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware scripts and resources at:

Twitter: @lamw

vGhetto Script Repository

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

I fixed it by booting the gparted live CD, then creating a new partition at /dev/sda6 with the label /var/log/vmare using the new found free space.

Deleted the contents of /var/log/vmware (backup if you need them).

Then I edited /etc/fstab and copied the /var/log line and pasted a new line and changed both /var/log instances to /var/log/vmware. Rebooted.

Now all my ESXi servers log to their own partition /dev/sda6 in /var/log/vmware.

I did with the method explained juste before.

And i want to tell that the line in /etc/fstab, in my version of vMA appliance, contain a label in order to find the correct disk :

LABEL=/var/log /var/log ext3 defaults 1 2

So when you add the new disk with gparted, you just have to set the label, and of course remove the old one after copying the old logs.

It's so simple !

By the way, thanks to the community to bring us this wonderfull product !

Here is an update on how to resize partitions on vMA 4.1 - http://www.virtuallyghetto.com/2011/01/how-to-increase-capacity-of-varlog-on.html

Version history
Revision #:
1 of 1
Last update:
‎08-08-2009 03:46 PM
Updated by: