[CentOS] not using LVM for Linux VM guests?

[Jon Detert]

Hello,

----- Original Message -----
> From: "Russell Smithies" <Russell.Smithies at agresearch.co.nz>
> To: "CentOS mailing list" <centos at centos.org>
> Sent: Wednesday, November 16, 2011 2:37:54 PM
> Subject: [CentOS] not using LVM for Linux VM guests?
> 
> I came across an old post comment yesterday (from
> http://echenh.blogspot.com/2010/04/how-to-extend-lvm-on-vmware-guest-os.html
> ) discussing the "hack" of LVM on Linux VM guests and whether it's
> better not to use it to simplify disk management.
> I've re-posted the comment below, does it sound reasonable? Is it
> better to not use LVM on Linux VM guests?
> 
> --Russell

I've had the same question.  I've decided to continue to use LVM, for these 2 reasons:

1) my hypervisor, good, bad or indifferent, is VMware ESX 4.x and ESXi 4.x.  Those hypervisors can't create virtual disks greater than 256 GB.  So, if I want a file-system larger than 256 GB, I have to have some other software - LVM, in this case.

2) I like being able to give disk devices descriptive names, like /dev/mapper/zimbra-data instead of simply '/dev/sdb' or similar.  There are probably ways other than LVM to do that, but LVM does offer that flexibility.

One thing I do avoid, however, is partitioning the virtual disks that might need to grow.  This is because of the pain described in part below.  The kernel often seems to have a hard time letting go of it's view of the partition table - either i have to umount the partition, or reboot.  However, if i use the disk unpartitioned, the kernel has no prob, and I can *extend and/or resize*fs without umount or reboot.

- Jon

> -----------------------------------------------------------
> At my job, after doing the same kind of procedure graph, we began to
> ask ourselves, why are using a LVM on a Linux VM guests?
> 
> Since we're no longer living in the physical OS world, we didn't need
> to use the OS hacks(LVM) to overcome physical disk limitations
> anymore.
> We decided to Just let the hypervisor and virtual storage do that
> work for us.
> 
> For example, in our production setup (3 tier commerce with VMs for
> database , webserver, and appserver), we're see a great improvement
> in managability and performance (>10%) by just dropping LVM, and
> most partitions.
> 
> In your example, the resize process is 7 functional steps:
> 1. Increase size of VMDK
> 2. In VM OS, Create Partition (??)
> 3. REBOOT (!!)
> 4. PVCreate
> 5. VGExtend
> 6. LVExtend
> 7. Resize2fs
> 
> Going to a LVM/partition-less setup reduces expansion to 3 steps and
> we don't need to take the VM OS offline!
> 1. Increase size of VMDK
> 2- Inside the VM, OS, rescan the scsi drive with:'echo 1
> >/sys/class/scsi_device//rescan; dmesg' (dmesg will check that you
> drive isize has grown)
> 3- Resize2fs.
> 
> Our current disk arrangement has 3 VM HD devices
> 0 - small device (100M) with a single BOOT partition
> 1 - entire device is /
> 2 - entire device is SWAP
> 
> Doing this has simplified resizing so much, I now let the junior
> admins and my manager expand drive space as needed.
> 
> It's also let's us really be spartan on space since expansion is so
> quick. Instead of increasing systems in 30-50GB chunks, we can do
> 10-15GB and let our rmonitoring system warn us when space gets
> tight.
> -------------------------------------------------------------
> 
> =======================================================================
> Attention: The information contained in this message and/or
> attachments
> from AgResearch Limited is intended only for the persons or entities
> to which it is addressed and may contain confidential and/or
> privileged
> material. Any review, retransmission, dissemination or other use of,
> or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipients is prohibited by
> AgResearch
> Limited. If you have received this message in error, please notify
> the
> sender immediately.
> =======================================================================
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>