- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: transferring SAN-based filesystem to a new ser...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 06:32 AM
тАО08-11-2004 06:32 AM
One way I can move the filesystems is to do a vgexport on the original system, and a vgimport on the new system. However, it seems to me that I have to do a lot of legwork because the underlying PV paths will most likely be different between the two systems, and I have to make sure the PVs stay within the same volume groups. Or I can I just do a vgscan to do the dirty work and figure out which PVs go into which VGs?
Also, I'd like to leave the volume group information alone on the original system, just unmount the file system and inactivate the VG. This would allow me to manually fall back in case of system failure. However, what concerns me is that if the old system is rebooted, it will automatically try to activate the VG anyway, which I'm afraid may cause corruption. I can stop it from mounting the filesystems by editing /etc/fstab, but I don't know how to stop it from activating the volume groups, or what problems this may cause.
Thanks
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 06:39 AM
тАО08-11-2004 06:39 AM
SolutionYou can do a vgexport with -s option. This way the map file will also contain the VGID. So you dont have to mention the PV names in the RP4XXX even if the PV paths are different
From N4000
# vgexport -p -v -s -m VG01.map /dev/vg01
# rcp VG01.map myrp4xxx:/root/
Repeat the above process for all the VGs
# vgchange -a n /dev/vg01
in RP4XXX (after the disks are made visible to the RP4XXX)
# mkdir /dev/vg01
# mknod /dev/vg01/group c 64 0x010000
# vgimport -v -s -m /root/VG01.map /dev/vg01
Now to disable N4000 from activating the VG at boot up
# vi /etc/lvmrc
AUTO_VG_ACTIVATE=0
custom_vg_activation ()
{
/sbin/vgchange -a y -s /dev/vg00
}
#
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 06:41 AM
тАО08-11-2004 06:41 AM
Re: transferring SAN-based filesystem to a new server
# vgexport -m /tmp/vg??.map -p -v -s /dev/vg??
That will create the map file and the -s will put the VGID at the beginning of the map file. This is important in the vgimport step.
Now take the map file and transfer it to your new machine.
Make sure it can see the SAN disks and that ioscan shows that all of the /dev/dsk/* device files have been created.
Now create the VG files:
# mkdir /dev/vg??
# mknod /dev/vg??/group c 64 0x0?0000
Where the ? is the unique minor number for the VG. If you want to see what has been used: 'll /dev/vg*/group' and look at the 0x0?0000 strings.
Now import your VG.
# vgimport -m /tmp/vg??.map -v -s /dev/vg??
The '-s' on the vgimport tells the system to look for ALL disks, no matter what their path with that VGID and import them into this VG.
I have done this several time and never had any trouble at all.
On your old system, you could keep a copy of the vg??.map file, umount all the filesystems, deactivate the VG and export it, and if you need to, just recreate the /dev/vg?? directory, the /dev/vg??/group file and reimport the VG.
It wouldn't take you long at all. That way you don't have to worry about the VG being activated inadvertently on the old machine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 06:43 AM
тАО08-11-2004 06:43 AM
Re: transferring SAN-based filesystem to a new server
vgexport -pvs -m /etc/lvmconf/vgname.mapfilexx /dev/vgname
Make sure everything is unmounted and on the old server run:
vgchange -a n /dev/vgname
If your old system is not running MC/SG you can simply go in and rem out the lines in your /etc/fstab..should be okay on old now.
Then rcp this mapfile file over to your new server and do your import..
mkdir /dev/vgname
mknod /dev/vgname/group c 64 0x_ _0000
vgimport -vs -m /etc/lvmconf/vgname.mapfilexx /dev/vgname
vgchange -a y /dev/vgname
- or if you want to exclusivity then -:
vgchange -a e /dev/vgname
Again if your not in MC/SG environment where you would control this via pkg scripts, then just put the entries into your /etc/fstab and your ready on your new server.
HTH,
Rita
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 06:55 AM
тАО08-11-2004 06:55 AM
Re: transferring SAN-based filesystem to a new server
Make sure the existing N4000 is running at least the DEC2003 or JUN2004 HWE & Gold Packs (I assume you are running 11i already right?).. Then just do an Ignite Backup of your N4000... Set up the new rp4xxx server, hook up the FC connections.. make sure the new HBA's on this new server is registered on the SAN, and simply Ignite restore back...
If you're using a new install of HP-UX on your rp44xx system, then I suggest you do the vgexport/import method.. create a map file containing the VGID for each non-root VG .. ie. vgexport -p -v -s -m vgxx.map /dev/vgxx
Favourite Toy:
AMD Athlon II X6 1090T 6-core, 16GB RAM, 12TB ZFS RAIDZ-2 Storage. Linux Centos 5.6 running KVM Hypervisor. Virtual Machines: Ubuntu, Mint, Solaris 10, Windows 7 Professional, Windows XP Pro, Windows Server 2008R2, DOS 6.22, OpenFiler
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 07:01 AM
тАО08-11-2004 07:01 AM
Re: transferring SAN-based filesystem to a new server
Apparently, vgexport -s solves the move issues, because vgimport will find the vgid stamped on the PV's and take care of everything else.
By modifying /etc/lvrmc, I can control what gets activated at boot. I'll probably so something overly sophisticated like see if there is a file system mounted in /etc/fstab before activating a VG.
Thanks all!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 07:07 AM
тАО08-11-2004 07:07 AM
Re: transferring SAN-based filesystem to a new server
It has the potential to render your system unbootable.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-11-2004 06:59 PM
тАО08-11-2004 06:59 PM
Re: transferring SAN-based filesystem to a new server
As rp4xx is a pretty new server around I would however take care that:
1)PDC firmware is last
2)patching level (inc. HW enable patches) are really new (2004 suggested)
3)checking FC HBAs support + FC patches (fabric support,new HBAs etc).
rgs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО08-04-2006 09:50 AM
тАО08-04-2006 09:50 AM