Showing results for 
Search instead for 
Did you mean: 

Re: VGimport in Linux

Super Advisor

VGimport in Linux



i know in HP-UX how to mount filesystem on 2 node at the same time with RW on node1 and RO on node2

or mounted on second node if node 1 failed. by using vgimport and vgexport for file .... etc


in our case I have 2 node Linux (version 2.6.32-220.el6.x86_64 on 2 node) i want to do the same concept on the HP-UX servers by mounting the filesystem on second node if the main node failed.


How i can do this in redhat linux ? where i assigned the lun's on both node, and i currently using NFS to share this filesystem but i don't need this way because if the node 1 failed i can't reach this filesystem.


i need the same concept on HP-UX like the below steps



# vgexport –v –p –s –m /tmp/map/ /dev/vg01
# rcp ruxerp01:/tmp/map


# vgimport –v –s –m /tmp/map/ /dev/vg01
# vgchange –a n vg01



i hope my questions is clear now :)



Honored Contributor

Re: VGimport in Linux

In Linux, there are no map files... and although the vgexport/vgimport commands exist and sort of look similar to HP-UX, they have a very different function.


In HP-UX, the vgexport removes the VG information from the OS configuration, and creates a map file that can be used to re-import the VG with vgimport. It does not modify the VG metadata on the disks at all.


In HP-UX, the on-disk VG metadata does not include the VG name: an exported VG is a nameless entity, and it can be freely renamed on import. In Linux, VG name is included in the on-disk VG metadata, so an exported VG will carry its name with it. Renaming a Linux VG is a separate operation (the "vgrename" command).


In Linux, the vgexport command marks the on-disk VG metadata. The mark effectively means: "This VG has been prepared for moving to another system. It should not be activated until the sysadmin at the receiving end has checked that the VG name does not conflict with existing VGs. If such a conflict should happen, LVM should prefer the other VG with the same name rather than this one." The vgimport command removes the mark and allows the VG to be activated normally again.


Knowing this, it should be obvious that vgexport/vgimport is not applicable in Linux when setting up shared disks.


Instead, Linux LVM supports hot-plugging. When you have presented the disks to the second node properly (i.e. the kernel has recognized the new /dev/sd* or similar devices), the disks should be automatically recognized by LVM. If they aren't for some reason, a simple "vgscan" tells LVM to take another look at all the disks in the system (unless some disks have been excluded by a filter configuration line in /etc/lvm/lvm.conf).


(Another difference between HP-UX and Linux: In HP-UX, vgscan is kind of scary operation. You should think twice before running it, and certainly backup the existing /etc/lvmtab first. On Linux, vgscan is very safe, and can be used routinely: it will never remove VG configurations that are in use.)


In fact, you may find that you will have a different problem: when a Linux system boots up, it will normally attempt to activate all the VGs it sees. You might want to protect the shared VG somehow, so that it won't be activated until you really want it.


One way to protect a VG from accidental activation is the use of VG tags.

In /etc/lvm/lvm.conf, you can whitelist some VGs that they can be always activated, and then set up a requirement that all the others must have a particular VG tag, or the system won't allow them to activate. You might set up node1 to require the shared VG to have a tag "node1", and node2 to require it to have tag "node2". You can then add and remove the VG tags with the "vgchange --addtag" and "vgchange --deltag" commands.


In this case, the shared VG would normally have the "node1" tag on it, so it would only activate on node1.

If node1 failed, you would first make sure that node1 is really down, then go to node2, enter "vgchange --deltag node1 <vg>; vgchange --addtag node2 <vg>", then activate and mount the VG on node 2.


If you want to mount the same filesystem on two or more nodes, you'll need a cluster filesystem that is designed for that, like GFS or OCFS2. And for those, you need a cluster-wide lock manager to coordinate the filesystem access... which usually means setting up a full cluster.


For regular non-cluster filesystems, even if you mount the filesystem as read-only on the other node, you should remember that both nodes will cache everything they read from the disk. If the read-only node first reads a bit of filesystem metadata (e.g. a directory listing), and then the read-write node changes some of that metadata... then the read-only node will happily combine the stale data in its cache with new data from the disk, which may cause unexpected results. The filesystem driver might panic when it sees that critical filesystem metadata seems to keep "mysteriously" changing on disk. The only way to avoid conflicts like that would be to disable all disk caching for the read-only filesystem, and that will ruin the performance of the filesystem on that node.