EMC SW: VNX Operating Environment (OE) for File 7.1
Environment:
Product: VNX/Celerra
Problem:
Customer wants to add a vCenter Managed ESX Server via the Hypervisor Information Configuration Wizard in Unisphere. There is a connectivity error as soon as the IP address and credentials are entered.
Problem:
Error message:
There has been an error connecting to the server.
Connect to Virtual Center Server 'x.x.x.x' failed.
The default installation of vCenter 4.x used (self-signed) RSA 512 SSL encryption. VNX (may) require 1024 bit encryption, and if so, VNX broke our vSphere integration with storage. Our CX240 can still integrate with our vCenter just fine while our VNX cannot.
Be aware that suggestion offered above will break all communication between Virtual Center and the ESX(i) hosts. You will have to disjoin all hosts, update certs, and rejoin them after you put the new cert on Virtual Center -- all because of a code change on EMC. The amount of work that this requires on the VMware side is prohibitive in large environments, and the period where you have hundreds of unmanaged VMs is unacceptable in production environments. In any event, do not contemplate the above solution without a _knowledgable_ vmware engineer present. And have your resume up to date.
I am having the same issue since upgrading VNX unified code. Block is at 05.32.000.5.008 and file is at 7.1.47-5. Unisphere looks to be 1.2.0. What versions are you running. Replacing VCenter server certificates is not an option for us either. How can this be fixed from the VNX side, since it is what broke it? I did notice a new version of both block and file code is already available. I really don't want to perform another code upgrade to fix this issue, if it even does...
Even more fun when you have distributed switches on your vCenter. Tried replacing the certificates on the ESX hosts but this result in HA being broken so going back to the drawing board.
OPP_LTD makes a good point (not sure what the dvSwitch has to do with it). HA is implemented at the cluster level, and you can turn vCenter off and HA will still run fine because the hosts are monitoring each other and know where all the VMs are accross the cluster. It is entirely possible that HA is using the original certificates they obtained during installation to communicate for HA purposes. Messing with host certificates is not something I'd do, personally.
Still the article mentioned above deals with replacing the vCenter certificate (which will break all communication to hosts), The hosts will, in some manner or another, need to accept the new certificate from vCenter. If this was a right-click operation that would be fine, but it's not. You probably will be removing each host from inventory, and rejoining it to vCenter after upgrading the certificate. The question in my mind is, will the host accept a different certificate for vCenter.my.org when it already has the old one registered? Probably not just by providing the root password when re-joining it. I'd want vmware to do this in a lab before I'd mess with any certificates at all.
The real fix is for EMC to fix their code which broke vSphere integration on the VNX. There are indications in our testing from the VNX that there is no communication at all to vSphere, and that the level of encryption might be moot.
I believe this change is due to a recent update by microsoft that also changes the default behavior in the same way. I don't think there will be a fix, and if you update your vCenter Server running on Windows with the hotfix (http://support.microsoft.com/kb/2661254) you will also run into the same problem (VNX or not).
I also believe that this only effects people who upgraded from vSphere 4.0. I'd have to double check this, but i remember reading that fresh installs starting with 4.1 used a 1024 default key length.
Our VCenter / Unisphere integration broke after upgrading from Flare 31 to Flare 32 on a block only VNX5500. I suspect when it was originally setup, the "Bypass Certificate Verification for VMWare Infrastructure" box was checked. This box doesn't exist anymore and I don't think asking our VMWare team to replace their certs and re-import 120 hosts is a very nice fix.
dynamox
9 Legend
•
20.4K Posts
0
October 3rd, 2012 08:00
There has been an error connecting to the server.
Connect to Virtual Center Server 'x.x.x.x' failed.
Certificate Verification Error: unsupported certificate key size, minimum accepted key size is 1024 bits.
OPP_LTD
23 Posts
0
October 3rd, 2012 09:00
ah thanks! will give it a try
Disked
2 Posts
0
October 3rd, 2012 11:00
The default installation of vCenter 4.x used (self-signed) RSA 512 SSL encryption. VNX (may) require 1024 bit encryption, and if so, VNX broke our vSphere integration with storage. Our CX240 can still integrate with our vCenter just fine while our VNX cannot.
Be aware that suggestion offered above will break all communication between Virtual Center and the ESX(i) hosts. You will have to disjoin all hosts, update certs, and rejoin them after you put the new cert on Virtual Center -- all because of a code change on EMC. The amount of work that this requires on the VMware side is prohibitive in large environments, and the period where you have hundreds of unmanaged VMs is unacceptable in production environments. In any event, do not contemplate the above solution without a _knowledgable_ vmware engineer present. And have your resume up to date.
Train1
1 Message
0
October 3rd, 2012 12:00
I am having the same issue since upgrading VNX unified code. Block is at 05.32.000.5.008 and file is at 7.1.47-5. Unisphere looks to be 1.2.0. What versions are you running. Replacing VCenter server certificates is not an option for us either. How can this be fixed from the VNX side, since it is what broke it? I did notice a new version of both block and file code is already available. I really don't want to perform another code upgrade to fix this issue, if it even does...
OPP_LTD
23 Posts
0
October 5th, 2012 01:00
Even more fun when you have distributed switches on your vCenter. Tried replacing the certificates on the ESX hosts but this result in HA being broken so going back to the drawing board.
Disked
2 Posts
0
October 5th, 2012 08:00
OPP_LTD makes a good point (not sure what the dvSwitch has to do with it). HA is implemented at the cluster level, and you can turn vCenter off and HA will still run fine because the hosts are monitoring each other and know where all the VMs are accross the cluster. It is entirely possible that HA is using the original certificates they obtained during installation to communicate for HA purposes. Messing with host certificates is not something I'd do, personally.
Still the article mentioned above deals with replacing the vCenter certificate (which will break all communication to hosts), The hosts will, in some manner or another, need to accept the new certificate from vCenter. If this was a right-click operation that would be fine, but it's not. You probably will be removing each host from inventory, and rejoining it to vCenter after upgrading the certificate. The question in my mind is, will the host accept a different certificate for vCenter.my.org when it already has the old one registered? Probably not just by providing the root password when re-joining it. I'd want vmware to do this in a lab before I'd mess with any certificates at all.
The real fix is for EMC to fix their code which broke vSphere integration on the VNX. There are indications in our testing from the VNX that there is no communication at all to vSphere, and that the level of encryption might be moot.
sthulin
2 Intern
•
181 Posts
0
October 11th, 2012 07:00
I believe this change is due to a recent update by microsoft that also changes the default behavior in the same way. I don't think there will be a fix, and if you update your vCenter Server running on Windows with the hotfix (http://support.microsoft.com/kb/2661254) you will also run into the same problem (VNX or not).
I also believe that this only effects people who upgraded from vSphere 4.0. I'd have to double check this, but i remember reading that fresh installs starting with 4.1 used a 1024 default key length.
Tengage
19 Posts
0
October 16th, 2012 14:00
Our VCenter / Unisphere integration broke after upgrading from Flare 31 to Flare 32 on a block only VNX5500. I suspect when it was originally setup, the "Bypass Certificate Verification for VMWare Infrastructure" box was checked. This box doesn't exist anymore and I don't think asking our VMWare team to replace their certs and re-import 120 hosts is a very nice fix.