Antimail

Not from Safari...

hi
I've got a peculiar problem on windows server 2003.
At host A, I have a consistent NTFS source volume X(with a mountpoint) on a virtual disk on the disk array. Im creating an array based snapshot X" of X and make that visible to a different host B. At host B, after a 'Rescan disks', i could see the 'physical drive' but not the corresponding NTFS volume. The mountvol listing doesnot show that volume alone. Even after half-an hour, the system is in the same state. When analysed using winobj and dumpdiag tools, we found that the "harddiskvolume" is hooked on to the physical drive object but the harddiskvolume doesnt have any mountpoints associated to that.why is it so?
TIA
Vasanthi

Hi Vasanthi,

First of all, I would like to recommend you to contact Microsoft PSS to solve this type of issues. Usually figuring out this type of problem requires some back-and-forth communication, and avoids guess work on each side (that would delay the investigation).

Anyway, I'll try to respond the best I can:

>>> When analysed using winobj and dumpdiag tools, we found that the "harddiskvolume" is hooked on to the physical drive object but the harddiskvolume doesnt have any mountpoints associated to that.why is it so?

It looks like you are creating a non-persistent VSS Hardware snapshot. (with VSHADOW.EXE tool, you can get the same effect by just specifying the volume: VSHADOW X:)

Non-persistent hardware snapshots do NOT have a volume name by default. This is why you do not see it by running MOUNTVOL.EXE, because the mount point manager did not get notified about the snapshot volume device.

That said, non-persistent snapshots DO have a volume device (in the form \\?\Device\HarddiskVolumeNNN) but not a dedicated volume name (in the form Volume{GUID}) and not a drive letter/mount point path.


Solutions?
1) Create a persistent shadow copy instead (not a non-persistent one). I would strongly recommend this solution. In fact, this is the recommended method of creating VSS Hardware shadow copies - because you don't lose the snapshot device if you accidentally reboot the machine. With VSHADOW, you need to pass the additional "-p" option (VSHADOW -p X:). Altyernatively, with the VSS API, you need to pass the VSS_CTX_NAS_ROLLBACK flag in SetContext)
2) Expose the shadow copy locally. You can do this by using the ExposeSnapshot API, or by using VSHADOW (see the -el command-line options)

hi
Thanks for the reply.
I dont use VSS/VDS apis. I do create "array" based snapshots and not VSS snapshots. And this problem is infrequent and happens when this experiment is done frequently.

In such a scenario of non-usage of VSS/VDS apis, can you please tell me whats preventing the mountmanager to get notified about such a volume arrival?

TIA,
Vasanthi

I can't think of any reason of why this interaction with mount-point manager would fail. Maybe the snapshot contents is inconsistent as you create the snapshot without any OS integration?  

Anyway, I would strongly recommend you to use a VSS-based creation of hardware snapshots in your array.

Advantages:
1) This is a supported scenario both by Microsoft and the vast majority of hardware vendors. If something doesn't work you can always delegate the troubleshooting to the support department, and they will be happy to follow up.
2) There are standard tools to create shadow copies, shipped both by Microsoft or third-party partners.
3) The VSS technologgy is pretty solid. Hardware snapshot creation is integrated with the operating system starting with Windows Server 2003, and it interoperates well with various storagge solutions (like multipath, iSCSI, boot-from-SAN, etc) and also with applications (SQL, Exchange, AD, etc)

Thanks, Adi

PingBack from http://drinksnotdrugsblog.info/antimail-new-livecom-launched-with-screenshots-on-vista/

PingBack from http://drinksandbirthdaysblog.info/antimail-new-livecom-launched-with-screenshots-on-vista/