Hello,
----- Original Message -----
From: "Russell Smithies" Russell.Smithies@agresearch.co.nz To: "CentOS mailing list" centos@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:
- Increase size of VMDK
- In VM OS, Create Partition (??)
- REBOOT (!!)
- PVCreate
- VGExtend
- LVExtend
- Resize2fs
Going to a LVM/partition-less setup reduces expansion to 3 steps and we don't need to take the VM OS offline!
- 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@centos.org http://lists.centos.org/mailman/listinfo/centos