cswaters1's Posts

Just to close this off, I back rev'd the Solution Enabler to 7.0.1 (which was out around the same time that SRA 1.4.0.15 was released) and this seems to have fix all the issues. C... See more...
Just to close this off, I back rev'd the Solution Enabler to 7.0.1 (which was out around the same time that SRA 1.4.0.15 was released) and this seems to have fix all the issues. Could be useful for someone moving forward! Thanks, Craig.
Hi was running solution enabler 6.5.3.0 and SRA 1.3.0.8 all fine until we upgraded one of our SANs to CX4 with FLARE 29. So I went and upgraded both sites to Solution Enabler 7.1.2 and SRA 1.... See more...
Hi was running solution enabler 6.5.3.0 and SRA 1.3.0.8 all fine until we upgraded one of our SANs to CX4 with FLARE 29. So I went and upgraded both sites to Solution Enabler 7.1.2 and SRA 1.4.0.15 and I get the attached error message. When I try and rescan the array I get an error message. When I try and run a test failover I get communication with storage errors. Any suggestions? Thanks, Craig.
BUMP... Come on anyone?? I checked the support matrix and only VC2.5u5 is currently supported with Site Recovery Manager for VI3. Can someone please comment? Thanks, Craig.... See more...
BUMP... Come on anyone?? I checked the support matrix and only VC2.5u5 is currently supported with Site Recovery Manager for VI3. Can someone please comment? Thanks, Craig.
Just checked the SRM 101 compatibility matrix and VC2.5u6 is not currently listed, can someone at VMware comment on this? Thanks, Craig.
Just to give everyone a heads up... The problem was related to .vmx file. I had problems with these VMs originally as they had incorrect settings in the .vmx file (workingDir = needed to ... See more...
Just to give everyone a heads up... The problem was related to .vmx file. I had problems with these VMs originally as they had incorrect settings in the .vmx file (workingDir = needed to be changed to "." ). After going through the vmware-dr logs (should have got off my arse and done this in the first place instead of just throwing out a question before doing some research) I noticed errors with the VM being discovered during the add VM to inventory process. There errors were again related to the contents of the .vmx file (something about suspend.Directory not being a valid vmfs volume). So to fix it I did the following: I just removed the VM from inventory, renamed the folder where the vmx file resides, created a new VM with the same name and a new folder on the same Datastore, moved all the files to the new VM folder (except .vmx, vmsd, vmxf) Added the VM into inventory, added the disks to the correct scsi id's Bought up the VM and confirmed it was all good, deleted the renamed VM folder on the datastore. At this point SRM found the new VM and I was able to protect it like all other VMs in the protection group. Thanks for watching this space and thanks Lee for contributing! Craig.
Hi Lee, Apologies for the delayed response been attending the vForum conference over in Sydney. I'll try and make my question a bit clearer... So I've sucessfully completed a failover, n... See more...
Hi Lee, Apologies for the delayed response been attending the vForum conference over in Sydney. I'll try and make my question a bit clearer... So I've sucessfully completed a failover, no problems everyone is happy I've completed the reconfiguration steps ready for failback and all SAN related configuration looks fine. My issue is that there are a couple of VMs which exist in the recover site (they failed over fine) that when I create the protection group at the old recovery site / new protection site are missing, other VMs that use the same datastores / storage are discovered when I create the protection group?!? I just don't understand it... Can someone make any suggestions on how to fix these missing VMs, is it something to do with missing information in the .vmx ? Thanks in advance for your help, Craig.
Hi, I've successfully completed a failover without any issues, I'm now at the point where I start the failback procedure. I've unregistered the protected VMs at the old protection site, I'... See more...
Hi, I've successfully completed a failover without any issues, I'm now at the point where I start the failback procedure. I've unregistered the protected VMs at the old protection site, I've removed the protection groups that have been implemented at the old protection site, I've removed the placeholder VMs at the local non-replicated LUNs at the old recovery site, I've reconfigured my array (CLARiiON with MirrorView/S), I rescan the array and all disks are present and accounted for, My Invetory Mappings are reversed, I now come to create the protection groups, but some of the VMs are not listed in the datastore group, they're just missing... Any suggestions??, I have about 2-3 VMs which are never visible when I create the protection group, they look fine, they are on the correct Datastores, they don't have any CD-ROMs attached, nothing is obviously wrong... I've tried rebooting/restarting the VC / SRM servers/services but no change. Can anyone suggest a resolution? Thanks, Craig.
Wow, I'm really surprised about that, normally when I post these links they are good Seriously, only because its you Mike I've enclosed the file below (this is from a Northerner from Cleet... See more...
Wow, I'm really surprised about that, normally when I post these links they are good Seriously, only because its you Mike I've enclosed the file below (this is from a Northerner from Cleethorpes living in Melbourne, Australia). Cheers, Craig,
Yes it is... Just found the following - could be of use to others, here is the link for EMC's release notes for Mirrorview SRA 1.4.0.15. If you don't have access then get in contact with y... See more...
Yes it is... Just found the following - could be of use to others, here is the link for EMC's release notes for Mirrorview SRA 1.4.0.15. If you don't have access then get in contact with your local EMC rep and ask why? Thanks, Craig.
We're using VI3.x, solution enabler 6.5.30 and SRM 1.01-patch4 as I understand it the new Mirrorview SRA 1.4.0.15 you refer to is only compatible with vSphere and SRM 4.0? Can someone commen... See more...
We're using VI3.x, solution enabler 6.5.30 and SRM 1.01-patch4 as I understand it the new Mirrorview SRA 1.4.0.15 you refer to is only compatible with vSphere and SRM 4.0? Can someone comment on this / provide clarity? Thanks, Craig.
Just wanted to provide the solution to this. I noticed that the SCSI Target 0 for each ESX hosts only listed a single path, so I looked at the FC Zoning configuration but all looked fine... ... See more...
Just wanted to provide the solution to this. I noticed that the SCSI Target 0 for each ESX hosts only listed a single path, so I looked at the FC Zoning configuration but all looked fine... Basically the SPB was the answer, the ESX hosts are configured with a single HBA in this POC, for some reason the path to SAN port B-5 was assigned to the management LUN only, I edited the Host Connectivity Status, selected SP-Port B5 and hit the reconnect button. I then went to the ESX host in VC and rescanned all LUNs, this fixed the problem, both SCSI Targets listed all paths to all (Meta)LUNs / Snapshots. All good, thanks to those who viewed / replyed to this post.
Thanks for your reply BobbyTPI, Yes, I don't get it, everything looks fine, the same config with a simple implementation which works fine, I've even checked that the snapshots are created in... See more...
Thanks for your reply BobbyTPI, Yes, I don't get it, everything looks fine, the same config with a simple implementation which works fine, I've even checked that the snapshots are created in the reserve LUN pool on the SAN (which they all are) there just seems to be an issue when presenting them to the ESX hosts. I've looked at the HLU's for each LUN/snapshot until I'm blue in the face, no config issue there, theres about 19 MetaLUNs/LUNs and 19 snapshots... Any suggestions anyone?
mmm. One thing I have just noticed is that all the snapshot LUNs that fail to mount are all on SPB of the CLARiiON array. Interesting.
Hi, I've set up a simple test environment with a single VM, datastore etc which worked fine, I'm now testing a failover with about 19 LUNs and about 50 VMs. vCenter 1.01 patch 4 SRA Clarii... See more...
Hi, I've set up a simple test environment with a single VM, datastore etc which worked fine, I'm now testing a failover with about 19 LUNs and about 50 VMs. vCenter 1.01 patch 4 SRA Clariion v1.3.0.4 2 x VCs servers 2 x SQL servers 2 x CLARiiON SANs Mirrorview configured and SANs replicated, Snapview configured for each LUN with VMWARE_SRM_SNAP Setup looks fine, My problem is that when I hit test, the storage gets mounted to my recovery site, but about 5 of the LUNs are missing...? SRM conifiguration looks fine... Any suggestions? I've uploaded the logs and look forward to your response. Thanks, Craig.
The problem with a clone (for me) is that it's a point in time copy, any objects (computers, user accounts / groups etc) that are created after the clone are given a unique GUI (which will be dif... See more...
The problem with a clone (for me) is that it's a point in time copy, any objects (computers, user accounts / groups etc) that are created after the clone are given a unique GUI (which will be different between DEV and PROD), which makes the VMs different and would require us to re-clone the VM again on a regular basis to keep them like for like. What would be really useful is a 'read only' linked clone that would get changes from the PROD AD (source VM) as they occur and present these to DEV (but I guess that then you wouldn't be able to write changes from DEV, but this would be OK as long as the object (computer, group, user etc) already existed in PROD.... Thanks for all your feedback, I guess I'll have to manually keep recreating the clone on a regular basis to keep DEV in sync with PROD. Craig.
As stated previously, the production AD is already a VM - granted, P2V is not recommended but there is no real issue in cloning an AD server, as long as the clone is isolated. The purpose of t... See more...
As stated previously, the production AD is already a VM - granted, P2V is not recommended but there is no real issue in cloning an AD server, as long as the clone is isolated. The purpose of this post is to provide a mechanism to keep the Dev Environment clone of AD in sync with the original Prod AD VM (keep in mind Dev is completely isolated and will typical have other cloned production servers in it using the same IP Addresses etc as Prod.) Thanks for the links Edward, I'll start the research, my 'challenge' if you like is that our Prod and Dev VMs live on different ESX Clusters but in the same VirtualCenter... Has anyone tried this out using a Linked Clone? Can anyone recommend an approach? Thanks, Craig.
Can you recommend some good reading on the linked clone technology? I guess the original and the linked clone would have to exist on the same ESX host? Thanks, Craig.
Thanks for your reply Edward, So would I need Lab Manager to use a 'Linked Clone'? Or is it possible to do this using VI35? Regards, Craig.
My AD environment is already virtual... But that is not what this question is really about. I want an automated way to create a one way replication of changes in Production AD into DEV AD so t... See more...
My AD environment is already virtual... But that is not what this question is really about. I want an automated way to create a one way replication of changes in Production AD into DEV AD so that when we Develop new applications, any changes we make in PROD are there in DEV. We originally P2V'd our production AD servers and then V2V'd them to DEV (so they have the same hostname/ IP etc), the problem is that as Prod changes we have to refresh DEV, which is growing seperately to PROD. Any suggestions? I know Lab manager enables you to snapshot VMs for different environments but wanted to know if there was something else out there... Can I use Lab Manager to snap our production AD and use this as a pointer for DEV? Thanks, Craig.
Not sure where to post this so I'll try here. So, here is my problem: We currently have 3 environments PROD, STAGE and DEV and we typically use a DEV-STAGE-PROD lifecycle for new applicatio... See more...
Not sure where to post this so I'll try here. So, here is my problem: We currently have 3 environments PROD, STAGE and DEV and we typically use a DEV-STAGE-PROD lifecycle for new applications being developed. We use AD for security accounts / groups in PROD and have a seperate install in DEV (I've been using LDAP imports to import new user accounts / groups etc from PROD to DEV but this is manual). When we provision a system in DEV we typically rebuild in PROD, but any GUIDs from AD accounts etc are different. What would be great is some way to sync / partition AD from Prod to DEV and allow any AD users/groups created in PROD to also be available in DEV. Has anyone got any ideas on how I can keep these environments in Sync? Any suggestions? Thanks, Craig.