@porter: c'mon! This is not an answer, this is a zero-message. He asks if it is possible and you tell him to use SMIT?? SMIT is a frontend, nothing more, if it is possible, it is possible regardless of using SMIT or not and if it isn't it will be impossible, again reagardless of using SMIT or not.

This is not the first time i see you giving such non-answers. Are you posthunting?

@Threadstarter: no, that is not possible. LVs (Logical Volumes) belong to a certain VG (Volume Group). A VG is a logical construct which combines several PVs (Physical Volumes: pyhsical disks, RAID volumes, SAN-shares, etc.) to one manageable entity. The disks are split into (more or less anonymized) parts (the "Physical Partition", PP) and given to a pool which can be assigned to the LVs in the VG. Most of the times LVs contain (exactly one) FS, but LVs could also host a swapspace, a boot partition, and some other things (you could even decide to use it as a raw device although this makes no sense any more nowadays), but save for these you could use "LV" and "FS" interchangeably - most of your logical volumes contain a filesystem.

Usually VGs are used for a group of LVs which are somehow logically connected. For instance, if you have several database instances on one machine it might be a good idea to create a VG for every instance. In every of these VGs you would have one FS (LV) for the binaries, one for the logs, one for the tablespaces, etc.

So the only reason why you would want to transfer a filesystem from one VG to another would be space considerations. In this case it is better to:

add more PPs to the LV if there are enough left in the pool (use lsvg <VGName> to check). dont forget to expand the filesystem after resizing the LV, it is not done automatically. Do the following:

get the PP size to find out how many PPs you will have to add to expand the LV for a certain size. (lsvg <VGName>) Get the name of the LV as you have perhaps only the mountpoint of the corresponding filesystem (lsvg -l <VGName>). Now calculate how much this is in 512-byte-blocks. Use chfs to expand the filesystem accordingly (chfs -a size=+<NrOfBlocks> <mountpoint>). You can do that without umounting the FS, your application using the FS won't even notice it.

For example: The PP size is 128MB and you want to add 2GB to the LV mytestlv mounted on /my/testlv. You will have to add 16 PPs. (I won't explain possible considerations about mirroring here.) Issue

extendlv mytestlv 16

Now calculate how much this is in 512-byte-blocks: 2*1024*1024*2=4194304

chfs -a size=+4194304 /my/testlv

If this is not possible because the pool of free PPs is exhausted add a new physical volume to the colume group (up to a maximum of 32)

If this is still not possible it is better to reorganize the volumegroup as a whole, using a bigger PP size (since PVs are limited to 1019 PPs the PP size determines the maximum size of the PVs used), use different storage, etc. and recreate all the LVs on the VG.

Oh, besides: you could do all that with SMIT too if you like.

bakunin