After restart my physical drive get deport
Updated: 21 May 2010 | 10 comments
This issue has been solved. See solution.
i am using SF 5.0 with windows2003 R2. i have two physical drives attached. One is primary/boot drive and secondary drive is for replication. when my PC gets restart my 2nd drive gets deport and i haveto import it manually. Why its not being import auto after restart?
Thanks in Advance
discussion Filed Under:
Comments
Maybe it's created as cluster disk group?
This usually happens with cluster disk groups as per article http://seer.entsupport.symantec.com/docs/301123.htm
Can you confirm that this disk group is not created as cluster disk group?
If it's not a disk
If it's not a disk presented using a software iscsi initiator, the only other reason would be due to it being created as a Cluster diskgroup. (Which has auto-import flag disabled)
The next time you import the diskgroup using the VEA gui, make sure you are importing it as a standard dynamic diskgroup and not a cluster diskgroup and see how it goes.
Please mark my post as solution to help others also if it resolved your issue.
Mouse i have not created
Mouse i have not created cluster disk group even while creating the DIskGroup i did not select any check(either cluster disk group or other)
Jay kim i did not select the cluster disk group. i am sending you the picture at the time of importing the DiskGroup
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
Hmm. You said you had 2
Hmm. You said you had 2 physical disks attached. So I expect Harddisk0 (System/Boot) and Harddisk1 in that diskgroup.
But I see two disks in that diskgroup of Harddisk1 and Harddisk2. Do you actually have 2 disks inside that UserData DDG?
(It doesn't matter if you really have 2 harddisks in that DDG, I was more curious as to if this is now the expected / correct info)
Also, you said the second disk was for replication. Is VVR being used for volumes in this diskgroup?
As far as I know, there is a known issuse with SFW 5.1 where a secondary diskgroup with VVR objects inside will not auto import.
We have a private fix for this issue which you will need to call into support for. (Can't guarantee this is the issue till we check logs)
If you have SFW 5.0 installed, I'm not sure if the same issue exists also for it so it may be a different issue.
Are the disk/s over 2TB in size and is MBR? If so, disk will need to be converted to GPT before it'll auto import.
Well, these are just some things I can come up with with my head while I'm at home. =)
Please mark my post as solution to help others also if it resolved your issue.
First of all thanks I
First of all thanks
I converted the disk from MBR to GPT and now my Disk Group is importing auto
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
Very glad to hear that
Very glad to hear that resolved the issue.
Could you mark my last reply as the solution?
It would be easier to see for others also. =)
Please mark my post as solution to help others also if it resolved your issue.
Kim i dont know why today
Kim i dont know why today same problem occuring:(.......i restarted my PC so many times but the DiskGroup importing auto successfully but today this is not happening :(
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
Hmm. It did sound strange
Hmm. It did sound strange that GPT worked when the harddisk is not over 2TB.
I recommend you to call into support as we may need to look at it in more detail.
Please mark my post as solution to help others also if it resolved your issue.
It's a longshot, but worth a try.....
Sometimes a timing issue can occur during bootup when the disks are not ready for import when the vxboot process (part of SFW) attempts to bring the Secondary Disk Group(s) online. This of course is seen frequently with iSCSI configurations because the iSCSI Initiator loads further along in the boot process, so when vxboot attempts to import the Disk Groups, they don't exist yet because SFW hasn't been provided disk access at that point.
Even outside of iSCSI, there are some situations that can still cause a timing issue that could potenitally be avoided by having the Disk Group attempt to import further along in the boot process. I believe you are using internal storage which you wouldn't think could suffer this issue, but it may be worth a quick test to see if that has any impact on your issue. It's a quick test to run and it's very easy to revert back if the issue persists so you return to your current configuration.
1. From a command prompt, run the command: vxdg -gUserData latestart ON (where 'UserData' is the name of your DG).
2. Open the Services Control Panel (start > run > services.msc) and confirm that the Veritas DG Delayed Import Service is set to Automatic.
3. Reboot the system and see if your Disk Group now imports upon reboot.
If the Delayed Import doesn't resolve the issue, run through the following steps to revert your system back to the original state:
1. From a command prompt, run the command: vxdg -gUserData latestart OFF (where 'UserData' is the name of your DG).
2. Confirm that the Veritas DG Delayed Import Service is set to Manual and stop the service or reboot.
If issue persists, I would recommend taking Jay Kim's suggestion of calling into support so they can gather logs and perform a more indepth analysis to determine why this process is failing in your environment.
Cheers,
rjhanley
Thanks rhanley. its resolved.
Thanks rhanley. its resolved. its amazing.
i think Veritas DG Delayed import Services is not only for ISCSI disk drives, its also for physical disk.
Thanks alot friend :)
Any comment will be appreciated. Mark as Solution if your query is resolved
__________________
Thanks in Advance
Zahid Haseeb
zahidhaseeb.wordpress.com
Would you like to reply?
Login or Register to post your comment.