On 6/24/2015 2:06 PM, Chris Adams wrote: > Once upon a time, m.roth at 5-cent.us <m.roth at 5-cent.us> said: >> Here's a question: all of the arguments you're giving have to do with VMs. >> Do you have some for straight-on-the-server, non-VM cases? > I've used LVM on servers with hot-swap drives to migrate to new storage > without downtime a number of times. Add new drives to the system, > configure RAID (software or hardware), pvcreate, vgextend, pvmove, > vgreduce, and pvremove (and maybe a lvextend and resize2fs/xfs_growfs). > Never unmounted a filesystem, just some extra disk I/O. > > Even in cases where I had to shutdown or reboot a server to get drives > added, moving data could take a long downtime, but with LVM I can > live-migrate from place to place. This is one of my primary use cases, and a real big time saver. I do this allot when migrating Oracle DB LUN's to larger sized, new allocations. It works great weather you are using ASM or any Linux filesystem. It is especially handy when migrating from one SAN frame to another. You can fully migrate with zero down time if you do even a small amount of planning ahead. There are just so many time saving things you can do with it. Sure, if all groups in the chain plan ahead properly there can be very little change needed but how often does that happen in real life? It is part of my job to plan well enough ahead to know that storage needs grow despite everyone's best intentions to get out of the gate properly. LVM makes growing much easier and flexible.