LVM question : how to merge 2 VGs intoa single one without data loss ?
ZeDeufr
Is there any way to merge 2 PVs belonging to 2 *different* VGs into 1
VG *without* losing data already stored in the 2 PVs ?
I'm working on AIX 5.3 ML4.
I've got 2 different VGs, each with only one PV. Each VGs contains
only one LV/FS (jfs2) + the jfslog LV.
The FS (and the VGs) are big : around 12 Tb each. One of them is
nearly full, the other one is not so full.
The idea is to merge the VGs so I can reduce the FS/LV which is not-so-
full, to later extend the one which is full.
Of course, with the amount of data in play, I'd like to avoid backing
up/restore it.
I've tried to exportvg both VGs then recreatevg with both PVs but it
doesn't work. Any ideas ?
Thanks.
Uwe Auer
Hi,
to my knowledge - no way. There is no offical AIX command or any
combination of LVM commands to achieve what you want. The only way to
get both LVs into the same VG is:
- get a third disk hdisk3
- add hdisk3 to VG1
- create a LV3 on VG1 of exact the same size of LV2 on VG2
- Use "cplv -e LV3 LV2" (after having read man page for cplv)
(But cplv will take really very long on a 8 or 10 TB LV)
In fact, I do not understand why you are not working with more than 1
LV/FS per VG ?
Regards,
Uwe Auer
ZeDeufr
>
> - Afficher le texte des messages précédents -
Thanks for answering.
There is no deliberate choice from us to have only 1 LV/FS per VG.
It's just the way it has been done on that particular server.
Had it been thought of before, we would have created 1 VG for the two
LV/FS, and wouldn't have had any problem reducing one of them to
extend the other...
Now I'm stuck with the current situation, and have to do with it !
If there is no clean way to achieve what I'd like to, I guess we'll
have to backup/restore the data of the smaller of the two FS.
I suppose we could mess with the VGDA using "dd" to try changing the
VGID or something, but I'm not fond of doing this on the production
server, even if it could be proved successful on a test machine (which
I doubt anyway).
Regards,
Frédéric.
Uwe Auer
>>
>> - Afficher le texte des messages pr锟絚锟絛ents -
>
> Thanks for answering.
>
> There is no deliberate choice from us to have only 1 LV/FS per VG.
> It's just the way it has been done on that particular server.
> Had it been thought of before, we would have created 1 VG for the two
> LV/FS, and wouldn't have had any problem reducing one of them to
> extend the other...
> Now I'm stuck with the current situation, and have to do with it !
>
> If there is no clean way to achieve what I'd like to, I guess we'll
> have to backup/restore the data of the smaller of the two FS.
> I suppose we could mess with the VGDA using "dd" to try changing the
> VGID or something, but I'm not fond of doing this on the production
> server, even if it could be proved successful on a test machine (which
> I doubt anyway).
>
> Regards,
Hi,
forget about the "dd" thing. Even if you would be able to figure out the binary
structure of VGDA it would be required to change ODM, LVCB and there respective
references too. There must be a reason why there is no "mergevg" command :-)
PS: Still got not the point, why you are not using *additional* logical
volumes/filesystems to increase your existing structure. Is the directory
structure that flat that you cannot split it up to more than one filesystem ?
Regards,
Uwe Auer
ZeDeufr
>
> >> - Afficher le texte des messages précédents -
>
> > Thanks for answering.
>
> > There is no deliberate choice from us to have only 1 LV/FS per VG.
> > It's just the way it has been done on that particular server.
> > Had it been thought of before, we would have created 1 VG for the two
> > LV/FS, and wouldn't have had any problem reducing one of them to
> > extend the other...
> > Now I'm stuck with the current situation, and have to do with it !
>
> > If there is no clean way to achieve what I'd like to, I guess we'll
> > have to backup/restore the data of the smaller of the two FS.
> > I suppose we could mess with the VGDA using "dd" to try changing the
> > VGID or something, but I'm not fond of doing this on the production
> > server, even if it could be proved successful on a test machine (which
> > I doubt anyway).
>
> > Regards,
>
> Hi,
>
> forget about the "dd" thing. Even if you would be able to figure out the binary
> structure of VGDA it would be required to change ODM, LVCB and there respective
> references too. There must be a reason why there is no "mergevg" command :-)
>
> PS: Still got not the point, why you are not using *additional* logical
> volumes/filesystems to increase your existing structure. Is the directory
> structure that flat that you cannot split it up to more than one filesystem ?
>
> Regards,
>
> - Afficher le texte des messages précédents -
The point is we don't have any free disk space to increase either VG.
That's why I was looking for a way to merge the 2 VGs into a single
one without having to backup/restore data.
The (rather stupid) way it has been designed, we have a full disk
cabinet dedicated to storage (SAN), sliced up into disks attached to
the VGs.
Each of my VG is made of 1 LUN (no other available), filled with 1 LV
taking whole disk space except for the jfslog.
Hope this answers your question.
Regards
Frédéric.
Mark Taylor
to create a new VG / LV / Filesystem and migrate the data, you have no
other option. I am assuming that you have a DR solution and you have
tested the restore of sed data on your DR system, if so, and the data
is ok and not corrupt, then you can blow away the disks and data,
create the config you want to end up with and restore the data ..
NB: if you have considered dd'ing and editing the vgda's over a much
simpler solution as above, then really I think you shouldn't really be
allowed near a computer as its sounds as if you are a bit of a
liability.
HTH
Mark Taylor