I have heard somewhere that certain versions of Windows aggresively signed all disks it detected, which could cause severe problems in a SAN enviroment. As if a LUN carrying a VMFS datastore was not masked away correctly from a physical Windows server it could destroy it by writing a disk signature in the MBR.
Can anyone confirm if this has been a problem?
And what versions of Windows server that has this behavior? I do not belive they do this anymore, but from what version? 2000/2003?
Even with the Windows 2008 R2 with automounting enabled it did not do anything to do disk. I tried then to bring the disk "online" and that did not do any signaturing to it either. It was just an "healthy unknown partition" in Windows Disk Manager and continued to work as a VMFS store.
But that was an R2 Enterprise, so it would be good to check with other versions of Windows Server too.
It never hurts to disable automount. Me personally, i would never ever leave this enabled when exposing LUNs to it.
If you want to be super save I guess, don't connect to it via the SAN option. Just use the IP method.
I have some memory of this behavior is different between Win2003 Standard and Enterprise Edition. Strange, but perhaps that Enterprise should be more "SAN aware"..?
There are NO differences between versions of Windows server. They only add MORE features, but kernel is exactly the same, behavior is the same.
But that was an R2 Enterprise, so it would be good to check with other versions of Windows Server too.
Yeah what joerg said. NEVER EVER let Windows automount ANY Foreign LUN / Volume. EVER.
That's just not good practice. 2 dissimilar OS should not have access to the SAME Volume at the SAME time. That's not a good idea.
I have some memory of this behavior is different between Win2003 Standard and Enterprise Edition. Strange, but perhaps that Enterprise should be more "SAN aware"..?
There are NO differences between versions of Windows server. They only add MORE features, but kernel is exactly the same, behavior is the same.
So you are saying that it is not correct what a.p. says earlier in the thread?
It would be interesting to really know the behavior of the different Windows operating system generations and also if there is any difference between Standard or Enterprise versions.
Of course it is not a good idea to let any random server access the VMFS LUNs, but sometimes it could be necessary and sometimes it could happen by mistake, so I find it interesting to know what will happen if it is done.
**Updated 11/24/10**
Solved! Ugh. It was Server 2008 UAC. Executing the script as administrator did the trick. Seems that vmware support should have known this and not had me on a goose chase of LUN ID's and reinstalling VCB. Oh well. VCB is supposed to be ending anyway?
This thread gave the answer. Hope it helps you.
http://communities.vmware.com/thread/244650
Has anyone had Server 2008 work as a VCB proxy?
I've been working on a case with vmware where my new VCB proxy will not backup vm's. I am using simple scripts with vcbmounter. This is the same setup I've used the last three years on a Server 2003 VCB proxy. The new proxy is Server 2008 (not R2). VCB setup does say that 2008 support is "experiemental" but I want to keep Server 2008 as it is part of our overall strategy.
What we found is that the old 2003 proxy shows the LUNs as Healthy (Unknown Parition) while Server 2008 shows them as Healthy (Primary Partition). Automount is disabled. I have not changed 2008's behavior of putting disks "online" as the reading I did said I don't need to adjust this.
Anyway vmware says I need to get the LUNS to show as Healthy (Unknown Parition) and to that end; reinstall VCB and represent. I don't have much faith in that but I'll give it a try.
I'll post back here if I get it to work. What is odd is one machine did back up but that is the only one. I did some experiments with backing up vm's that are on the same LUN; different LUNS, Hosts, etc...
I've attached creen shots of Disk Management