Arquivo do mês: setembro 2013

Error de upgrade con el vCenter SSO: Server certificate assertion not verified and thumbprint not matched

Al actualizar el SSO de 5.1 a 5.5, se puede tener el siguiente error:

Getting SSL certificates for https://10.100.5.95:7444/lookupservice/sdk com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate assertion not verified and thumbprint not matched Return code is: SslHandshakeFailed 1 VMware Single Sign-On-build-1302472: 09/23/13 16:24:19 Leaving VmSetupImportLookupServiceData, Error:

Este error pasa por problemas con los certificados SSL, donde los hostnames no son iguales a los que fueron indicados en la instalación de la versión anterior que está almacenada en el registro del Windows. Para corregir el  problema, se tiene que cambiar la siguiente llave de registro:

HKLM\SOFTWARE\VMware, Inc.\VMware Infrastructure\SSOServer\FqdnIp

Y completar con el FQDN del servidor donde el SSO está instalado.

Aprecio cualquier feedback acerca de esta corrección.

Anúncios

Erro de upgrade do vCenter SSO: Server certificate assertion not verified and thumbprint not matched

Ao atualizar um SSO de 5.1 a 5.5, o seguinte erro pode ser encontrado:

Getting SSL certificates for https://10.100.5.95:7444/lookupservice/sdk com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate assertion not verified and thumbprint not matched Return code is: SslHandshakeFailed 1 VMware Single Sign-On-build-1302472: 09/23/13 16:24:19 Leaving VmSetupImportLookupServiceData, Error:

Este erro se refere a um problema com os certificados SSL, que não combinam com o nome da máquina armazenado no registro do Windows referente ao SSO. Para corrigir o problema, é necessário editar a seguinte chave de registro:

HKLM\SOFTWARE\VMware, Inc.\VMware Infrastructure\SSOServer\FqdnIp

E completar com o FQDN do servidor onde o SSO está instalado.

Qualquer feedback referente a esta correcão será bem-vindo.

Actualizando VMware vCenter SSO 5.1 a 5.5 – error code 1603

Si estás actualizando el SSO y estás recibiendo un error del tipo “CustomAction BootstrapAll returned actual error code 1603”, esto puede estar ocurriendo debido a un pequeño problema en el instalador del paquete del SSO. Existem ya algunas soluciones para el problema en versiones anteriores a la 5.5, pero lo que parece resolver el tema es el siguiente procedimiento:

  • Remover la carpeta C:\Program Files\VMware\CIS con todo su contenido (hagan antes un backup)
  • Recrear la carpeta C:\Program Files\VMware\CIS sin contenido, y volver a ejecutar el instalador

Me gustaria saber si este procedimiento funciona o no, así que agradezco si me dejan un comment positivo o negativo.

Saludos!

Atualizando SSO 5.1 a 5.5 – error code 1603

Se voce está atualizando o SSO e está tendo um erro do tipo “CustomAction BootstrapAll returned actual error code 1603”, isto pode estar ocorrendo devido a um pequeno problema no instalador do pacote do SSO. Existem algumas solucões para o problema já postadas para versões anteriores, mas para a versão 5.5 o que parece resolver o problema é:

  • Remover a pasta C:\Program Files\VMware\CIS com todo o seu conteúdo (faca um backup antes)
  • Recriar a pasta C:\Program Files\VMware\CIS vazia, e executar o instalador novamente

Gostaria de receber um feedback se alguém conseguir consertar o erro com este procedimento ou não.

Um abraço!

vSphere 5.5 GA – disponible para download – novedades parte 1

Ya está disponible para download el vSphere 5.5 – lo que se esperaba sólo para octubre está listo y puede ser puesto en producción. En primer lugar me gustaría hablar sobre la instalación del producto con la ISO, que sigue siendo la misma de la serie 5.x, así que no es necesario hablar de nada nuevo aquí.

esx55_install_1

Para los que lo extrañan, todavia se puede utilizar el vSphere Client instalable, versión 5.5, pero sin nada de nuevo.

Algunas cosas que ya pude verificar y son realmente interesantes:

  • El tamaño de los discos VMDK ahora puede ser de hasta 62TB (antes estabamos limitados a 2TB-512B, pero solo en VMFS-5, y solamente con VMs que estan en un ESXi 5.5 – ojo con entornos mixtos). Los RDMs de compatibilidad virtual tambiém tienen este nuevo limite (62TB).
  • El límite de memoria física de ESXi es el doble, aument´o de 2TB a 4TB. En consecuencia, el numero maximo de CPUs virtuales por core también aumentó, del 25 a 32 (es decir, 32 CPUs virtuales de VMs por núcleo físico – si el host tiene 2 procesadores Xeon de cuatro cores, soporta hasta 256 VMs con 1 vCPU, o 128 con 2 vCPU, por ejemplo). También aumentó el número de CPU lógicas por host (320 con HT activado, por ejemplo).
  • El Fault Tolerance todavia tiene las mismas limitaciones y no soporta VMs con más de 1 vCPU.

Una gran novedad es el vCenter Server Appliance: ya no tiene el límite del 5 hosts y 50 máquinas virtuales al usar la base vPostgres interna en la versión 5.5 – por lo que ahora, se puede utilizar la base interna para entornos de gran tamaño. El límite actual es de 400 hosts y 4.000 máquinas virtuales. Logicamente, se tiene que configurar la VM del VCVA para soportar entornos de gran tamaño, de acuerdo con la KB http://kb.vmware.com/kb/2057376.

Les dejo el Release Notes completo para los que quieran analisar: https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-55-release-notes.html

vSphere 5.5 GA – disponível para download – novidades parte 1

Já está disponível para download o vSphere 5.5 – o que estava sendo esperado somente para outubro já está pronto e pode ser colocado em producão. Primeiramente gostaria de falar sobre a instalacão do produto via ISO, que segue sendo a mesma da série 5.x, portanto não precisamos mencionar nada de novo por aqui.

esx55_install_1

Para os saudosistas, ainda está disponível o vSphere Client instalável, versão 5.5, mas sem nenhuma melhoria ou nova funcionalidade.

Alguns itens que já verifiquei e que realmente são interessantes:

  • O tamanho dos discos VMDK agora pode ser de até 62TB (antes estávamos limitados a 2TB-512B, mas apenas em VMFS-5, e apenas com VMs que estão em um ESXi 5.5 (muito cuidado com ambientes mistos, portanto). Os RDMs de compatibilidade virtual também tem este novo limite (62TB).
  • O limite de memória física do ESXi foi dobrado, de 2TB a 4TB. Consequentemente, o máximo de vCPUs por core suportado também aumentou, de 25 para 32 (ou seja, 32 vCPUs de VMs por core físico máximo – se o seu host possui 2 Xeon quad core, suportará até 256 VMs de 1 vCPU, ou 128 de 2vCPU, por exemplo). Também aumentaram o número de CPUs lógicas por host (a 320, com HT habilitado, por exemplo).
  • O Fault Tolerance ainda possui as mesmas limitacões, e não suporta VMs com mais de 1 vCPU.

Uma GRANDE novidade está no vCenter Server Appliance: não está mais presente o limite de 5 hosts e 50 VMs quando se utiliza a base vPostgres interna para a versão 5.5 – portanto, agora, já se pode utilizar a base interna para ambientes grandes. O limite agora está em 400 hosts e 4000 VMs. O ideal é que o appliance seja alterado para suportar ambientes grandes, de acordo com a KB http://kb.vmware.com/kb/2057376.

Deixo aqui o Release Notes completo para os que queiram analisar: https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-55-release-notes.html

Verificar modelo y driver de nics en ESXi

Para comprobar que placas de red hay en su ESXi no es suficiente solamente el vSphere Client, o utilizar la línea de comandos como se ha mencionado en mi post anterior. El hecho de saber que una placa es Intel o Broadcom no es suficiente, e incluso con el modelo en manos los fabricantes crean una gran cantidad de variaciones de hardware.

En primer lugar es necesario comprobar exactamente que placa está conectada con el hardware y el driver que está utilizando. Para ello, el viejo lspci de Linux es útil – con la opción “-p”:

lspci -p | grep vmnic

Después, se puede corroborar la versión de los drivers instalados en el ESXi:

esxcli software vib list | grep bnx2 (utilizo el bnx2 como exemplo)

En la consola, veríamos así:

esxinics_driversEn el screenshot, el driver de la placa es el 2.2.1l.v50.1-1 (los otros tres son de otras placas – bnx2x – o de otras funciones – acceso iSCSI o FCoE).

Para comprobar que el driver está actualizado o si hay actualizaciones disponibles, se puede acceder la HCL VMware: www.vmware.com/go/hcl como en pantalla de abajo, usando la VID, DID, SVID y SDID – si se utiliza solo el nombre la placa se pueden tener diversos resultados que no son concluyentes. El uso de las flags VID y DID ayuda a determinar exactamente que placa el sistema tiene.

esxinics_drivers2Basado en eso, tenemos el resultado abajo:

esxinics_drivers3A la derecha podemos ver que versiones de ESX son compatibles con esta placa. Haciendo click sobre el nombre de la placa, es posible verificar que drivers la soportan:

esxinics_drivers4Por lo tanto, con el  VID y DID que obtuvimos con el lspci -p, podemos determinar que la placa Broadcom que tenemos tiene un driver que está soportado, pero que contiene actualizaciones (lo mas nuevo de la lista es el que está arriba). En este caso, recomiendo que los drivers sean acttualizados así que posible.

En el futuro sale post acerca de como actualizar drivers.