pvries's Posts

I have a new environment, green field installation of vSphere6.5 on HPE blade c460 gen9 (on the HW compatibility list). 2sites, 2PSC, 2VCSA, 12 hosts and I have the same problem in both sites. I ran the command on all my 6.5 hosts (installed with the HPE custom ISO from 11/18/2016 and updated with VUM to 6.5d)    Authorization Model: password    Enabled: true    Loglevel: warning    Port: 5989    WSManagement Service: true So it seems to be enabled on my hosts. Then I tried the second method in unregistering the service in the new VCSA6.5d but this cis.vws.servicename does not even exists in both my VCSA's! What can I do? this environment is supposed to go in production but I can't without the HW monitoring. This is kind of a (very) big bummer which I did not expect from VMware.

Thanks guys. I already downloaded and installed the 2.0.0.120417 version from the IBM FTP site. The arrays are discovered now and VMs can be protected, however performing a failover drops an error in step 8 when making the replica read/write: Step 8. Change Recovery Site Storage to Writeable. Error: Failed to promote replica devices. Internal error: std::exception 'class Dr::XmlValidateException' "Element 'TargetGroups' is not valid for content model: '(TargetGroup,)'". Failed to promote replica devices. I must dive into this further because we are using Global Mirror Volumes with changes volumes which are not supported by the SRA. Only either Metro mirror or normal Global mirrors are supported. This was a Global mirror. But indeed we are getting somewhere, an official release will foloow soon i hope. Thanks for notifying the bug also, is wasn't aware of that, will take action soon.

Hi, thanks for your suggestion. I know this FTP site and indeed that it seems they have put a newer SRA v2.x which is for SRM 5.x (where the v1.2.x versions are for SRM 4.x). However I downloaded the IBMSVCSRA_v2.0.0.120116 posted on january 23rd but it is not working. The error "SRA command 'discoverArrays' didn't return a response." remains. I already increased the time out setting suggested by several sites. So still no luck here. I have a so called PMR with IBM, it is a support case and they were referring that I could request a beta end of March 2012. I did ofcourse, still waiting for a reply.... Peter.

hi kopper27, No, in the SRM 5.0.1 update the same SRA version (2.00.11725) is presented which only supports the 6.2.x firmware, still not the 6.3.x version. After more than 3 months there is still not a supported SRA available for the v7000 6.3.x firmware code. If someone has a beta, please share. Peter.

Hi rterra, hello Duncan (how are you btw?) I had the same problem as described above when upgrading to U4 from a native U3 installation. I have a Proliant ML110G5 with a ICH-9 SATA controller, I know it´s not on the HCL but it runs ESX35U3 just fine. What I have found out is the following. Since U4 has added support for SATA ICH-9 and ICH-10 controllers it is now important that your SATA controller is in the list of supported SATA controllers, this actually will be a short list sinds the SATA support has just been added to the ESX installation. My controller isn´t in the list so I had to go back to U3 (fresh install). During this install I noticed that the installation gave me sda´s instead of the hda´s which U4 was giving me. Have a look at my partition table: U3 partition table: Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 60801 488383968+ fb Unknown Disk /dev/sdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 13 104391 83 Linux /dev/sdb2 14 650 5116702+ 83 Linux /dev/sdb4 720 30401 238420665 5 Extended /dev/sdb5 974 30401 236380352+ fb Unknown /dev/sdb6 720 788 554179+ 82 Linux swap /dev/sdb7 789 973 1485981 83 Linux Partition table entries are not in disk order Disk /dev/sdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 60801 488383968+ fb Unknown U4 partition table: Disk /dev/hdc: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 1 60801 488383968+ fb Unknown Disk /dev/hda: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 13 104391 83 Linux /dev/hda2 14 650 5116702+ 83 Linux /dev/hda3 651 719 554242+ 82 Linux swap /dev/hda4 720 30401 238420665 5 Extended /dev/hda5 720 973 2040223+ 83 Linux /dev/hda6 974 30401 236380352+ fb Unknown Disk /dev/hdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 1 60801 488383968+ fb Unknown So in U4 the Linux part, disk and partitioning, is showing the same information, only the ESX part is missing native SATA drivers for my controller so no storage adapters. I assume that because U3 is still using something like a SCSI emulation, the storage adapters are shown (as SCSI controllers). The added support of native SATA in U4 (and removing the sda´s from my system) has resulted in not showing the storage adapters in my case. Regards, Peter.