gsclvmd and lazy update on powerha


I have read gsclvmd is used on ECVGs to synzronize LVM's ODM on both nodes of the cluster and lazy update process is when the ONLINE node is gone and the second import all VGs  updating its ODM with all changes. but my question is if gsclvmd and lazy update are the same?

Does gsclvmd daemon does importvg VGs on the passive node's ODMs?

Thanks much!
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Hi again,

let me quote from a former conversation of ours:

With concurrent VGs the group services. [i.e. "gsclvmd"] on all nodes are always aware of possible changes in the VG structure (changes in LV size, new LVs - but not new filesystems!) and there is also no need anymore to break reserves (because there are none).

That's what they call Lazy Update or Fast Disk Takeover.

"Lazy Update" is not concisely used by IBM. One time they call "lazy update" the process performed during failover when all previous changes to a VG were made by CSPOC stating that lazy update is unnecessary with concurrent VGs, another time they say that "lazy update" is performed with concurrent VGs and means that no reserves must be broken.

Below I'll refer to the second sense of "lazy update", because that's how I saw the whole thing working, but indeed, IBM docs are not that straightforward.

I should also have mentioned in the quoted text above that the first part (up to and including the phrase in parentheses) pertains to normal cluster runtime and is a prerequisite for lazy update, and that the second part (the "reserves" thing) pertains to a cluster failover situation where the "real" lazy update happens.

The cluster will perform "importvg" only in takeover situations, and only if the VGs are non-concurrent or if there's a mismatch in the actual and recorded VG timestamps for some reason.

Thus, proper functioning of gsclvmd and the presence of concurrent VGs (which are not allowed without a running gsclvmd anyway) are the prerequisites for lazy update, thus gsclvmd and lazy update are not the same, yet closely related.

I found the time to re-read part of the docs, and it seems that the blurs in the manuals concerning lazy update should be resolved like this:

- Lazy Update has as a prerequisite that all changes are made via CSPOC. It's a function of CSPOC and the cluster manager, and is not related to gsclvmd or EC mode. An LVM update is reflected in the passive node's ODM, and the passive node cannot verify this against the VGDA, because it has no access to it (would require EC mode). At takeover time VGDA and ODM timestamps are compared, and only if they differ exportvg/importvg is performed.

- Fast Disk Takeover, on the other hand, requires EC VGs and a running gsclvmd. Here the passive node has access to the VGDA (because of EC mode) and can update its ODM according to what's in the VGDA. The whole thing is triggered by gsclvmd whose main other purpose is inhibiting a varyon to the "active" state which could otherwise be possible because there's no "disk reserve" with EC mode.

IBM sometimes call the disk takeover in an EC environment "Lazy Update" which I think is definitely wrong!
sminfoAuthor Commented:
jee.. believe me wmp... it's really confusing!!  I haven't found which tasks from LVMs do gsclvmd for example... On the other hand lazy_update/fast_take_over I swear it was the same... I have to go home now.. I'll reply on a copule of hours (I have to study tonight! ;)
Bootstrap 4: Exploring New Features

Learn how to use and navigate the new features included in Bootstrap 4, the most popular HTML, CSS, and JavaScript framework for developing responsive, mobile-first websites.

Strange enough, but just this book of all books has some nice explanations on what gsclvmd does -
the ( - fanfare!  - tambour! - rataplan! - ) AIX 6.1 Differences Guide SG 24-7559.

Study chapter 4.10 and have fun!  


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sminfoAuthor Commented:
WMp.. my confusion begans when, at work, we migrate all clusters from ECVGs-2nodes to ECVGs-3nodes-2sites-GLVM.. all problems began here because there's no LVM's synchronization  between nodes... Look an example:

Yo have worked on node1 for 1 year, you have extendlv, create/delete LV, create/delete FS, ect etc... so, all these changes are not syncronize to node2 and node3. (All this was confirmed through PMRs with IBMs)... so, if you stop cluster services without moving it to node2 an node3 just before the stop.. yo MUST exportvg/importvg VGs on node2 and node3 changing RPVs just to synchronize data... believe or not?

Yes, as you hear, unbelievable that an HA application have to be stopped for exportvg/importvg to synchronize all changes between nodes...

So, I wanted to look how powerha/hacmp LVMs syncronization worked.. and that's the questio...

BTW, I have read this chapter of the redbook and, if I don't forget, it talks about changes on the gsclvmd's log (alog)...

And now I think you're right about lazy update is NOT fast disk takeover...

I need to create my own lab with theses clusters to look answers by my own..

>> these changes are not syncronize to node2 and node3 <<

This is quite normal if you neither use CSPOC to make the changes nor have EC VGs.

CSPOC does lazy update, as we know in the meantime, and EC does fast takeover.

If neither of the above mechanisms are used - how should the cluster manager know what you did with the VGs? Only node1 will know, the other nodes will stay on the level set during the first importvg.

>> I have read this chapter of the redbook << 

You should have scrolled down a bit. The chapter which deals with the logs is 4.9.3 ("The gsclvmd daemon log"). Chapter 4.10 ("Group Services Concurrent LVM enhancements") lists various conditions and their consequences (yes, logging is among these consequences, but not only).

Thx for the points! Once you have your own lab we'll turn the tables and I'll start asking you for help.

Best wishes,

sminfoAuthor Commented:
wmp... "the points" are nothing compare with your help and explanations all over these years ago...... This forum, and special with your knowledge,  have help me  to learn, understand and troubleshoot this wonderful OS since from June/2010 when I start working with AIX...

I'll let you know when the lab is OK...

See ya!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.