Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Absent Member.
Absent Member.
1577 views

MIGGUI and SMDR

Migrating NSS shares from one Novell Cluster to another Novell Cluster. Both clusters are OES11 SP2.

Using MIGGUI, the migration or sync process will not start or authenticate unless I go to the source server and restart the SMDR service, then it runs fine. The issue is that it stalls after 6 hours (it's a 1.6TB volume) and you have to manually restart the process so I never get a full sync. Anyone else run into this? any tuning to the process tricks?

thanks!
Labels (2)
0 Likes
9 Replies
Absent Member.
Absent Member.

Is it the source one that is always stalled? What are the versions of the SMS modules on both ends? Once upon a time, there was an issue with the SMS modules and the solution was to back-rev them. However, I don't recall the exact details at this time.

-- eDirectory Rules! Peter www.DreamLAN.com
0 Likes
Absent Member.
Absent Member.

peterkuo;2322712 wrote:
Is it the source one that is always stalled? What are the versions of the SMS modules on both ends? Once upon a time, there was an issue with the SMS modules and the solution was to back-rev them. However, I don't recall the exact details at this time.


Both are patched to current OES11 SP2, so latest/greatest code. and the same versions across, it's is weird behavior, runs fine, but then at some point it dies. Both source and destination has 8GB ram and is not hitting the swap file. Processor utilization is low. Even did this after rebooting both hosts and offlining/onlining the resource.
0 Likes
Absent Member.
Absent Member.

So is the source server or the destination server that is stalling? Or it is random between them?

-- eDirectory Rules! Peter www.DreamLAN.com
0 Likes
Absent Member.
Absent Member.

more info, the source server shows "Could not start Responder to (IPADDRESS OF DESTINATION BOX) cCide 0xfffeffa8" when trying to restart a sync that stalled, restarted SMDR seems to allow it to restart, but can't find any error logs showing when it dies
0 Likes
Absent Member.
Absent Member.

the source server is the one that needs to have smdrd restarted, if you don't, the error message on the source server is " smdrd[processID] : Could not start Responder to IPADDRESSOFSERVERRUNNINGMIGGUI. cCode - 0xfffeffa8"
0 Likes
Cadet 1st Class Cadet 1st Class
Cadet 1st Class

Is the error occurring at a folder / volume boundary? Or is this a simple Volume to Volume migration that would trigger a single nbackup job? I do not know of that particular error code.

I have seen issues where in dual homed situations the two ends of the smdr pipeline are created on different networks which do not have direct access to each other. This can pass initial validation checks, and then apart later on. But usually that would be very early on in the process. The solution is to ensure that smdr and the source / destination addresses specified are on directly attached or routed network and not going through NAT or some other stuff.

You can start smdrd manually with debug options, this can often reveal whats actually happening. The --debugfilename option allows you to specify the debug output file. This is VERY verbose, you need to choose a location with enough spaceto handle ~1KB of output per file.
0 Likes
Absent Member.
Absent Member.

SITREP: Old cluster on physical hardward (7 yr old IBM Blade Center with HS21 blades)+ DOS formatted NSS shares , New Cluster in VMWARE + GPT formatted NSS Shares. Copying folder from 1 level below volume to folder 1 level below volume.
Both clusters running OES11 SP2 on SLES11SP3
IP range of both clusters is different, but on "same" network (no NAT, same DNS domain). XXX.XXX.17.* vs XXX.XXX.11.*
Sync appears to stall AFTER the file copy portion, manually ending it and restarting it will work ONLY IF smdrd is restarted on the SOURCE cluster.

the smdrd with debug, should it be run on the source or destination?
0 Likes
Absent Member.
Absent Member.

Tried a smaller subfolder separately, seemed to work on and upon restarting the sync I didn't need to restart SMDRD on the source server. Could this be a file size issue? As in over a certain amount of GB's the SMDRD service locks?
0 Likes
Absent Member.
Absent Member.

more info, SLP is also dying on the boxes, restarting that allowed SMDR to rereg the volumes when restarted
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.