Disk partitioning- Vmware Linux guest
-
If you were on a SAN, you would have the same growth options that you have with VMware here, and you would use LVM to manage your storage. LVM was actually designed more for these scenarios than for any other. This isn't a "hey, I could skip LVM here" situation, it is in fact "exactly what LVM was made for."
We just had this in another thread last night. LVM adds a lot of pros and has basically no cons. There is no reason to skip it but important reasons to add it in.
The only time I'd serious talk about not having LVM is in a pure DevOps / Cloud scenario where you can't access the system to use LVM and you would destroy the instance and make a new one rather than ever using an LVM feature. So if you were working purely through Chef, Puppet or Ansible and working exclusively with disposable VMs.
-
Thanks a lot @scottalanmiller will read more about lvm, but this really helped.
-
We are doing an LVM session at MangoCon I think!
-
I read this on a site:
*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 SWAPDoing 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.*
-
@Ambarishrh said:
*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.But that isn't what LVM is. It is not a hack nor is it for overcoming physical disk limitations. It's an important part of the storage mechanism.
-
@Ambarishrh said:
Doing this has simplified resizing so much, I now let the junior admins and my manager expand drive space as needed.
Because their juniors could not follow the simple instructions for using LVM? This seems like they are grasping at trying to justify having made a mistake. If their junior admins don't know LVM already, they have a problem. If their juniors can't follow the documentation that you just copied here to do it, they have a huge problem. LVM is easy. Yes, it adds a few commands, but so does RAID. But we don't drop that just because it would save effort.
-
@Ambarishrh said:
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.*
So quick? How is this faster? Ten seconds faster because of a few fewer manual commands? How often are they expanding? Sounds like they made the mistake of not thin provisioning and hired people who can't type and don't have enough disk space. Plus they are dependent on having only one working partition to expand. Put those four mistaken things together and they imagine that LVM would stand in their way, which is false. So four administration mistakes made by incompetent people, add in their complete inability to understand what LVM is and their imagine that removing LVM is somehow helping them. This seems absurd.
-
I am still learning about LVM, one of my search took me to a site where this was explained!
Let me test this and i might need some help/advice on this.
-
@Ambarishrh said:
I am still learning about LVM, one of my search took me to a site where this was explained!
Let me test this and i might need some help/advice on this.
LVM is volume management. It is a basic form of storage virtualization used on all enterprise operating systems. AIX, Solaris, Windows, Linux, FreeBSD... they all use volume management as a very important abstraction layer between the file system and the block storage. It is what enables snapshots, partition modification and more in every one of those OSes. It's not really something that should generally come up as a topic for not using. There are cases for not uses it, but very few.
Think of volume management like virtualization. It is there to abstract raw interfaces and to provide flexibility for the unknown. Like virtualization, you generally avoid it only when you have a strong, clear technical reason why it is a problem. By default, always use it. Never ask "is it needed", you don't use it because it is necessary but because it is important. You only don't use it when you need to not use it.
-
This says you don't need a reboot for resizing. So if i understood this correctly, in my case VMWare can increase disk space on the fly, and then using LVM i make that space available to the volume group and then can be used to increase the space on the server with resize2fs.
-
@Ambarishrh said:
This says you don't need a reboot for resizing. So if i understood this correctly, in my case VMWare can increase disk space on the fly, and then using LVM i make that space available to the volume group and then can be used to increase the space on the server with resize2fs.
Correct, LVM is on the fly, no reboots involved.
-
With LVM you have the power to easily have multiple partitions for whatever needs you have. This lets you choose different filesystems as needed, as well. You can mix and match filesystems and features for speed, security, flexibility, etc. You can do encryption on a volume rather than on the entire system which is much more powerful, you can use XFS where it is useful, BtrFS where you want, EXT4 when needed... whatever. You can turn on quotas or compression selectively instead of globally.
-
I am planning to have the / and /var with LVM ext4, hope i can set only these two as LVM. does that make sense?
-
@Ambarishrh said:
I am planning to have the / and /var with LVM ext4, hope i can set only these two as LVM. does that make sense?
You make a partition that is LVM and then everything under that is the additional volumes. /boot and swap don't go on LVM.
-
I completed a test server with LVM. Did a split of /var on a separate disk and also moved /home to that, so that if something fills up this / doesn't get affected.
Overall it was very easy to extend the disk space and was a very good experience. Thanks once again @scottalanmiller
-
@Ambarishrh said:
I completed a test server with LVM. Did a split of /var on a separate disk and also moved /home to that, so that if something fills up this / doesn't get affected.
Overall it was very easy to extend the disk space and was a very good experience. Thanks once again @scottalanmiller
Another good thing to do is leave a small amount of space free (enough to cover the diff) so that you can do a snapshot of the LVM. If you update and it borks something you can revert to the snapshot, or even export the snapshot for a backup.
Since it's on VMware it's not that big of a deal because you have the snapshots for the vm itself, however on a physical machine it's useful.
-
regarding snapshots, this is what i heard from our hosting provider support team.
He says "big rule.
DO NOT LEAVE SNAPSHOTS AROUND.
if it exists for >48 hours, you're doing it wrong.
I have countelss stories of customers who made a snapshot forgot about it
3 months later they do a reboot or something and vmware consolidates the disk
we had a customer with a mission critical vm offline for >24 hours because it took 2 days to consolidate their data
(was like a 4tb vm)
snapshots are intended for short term use only" -
@Ambarishrh said:
regarding snapshots, this is what i heard from our hosting provider support team.
He says "big rule.
DO NOT LEAVE SNAPSHOTS AROUND.
if it exists for >48 hours, you're doing it wrong.
I have countelss stories of customers who made a snapshot forgot about it
3 months later they do a reboot or something and vmware consolidates the disk
we had a customer with a mission critical vm offline for >24 hours because it took 2 days to consolidate their data
(was like a 4tb vm)
snapshots are intended for short term use only"Oh ya these are just for short term. For example if you update and it screws something up you can revert. Once you test and make sure it's ok then delete it. I don't know how VMware does snapshots, but with LVM you can also export it. So you can take the snapshot and save it to a file, and if an issue does come up later down the road, you can just dd the file to the LVM again.
-
@johnhooks said:
@Ambarishrh said:
I completed a test server with LVM. Did a split of /var on a separate disk and also moved /home to that, so that if something fills up this / doesn't get affected.
Overall it was very easy to extend the disk space and was a very good experience. Thanks once again @scottalanmiller
Another good thing to do is leave a small amount of space free (enough to cover the diff) so that you can do a snapshot of the LVM. If you update and it borks something you can revert to the snapshot, or even export the snapshot for a backup.
Since it's on VMware it's not that big of a deal because you have the snapshots for the vm itself, however on a physical machine it's useful.
However, it IS useful to be able to do snapshots programatically and uniformly from inside of the OS. There are times that this would make sense and you can do it in a uniform way across physical and virtual machines, across all filesystems, across all hypervisors.
-
@Ambarishrh said:
regarding snapshots, this is what i heard from our hosting provider support team.
He says "big rule.
DO NOT LEAVE SNAPSHOTS AROUND.
if it exists for >48 hours, you're doing it wrong.
I have countelss stories of customers who made a snapshot forgot about it
3 months later they do a reboot or something and vmware consolidates the disk
we had a customer with a mission critical vm offline for >24 hours because it took 2 days to consolidate their data
(was like a 4tb vm)
snapshots are intended for short term use only"That is generally true, on VMware. That's a VMware shortcoming. If you are making lots of snaps and just letting them sit around, Vmware isn't going to be happy and eventually will fail, I've seen it.
If you are on more advanced systems like Scale, you do not have these kinds of limitations. It's not an intrinsic nature of snapshots to need to be very short term, it is the nature of how VMware implemented them.
Even if your snaps don't cause problems down the road, you would still probably not want to just collect them at random. But keeping long term rollbacks is not a big issue. XO even has rolling backups as a standard feature on XenServer.
