I would like to create a Lvolume on an already written disk.
Main goal is to NOT format data on this disk. Unfortunately, while trying to mount my LV , I've got this error :
linux-qc44:/ # mount -a
mount: wrong fs type, bad option, bad superblock on /dev/mapper/system-DB,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Anyone have an idea ?
Before doing a mount -a, here's what I did :
linux-qc44:/ # pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created
linux-qc44:/ # vgcreate system /dev/sdb
Volume group "system" successfully created
linux-qc44:/ # lvcreate -l 100%FREE system -n DB
Logical volume "DB" created
linux-qc44:/ # lvdisplay
--- Logical volume ---
LV Name /dev/system/DB
VG Name system
LV UUID WcEgQK-7xZB-622K-tSu3-x0AQ-Lzhr-fLgHxE
LV Write Access read/write
LV Status available
# open 0
LV Size 1020.00 MB
Current LE 255
Segments 1
Allocation inherit
Read ahead sectors auto
When you create a LV you also have to create a FS (Filesystem) of some type on the LV to be able to mount it. Look into the command mkfs maybe.
LVs without FS can just be used for things like RAW volumes etc.
thanks for your quick reply.
Unfortunately if Im using mkfs, all preexisting data will be lost.
Let me explain my scenario :
We have two sites.
Site 1 has an AIX connected to a Storage through iscsi protocol. This is the production site. This AIX server use LVM to create VG, PV, LV with no problem.(LV command is formating.
Site 2 (disaster Site) has a second SAN Storage which is receiving mirrored data from Site 1. A second AIX server is attached to this second Storage through iscsi ( this LUN is a data replication from Site 1)
The idea would be to mount the LUN ( which is already populated) on the second AIX through LVM. This is where I get Stuck as I cannot create an LV and mount the system until I do a MKFS !!!!
Is this a normal behavior ? did I miss something ?
The commands you showed etc. is a Linux box. Now it is 2 AIX boxes? They have totally different commands for their LVMs.
Normal behaviour depends. Usually your AIX1 node has exclusive access rights on the storage and so there is usually a reservation on the SAN-volumes. There are scenarios where there are drivers used, that don't handle reservations. Normal behaviour is often to have only 1 node getting exclusive access to your production box. The other node is often just a standby box. But that all depends on how your scenario is set up.
Without knowing that concurrent access from your second node AIX2 is explicit allowed, I would not touch it.
The normal way is to add your LV and FS from the active productive node AIX1.
Maybe you get some more information how your boxes and SAN-access are setup before daring data corruption or problems for the production node AIX1.
You're right this is some Linux Output .
I currently do not have my AIX available, So I've decided to test on LInux. I thought LVM behaviour was the same on both AIX and LInux.
Is the following make sense to you :
Site 1 :
Storage 1 : Volume and LUN presented to AIX 1 only : readwritable. ( LVM was used to create vg, pv, lv on the presented LUN)
Site 2:
Storage 2 : replicated Volume and LUN presented to AIX 2 only : read-only (until mirror is manually broken (disaster recoery scenario).
Suppose disaster recovery occurs, mirror is manually broken : LUN is getting read write attribute and of course Data are already present on the LUN.
HOW do I proceed to mount this LUN to my AIX WITHOUT FORMATING ??
Well what you are trying will surely not work...
If I follow you, the idea is to show via SAN the disk to a remote server ,am I right?
In this case you should not use vgcreate or whatever but make a safe copy using vgexport or exportvg (aix) look at the man pages since I dont have the syntax in mind :
A mistake and you are doomed... I would say in HPUX you would use
vgexport -s -p -m -v mapfile.vgXX /dev/vgXX
using the mapfile you on the remote box can import the vg giving it a newname and hope you mount it read only or use the -e (exclusive) mode
This is what we are to do when using HACMP(AIX) or MCSG (HP)... (but can be done without the soft...)
This is a remote Server on a SECOND SAN . There are 2 replicated SAN. So Volumes ( and LUN) inside SAN 1 is replicated to SAN 2. That's why I don't understand why I have to Format or export something ( as my replication occurs at block level). ??
I don't know why you always talk about formatting.
When you have productive node AIX1 and it's backuped by a standby node AIX2 of which AIX2's storage is a mirror which is at normal times read-only from AIX2 side, then you just don't touch it from AIX2 as long as there is no crash or maintenance needed.
You do not FORMAT. There is no such thing to do that at all. Get rid of that word!
If you keep your cluster maintained, normally AIX2 would know at least all VGs AIX1 knows. If not you can, as vbe already said, just importvg the VGs from the now read-write available storage on AIX2. Also you can maybe just varyonvg them.
Forget that word "FORMAT"!
When storage is available and VGs vary on at AIX2, you can just add a new LV by smit(ty) or mklv + crfs for example.
What we do if a VG changes on one node is, that we get a downtime and varyoffvg it on prod node and just exportvg/importvg it on AIX2 so it also knows/has an up-to-date configuration.
Small hint: There is a switch -L for importvg to learn any changes in configuration compared to what it currently knows; from man importvg:
-LVolumeGroup
Takes a volume group and learns about possible changes performed to that volume group. Any new logical volumes created as a
result of this command emulate the ownership, group identification, and permissions of the /dev special file for the volume
group listed in the -y flag. The -L flag performs the functional equivalent of the -F and -n flags during execution.
...
Then we varyoffvg on AIX2 again and give it back to AIX1 so production can continue at times.
No offense but if you feel uncomfortable in HA/CMP environment or if you are still a bit unfamiliar to AIX and LVM etc. I suggest you get another co-worker that knows his way around with you when working at such a cluster since it is easy to break something. Really not meant as offense but just to point out how sensible this is.
Or if possible, test it out at some test cluser first to become familiar with it.
You want to have an HACMP functionality without the software (otherwise you would have sai "we use HACMP") - But that doesnt change what Zaxxon and I have explained:
A disk or PV is useless if you dont know its structure (and so you create one!) to be able to "share" the data on it - Since UNIX takes care of the writing to it, only one can access in RW at any time - That is why you have the exclusive mode - to let the OS know it is a shared disk, for this both server have to know the the content of the VG ( the PVs and LVM structure) that is why you DONT CREATE a new one (server 1 did that...) but importvg.
What we are saying is that server2 should already be aware of the VG and you, to mount its content only have to varyonvg, zaxxon will correct me if I didnt get it right...
@vbe: That hits it.
There is also concurrent access to storage in clusters possible to be configured, but it seems that isn't the case here. All of our clusters which are 2 node clusters have due to reservation only access to 1 storage at a time. Writing the mirror is done by SRDF on our EMC system, by AIX mirror on our part of our Clariions and SAN Symphony at the other half of Clariion storage units.
We only have concurrent acces on Heartbeat devices.
