topic Re: update LS-mirror after NAS vol creation in Active IQ Unified Manager Discussions

update LS-mirror after NAS vol creation

scheckel — Thu, 05 Jun 2025 05:48:39 GMT

Hi,

With cDOT its recomended to have LS mirrors to all nodes from the root volume. Waiting 15 minutes (depending on the schedule) till the new provisioned volume(s) is availible don't makles sense. Maybe there is a mount command to a VC or a unix hosts will happen in the workflow. So has somebody realized this?

so workflow should have additinally following steps, how it is on CLI

or its possible to place this in a embeded command called "update LS-mirror" specifying cluster and vserver:

Find out the root volume of a vserver:

wdflab1::> vserver show -vserver wdflabvs07_fp_infra -fields rootvolume

rootvolume rootvolume-security-style

wdflab1::> vserver show -vserver wdflabvs07_fp_infra -fields rootvolume

vserver rootvolume

------------------- ----------

wdflabvs07_fp_infra rootvol

or use snapmirror show:

wdflab1::> snapmirror show -vserver wdflabvs07 -type ls -fields source-

source-path source-cluster source-vserver source-volume

wdflab1::> snapmirror show -vserver wdflabvs07 -type ls -fields source-path

source-path destination-path

------------------------------------- ------------------------------------------

wdflab1://wdflabvs07_fp_infra/rootvol wdflab1://wdflabvs07_fp_infra/root_vol_m01

wdflab1://wdflabvs07_fp_infra/rootvol wdflab1://wdflabvs07_fp_infra/root_vol_m02

2 entries were displayed.

update LS-set:

wdflab1::> update-ls-set -source-path wdflab1://wdflabvs07_fp_infra/rootvol

(snapmirror update-ls-set)

[Job 3741] Job is queued: snapmirror update-ls-set for source wdflab1://wdflabvs07_fp_infra/rootvol.

watch progress

wdflab1::> job watch-progress -id 3741

Complete: SnapMirror: done [0]

wdflab1::>

Best wishes,

Markus.

Re: update LS-mirror after NAS vol creation

dcornely1 — Thu, 12 Dec 2013 00:28:46 GMT

We dealt with the same problem here. We resolved it by reducing the LS mirror update cycle to 1 minute and I added a 60 second sleep to the No-Op command as the last thing my create volume workflow does. This way the Storage Service we have knows that when the WFA workflow completes the LS mirror update has already occurred and the next step in the process of mounting will succeed.

I did consider inserting a manual LS mirror update into the process but the issue with that is our environment has to be able to accommodate multiple create requests in parallel and if they were all attempting to execute manual LS mirror updates at roughly the same time many would probably fail (or something else I don't want to encounter). The solution really depends on your use cases...

Re: update LS-mirror after NAS vol creation

adaikkap — Thu, 12 Dec 2013 04:27:05 GMT

Hi,

This is great. Would you mind sharing your workflow as a dar file for others as well?

Regards

adai

Re: update LS-mirror after NAS vol creation

dcornely1 — Thu, 12 Dec 2013 06:25:50 GMT

You bet - I'm attaching my volume create workflow. I put this together based on some of the canned workflows that come with WFA so things like the looping mechanism for the export rules I just copied since it works well.

The final command in the workflow is the one I referred to earlier where I just added a 60 second sleep using the Start-Sleep Powershell built-in cmdlet.

Also, here is a description I put together in my documentation for how to add the export rules. Keep in mind that the workflows I develop are for a Web Services environment so they aren't intended for use via the WFA gui which is why all the inputs are just simple strings or numbers. That said, it wouldn't be too hard to modify this flow to be more user friendly from that perspective.

Export Specification Rule is an input that combines all the Export Rules for the Volume. These rules are added only when a new export policy is being created. Each Export Specification Rule is of the form:

<client-specification IP>;read-only rule;read-write rule;superuser rule

Individual rules are separated by an ampersand (&).

For example, the export rule spec '10.10.10.10;ntlm;krb5;sys&20.20.20.20;krb5;sys;ntlm' specifies two export rules:

Export Rule 1) client-specification = 10.10.10.10

read-only rule = ntlm

read-write rule = krb5

superuser rule = sys

Export Rule 2) client-specification = 20.20.20.20

read-only rule = krb5

read-write rule = sys

superuser rule = ntlm

However, the above is only an example to illustrate how multiple rules are passed at one time – for specific values to satisfy the (5) situations below read on.