Just for information ....
Hi,
I have 4 disks : 1 for system and 3 for data with LVM (only 1 vg).
If my system drive burn, Can I read my datas with an other system compiled with LVM ?
Thanks,
Signature · 4 lines
Igor Dumaire www.LTUtech.com - Making Sense of Visual Content ------------------------------------------------
Quoted 4 lines · Igor Dumaire
I have 4 disks : 1 for system and 3 for data with LVM (only 1 vg).
If my system drive burn, Can I read my datas with an other system compiled with LVM ?
Yes. You will need to do a vgscan to find the new disks. Hopefully they will not have the same VG name as another VG on that system.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 2 lines · Previously Andreas Dilger
Yes. You will need to do a vgscan to find the new disks. Hopefully they will not have the same VG name as another VG on that system.
What if they do?
Wichert.
Signature · 4 lines
_________________________________________________________________ / Nothing is fool-proof to a sufficiently talented fool \ | [email protected] http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Quoted 5 lines · Wichert Akkerman
Quoted 2 lines · Previously Andreas Dilger
Yes. You will need to do a vgscan to find the new disks. Hopefully they will not have the same VG name as another VG on that system.
What if they do?
Nothing, originally. Your last "vgchange -a y" should populate the /etc/lvmtab.d directory with the current working volume group data. Even if you have two vg's of the same name, your last one should be the active one.
I had to go back to the original system and do a vgexport <vgname> in order to import it on the new system. I've considered naming vg's after their host (and possibly media type). That way, I'll know I have at least a stub of a unique name for the vg.
As far as keeping VG's separate based on media... I'm torn. It's a simple way of making sure I don't loose data if the IDE disk goes bad -- which has happened to me -- while the SCSI disk remains fine.
Unless I'm using RAID, grouping multiple physical disks together in one VG means I have to pay extra special attention to where the LV's allocate their PE's.
Signature · 3 lines
Chad Walstrom <[email protected]> | a.k.a. ^chewie http://www.wookimus.net/ | s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD
Quoted 5 lines · Wichert Akkerman
Quoted 2 lines · Previously Andreas Dilger
Yes. You will need to do a vgscan to find the new disks. Hopefully they will not have the same VG name as another VG on that system.
What if they do?
Then it will depend on disk ordering which one you get under that name, and the other will be unavailable. vgscan will see all of the disks, but then start checking the UUIDs on the PVs against the list on the "first" disk, and the extra disks with UUIDs that don't match will be discarded.
I don't think there are any likely scenarios with LVM 0.9+ that will cause problems, but since UUIDs were only introduced in 0.9, it may be much harder to handle this in older LVM versions.
You might be able to vgexport the disks from the "other" VG at that time, and reimport it with a different name, but I don't know how reliable that will be (if it even works). LVM has been confused by less. Better to just "not do that" in the first place.
FYI, AIX LVM does not keep the VG name on the disk itself, only a UUID. You also never do something like "vgscan" at boot time to reconfigure the LVM setup. When you attach the disks to a new system, you have to import them (at which point they get a name that is stored in a config file in /etc), and your LVM config is never touched until you change it. When you export the VG, it also doesn't write to the disks, just deletes the config from /etc. This means you don't need to do anything to the VG before moving it to another system.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
Quoted 11 lines · Andreas Dilger
Quoted 5 lines · Wichert Akkerman
Quoted 2 lines · Previously Andreas Dilger
Yes. You will need to do a vgscan to find the new disks. Hopefully they will not have the same VG name as another VG on that system.
What if they do?
Then it will depend on disk ordering which one you get under that name, and the other will be unavailable. vgscan will see all of the disks, but then start checking the UUIDs on the PVs against the list on the "first" disk, and the extra disks with UUIDs that don't match will be discarded.
Worst case would be a temporary disconnect of the PVs belonging to one of the VGs which share the same name. vgscan+vgrename the found one and reconnect the drives and vgscan again.
Quoted 4 lines
I don't think there are any likely scenarios with LVM 0.9+ that will cause problems, but since UUIDs were only introduced in 0.9, it may be much harder to handle this in older LVM versions.
See above.
Quoted 4 lines
You might be able to vgexport the disks from the "other" VG at that time, and reimport it with a different name, but I don't know how reliable that will be (if it even works). LVM has been confused by less.
???
Quoted 11 lines
Better to just
"not do that" in the first place.FYI, AIX LVM does not keep the VG name on the disk itself, only a UUID. You also never do something like "vgscan" at boot time to reconfigure the LVM setup. When you attach the disks to a new system, you have to import them (at which point they get a name that is stored in a config file in /etc), and your LVM config is never touched until you change it. When you export the VG, it also doesn't write to the disks, just deletes the config from /etc. This means you don't need to do anything to the VG before moving it to another system.
Well, actually you can just "vgscan" in the VG without vgexport'ing it in Linux LVM as well. vgexport/vgimport exactly is the clean procedure to make sure that name clashes don't happen!
Quoted 13 lines
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/_______________________________________________
linux-lvm mailing list
[email protected]
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
Signature · 15 lines
Regards,
Heinz -- The LVM Guy --
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Sistina Software Inc.
Senior Consultant/Developer Am Sonnenhang 11
56242 Marienrachdorf
Germany
[email protected] +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-