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 >