[18:10] <waldo323_> lvm question, I have system which has 1 volume group wth 4 logical volumes, is there a way to split these into separate groups without needed additional hard drive space? I
[18:12] <waldo323_> have seen examples where they basically copy a volume to a new group which has enoug disk space but that is not an option in this case.  the only volume that is actually impoartant is the one that is large enough that there woun't be enough space to copy it to another location , going to be aft for a little while but wanted to get the question entered before it left my brainspace
[18:36] <jrwren> Probably not.
[18:37] <jrwren> biggest question is: why would you want to? waht problem are you trying to solve?
[18:37] <jrwren> a VG holds PVs. So you'd have to empty PVs and move them to the new VG.
[18:37] <jrwren> In general, fewer VGs (ideally 1) is the most flexible config.
[19:36] <waldo323_> using security onion, and moving from 2.3 to 2.4 is a OS jump from centos 7 to oracle 9. we wanted to be able to keep our historical data. 
[19:40] <waldo323_> but the commands in their documentation aren't correct for their automated setup from 2.3. their instructions expect a particular volume to be its own volume group but it is in fact only a logical volume. their suggestion is to exclude this from the setup when installing fresh and then copy some of the new files in the folder from the fresh install into the previously excluded file system and change the mount point... https://docs.securityonion.n
[19:40] <waldo323_> et/en/2.4/appendix.html 
[19:44] <jrwren> wow, sounds like nightmare maintenance.
[19:55] <waldo323_> i'm going to go on a limb and guess this wasn't tested with the 2.3 installed from their iso as the iso installation (or at least the options I've gone through so far) haven't given the option to exclude or select disks it simply expects all disks to be used for the new installation - which given the use case its not unreasonable 
[19:57] <waldo323_> the data that would get saved would likely get over written with new data in a relatively short amount of time anyway unless there is any trend data which wouldn't get overwritten - not sure
[20:02] <waldo323_> if I were to guess, I'd guess that the CentOS changes over the past couple of years contributed to this complication
[20:03] <waldo323_> while working on this, I learned you can't shrink xfs file systems
[20:04] <jrwren> really?
[20:04] <jrwren> why do I feel like I have done that.
[20:05] <jrwren> wow, yeah, the command is even xfs_growfs. I wonder if I knew that and forgot and its another reason why I always preferred ext4.
[20:05] <waldo323_> everything i've found said to create a smaller one and copy the data into it
[20:05] <jrwren> darned shame, because xfs is so nice.
[20:06] <waldo323_> yeah :)
[20:12] <waldo323_> they instructions for, but won't support, a network installation so i'll try that again. i'll start with removing the root volume, re-create the root volume smaller and a temp volume for the nsm folder then install Oracle 9 which they are using as their base. I ran into an issue which was possibly user error last time I tried.... I am running this in a test environment which is helpful for ease of mind
[20:12] <waldo323_> *they have instructions for
[20:44] <waldo323_> just found that adding a disk to the system gives the option I was missing before, to exclude the disk with nsm on it