System Center SSP 2.0 SP1 (installed on SCVMM server)
System Center Operations Manager 2007 R2 Cu4
NetApp filer - not sure of exact version because the storage guy has just left - but he reviewed requirements and said it was fine
Standard SSP 2.0 provisioning is working fine using the default scripts and templates via SCVMM.
On the SCVMM/SSP server I have the OnCommand Cmdlets installed and added to the host Powershell profile. I have used the NetApp scripts provided and added them to the customised actions in SSP. The SCVMM server has a library share with a generalised VHD and template. All LUNs have been created on the same volume, including the library share that hosts the VHD. For info - the library share is a pass through disk.
When creating a VM in SSP specifying the NetApp ONTapCreateVM.txt and ONTapCreateVMLocked.txt scripts I get the following error;
Operation failed. Exiting progress message processing. Status TemplateCloneEngine::Clone: ValidateVHDDiskPaths failed reason Validate VHD path found that following VHD paths are not on NetApp LUN L:\TemplateVHDs\disk1.vhd
This runs for approx 5 seconds before being generated.
I have attached the WebService.log file.
Appreciate I may not have covered the environment in much detail - but feel free to ask and I'll give more information?
I was able to find a few similarities in the errors and logs to some internal burts. I will see if we can get more details on this but it looks like it may be due to dns resolution, ip , or something of that nature. I've actually seen a similar error like this in the previous 2.1.1 version which turned out to be an issue with the location of my library share on a scvmm vm. Not sure if this is the same thing but will request more info and get back to you.
Yes - sorry probably should have clarified that It is most certainly on a NetApp LUN. Perhaps worth noting that the LUN is attached to the SCVMM server as a pass through disk, and has a single share configured (permissions are ok) with the template VHDs stored their. The location I am attempting to clone too is in the same NetApp volume.
I think we only support the clone process if its a vhd as we can't see inside the pass-through lun but will get somebody to chime in. This sounds similar to the issue I had in my env. Also, just to be sure, we had a issue in 2.1.1 where a restart of the SSP service was required. Can you please confirm?
A pass-thru disk is percieved by windows to be a physical disk. The guest OS where you are running the cmdlets is not aware that this is a NetApp LUN and cannot perform the actions it needs to perform. Try mounting a guest LUN (via iSCSI) and running rapid provisioning against the guest LUN.
This would require the iSCSI network ports to be converted to virtual switches so that the hyper-v hosts and the guest virtual machines could both use the ports on the data network (vNic placed within host OS and vNics added to the library server both hanging of the virtual switch). Can you foresee any issues with this and is this something that you have seen before?
The NICs are the ones currently used just for iSCSI, we have two separate paths to each server each with there own subnet/vLAN patched to switches used just for Layer 2 traffic connected directly to the filers (Server<->Switch<->Filer). Part of the switch is segregated for CSV/Migration but that is on a seperate NIC pair within the server.
So with the NICs being used just for iSCSI the volume traffic would be the same (Just host vs. Host and Guests) as we would be changing an iSCSI host mount disk passed to the VM as a pass through disk, to a disk directed mounted via iSCSI in the guest VM; the only difference I can see would be the overhead of the vSwitch. Should this be seem as a risk within a production environment?
You may see increased latency due to the virtual switch inside of Hyper-V but that's going to be unavoidable unless you deploy a physical SCVMM server or add another dedicated NIC just for the guests to use. SCVMM won't be putting much load on the LUN if you are just using it as a cloning source. If you're doing "traditional" BITS based deployments with SCVMM you will see pretty high read loads on the LUN.
If you check the ""Allow Management Operating System to share this adapter" checkbox, what actually happens is that the host gets a virtualized NIC that it can use. That NIC may have more latency than a "real" physical NIC. If all your VM's are using this NIC for their VHD's, this could reduce the overall system performance.
You will be able to see this in Perfmon. If you look at the logical disk object and average disk latency counters, you should take a baseline now and then compare to running through the v-nic. That will tell you if there is a signiciant impact.
Have two clusters one which we are using the OnCommand scripts within the SSP2 portal and one with normal bits templates via the portal. Using this as a technology demo for management so would be good to start the bits deployment at the start of the demo and then the rapid provisioning half way through and see the rapid still finish first .
Will implement the above solution tomorrow and let you know how it goes.
I implemented the above today - directly mounted the LUN inside of the SCVMM server via iSCSI and put the template VHD in a library share located on that drive. I then created a new template and imported that into SSP 2.0
I now get a difference error message;
Operation failed. Exiting progress message processing. Status An error occured while processing the Create Storage. The requested name is valid, but no data of the requested type was found
The ONTapCreateVMLocked.txt script that it is utilising is running the following line that seems to be pertinent;
I notice this is not using a -mountpoint or any other attribute.
What we are trying to achieve is vhd cloning. The hosts have three CSV's on seperate volumes. C:\ClusterStorage\Volume1 in on the same volume as the library shares LUN and is set on the hyper-v hosts as the default vhd location. We what to get the the stage where the config files are on Volume3 and the vhd's are cloned to volume1.
Any help or pointers on the syntax we need for be great recieved.
This will tell us if we can create a new LUN (we create a 800gb lun and mount it on T: in the first command) and if we can perform a sub-lun clone. What the New-Clone command does is to create a new LUN (which from the log looks like it succeeds) and then performs a sub-lun clone (which Doesn't seem to succeed). If the two commands above work, then we probably have a bug in the SSP script it's self.
Again, thanks for your help in working out the kinks in the beta.