Qtree quiescing

[vemery999]

Hi,

I have a problem with some of my snapvault relatioships between Windows OSSV and qtree. After a WAN problem or somthing stop the transfert during a syhcnronization job, the relationship become quiescing and no way to come back idle or transfert.

I try a lot of things:

options snapvault.enable off

vol offline vol_name

vol onlie vol_name

options snapvault.enable on

snapvault start -r

I check for network issue.

Nothing....

In the log of OSSV (ossvinfo.exe) and output.txt, I can see:

2011/09/13 13:49:42: INFORMATION : QSM connection accepted from [::1] (inet6)

2011/09/13 13:49:42: ERROR       : Unexpected close getting QSM data

2011/09/13 13:49:42: INFORMATION : QSM connection accepted from 127.0.0.1 (inet)

2011/09/13 13:49:42: ERROR       : Unexpected close getting QSM data

Why 127.0.0.1 ? and why intet6 ?

before the qtree become quiescing, In the same log I can see:

2011/09/13 15:12:23: INFORMATION : QSM connection accepted from 172.22.9.4 (inet)

2011/09/13 15:12:24: INFORMATION : C:\ FAS2040:/vol/vol_name/qtree_name Transfer started between C:\ and FAS2040:/vol/vol_name/qtree_name

So when it's working, the connection come from the IP of my FAS2040. But when qtree quescing, the connection come from  127.0.0.1.

The only workaround I found is to delete the relationship and do a new baseline transfert. But the problem come back after few days.

Any idea to recover a quiescing relationship ?

thanks

Vincent

[p_schmitter]

Ich bin ab dem 27.09.2011 wieder im Büro

Ihre Mail wird nicht weitergeleitet.

In dringenden Fällen wenden Sie sich bitte an Herrn Michael Lengowski

I am back in the office at 09/27/2011

Your mail will not be forwarded.

In urgent cases please contact Mr. Michael Lengowski.

[p_schmitter]

Ich bin ab dem 27.09.2011 wieder im Büro

Ihre Mail wird nicht weitergeleitet.

In dringenden Fällen wenden Sie sich bitte an Herrn Michael Lengowski

I am back in the office at 09/27/2011

Your mail will not be forwarded.

In urgent cases please contact Mr. Michael Lengowski.

>>> vemery999 <xdl-communities@communities.netapp.com> 22.09.2011 17:29 >>>

vemery999 created the discussion

"Qtree quiescing"

To view the discussion, visit: http://communities.netapp.com/message/63893#63893

New Post:

[brauntvr2swiss]

Hi Vincent

I have the same Problem since few days. Do you have found a solution for this?

TIA

Thomas

[chinchilla]

Hi Thomas,

Maybe a silly thought, however - is there enough capacity on the destination volume? Maybe destination volume doesn't have sufficient capacity to rollback the interrupted transfer?

The most informative log to view is snapmirror.log located in etc/log folder on your destination storage system. In most cases when something goes wrong with snapvault you can find the answer there.

Also take a look in your Windows Application log, OSSV posts most errors there.

'snapvault.exe status -l' on the primary (OSSV host) will show the last error.

[brauntvr2swiss]

Hi chinchilla

Thanks for your help.  I have enough Space in the destination Volume (I have checked it).

The Message in the snapmirror log is:

Rollback_Failed (Cannot connect to source Filer)

On the same 2 Volumes I have also a Problem with NDMP incremental Backup with Backup Exec(DUMP: invalid inode ) So I think I have to open Case...

regards

Thomas

[brauntvr2swiss]

Hi chinchilla

It was definitely A sizing Problem. I have resized the 2 Volumes amply. Now It runs like a charm. The BackupExec Problem was a consecutive fault of the quiecsing State I think.

Thanks for your help..

Thomas

[vemery999]

Hi

Finaly: this message in the log comes after launch the "ossvinfo.exe" command to dump the log files before send it to netapp support...., so it was not an issue.

2011/09/13 13:49:42: INFORMATION : QSM connection accepted from [::1] (inet6)

2011/09/13 13:49:42: ERROR       : Unexpected close getting QSM data

2011/09/13 13:49:42: INFORMATION : QSM connection accepted from 127.0.0.1 (inet)

2011/09/13 13:49:42: ERROR       : Unexpected close getting QSM data

My relationships cames quieuscing with a particular firmware of my firewall Fortinet... :-(. After a downgrade, all work fine. But as soon as upgrade my firewall, the relationship comes quiescing.

Vincent

[brauntvr2swiss]

Hi Vincent

In my Case the Problem was the following option:

snapvault.ossv.compression   on

I have changed it to off and since then the quiescing Problem was history 🙂

regards

Thomas

[anirvanl007 · Accepted solution]

To my understanding quiescing is a state that the destination qtree is in.. is because of a few reasons.. very basic of them are:

Snapshot count: if it increase above 255, the destination will always show as quiescing, if it comes to idle and you try an update.. you will again face the issue.

Volume size on destination: If there is not enough space left in the destination, it goes to the same quiescing state.

When you do a volume offline, is the volume becoming offline or giving some error..?

Regards..

Anirvan Lahiri