To answer your query, in order to increase the size of an existing vg, you will need to assign another pv to it. you could reduce your existing vg and release a pv which then you can assign to another vg.
it is not possible to use existing free pe's on an existing vg to increase the size of another vg. vg's exclusivelly own pv's and pe's within pv's. vgspli will allow you to split an existing vg in to more vg's but above limitrations remain (pv's cannot be shared by vg's) hope it helps regards dean licherie On Tue, Aug 23, 2011 at 10:23 AM, Karthik R <mail2rkart...@gmail.com> wrote: > Thanks Daniel for ur suggestions/help. > > Heard of vgsplit and other stuffs not sure whether that can be > practically used here in this situation. > > Thanks > Karthik > > On Aug 22, 9:18 pm, Daniel Eggleston <egg...@gmail.com> wrote: >> That is a thoroughly inappropriate way to do it. The point of a volume >> group is that the physical volumes (PVs) in the VG are grouped - hence the >> name. These PVs are unavailable to LVs outside the volume group (it is >> self-contained). >> >> That said, it is technically possible (although ill-advised, error prone, >> and probably a performance killer... you have been warned!). In a pinch, >> you can create an LV in vg0, run pvcreate on it, and then run vgextend on >> vg1, adding the new PV to it. >> >> i.e.: >> lvresize /dev/vg0/export [options to control new size] >> lvcreate -n pv_for_vg1 -L [size reclaiming from vg0] vg0 >> pvcreate /dev/vg0/pv_for_vg1 >> vgextend vg1 /dev/vg0/pv_for_vg1 >> lvextend /dev/vg1/something -L [new size] >> >> NOTE: I said this is error prone, and I meant it. In this scenario, vg0 >> MUST be online before vg1 can come online. And vg0 must remain online until >> AFTER vg1 comes offline. You should not remain in this state for a long >> time, it's really a band-aid solution in case you can't take a downtime >> immediately - your next move should be to add disk space & rearrange back to >> independent volume groups. This is pretty much exclusively for the case >> where you planned your storage poorly, and screwed up your size projections. > > -- > You received this message because you are subscribed to the Linux Users Group. > To post a message, send email to linuxusersgroup@googlegroups.com > To unsubscribe, send email to linuxusersgroup+unsubscr...@googlegroups.com > For more options, visit our group at > http://groups.google.com/group/linuxusersgroup > References can be found at: http://goo.gl/anqri > Please remember to abide by our list rules (http://tinyurl.com/LUG-Rules or > http://cdn.fsdev.net/List-Rules.pdf) > -- You received this message because you are subscribed to the Linux Users Group. To post a message, send email to linuxusersgroup@googlegroups.com To unsubscribe, send email to linuxusersgroup+unsubscr...@googlegroups.com For more options, visit our group at http://groups.google.com/group/linuxusersgroup References can be found at: http://goo.gl/anqri Please remember to abide by our list rules (http://tinyurl.com/LUG-Rules or http://cdn.fsdev.net/List-Rules.pdf)
