Hello,
----- Original Message -----
> From: "Russell Smithies" <Russell.Smithies@xxxxxxxxxxxxxxxx>
> To: "CentOS mailing list" <centos@xxxxxxxxxx>
> Sent: Wednesday, November 16, 2011 2:37:54 PM
> Subject: 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@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
