Lo primero de todo, debemos detener los siguientes servicios:

VMware Update Manager Service
VMware VirtualCenter Management Webservices
VMware VirtualCenter Server service

Una vez listo, copiamos la carpeta “Datamigration” que viene en el DVD de VMware vSphere 4.1 a la raiz del servidor actual de vCenter. Vamos por línea de comandos y ejecutamos “backup.bat” para realizar una copia de seguridad completa y poder restaurarlo en el futuro servidor.

Nos realizará un par de preguntas por si queremos guardar los parches ya bajados a nivel de host y de máquina virtual, cada uno escoge su opción en mi caso no y ya los bajaré de nuevo.

Copiamos toda la carpeta “Datamigration” del servidor vCenter 4.0 32 bit (origen) al futuro servidor 4.1 (destino) a su raiz. Y con el servidor vCenter origen ya hemos finalizado.

En el servidor destino no deberemos tener instalado nada, simplemente preparado tras instalar Windows (XP SP2 x64, 2003 SP1 x64, 2008 x64 o 2008 R2) de 64 bit, abrimos una consola de DOS, entramos al directorio “Datamigration” y ejecutamos “install.bat”, deberemos indicar cual es la unidad de DVD de vSphere 4.1 ya que es necesaria para que nos vaya instalando los componentes cómo los teníamos instalados en la instalación origen.

Durante el proceso de migración nos saltará el asistente de instalación de VMware vSphere 4.1… lo continuamos…

Y si disponemos de VMware Update Manager igualmente; además este asistente de migración nos migrará VMware Orchestrator si también lo tenemos instalado…

Bien, una vez que acabe el asistente de migración es normal que nos de errores ya que hemos cambiado el nombre del host vCenter y su dirección IP, por lo que tendremos que indicárselo a los host ESX(i) y que apunten de forma correcta al nuevo vCenter; lo haremos de igual forma a Update Manager para que puedan iniciar sus servicios de forma correcta.

Vamos a los servidores ESX con cualquier cliente SSH (putty por ejemplo) y con el editor VI editamos el fichero “/etc/opt/vmware/vpxa/vpxa.cfg” buscamos la entrada con el parámetro “<serverIp>” y cambiamos la dirección IP del antiguo servidor de vCenter por el nuevo de la 4.1.

Una vez cambiado tenemos que reiniciar los agentes de administración (VMware ESX Management Services) con:

’service mgmt-vmware restart’
’service vmware-vpxa restart’

A nivel de VMware Update Manager deberemos corregir e indicar quien es el servidor VMware vCenter para que inicie bien los servicios, editamos el fichero: “%Programfiles(x86)%\VMware\Infrastructure\Update\vci-integrity.xml” y modificamos el parámetro <vpxdLocation> con la dirección IP del nuevo servidor.

Una vez esto, reiniciamos los siguientes servicios para que los cambios surjan efecto:
VMware Update Manager Service
VMware VirtualCenter Management Webservices
VMware VirtualCenter Server service

Finalmente instalamos el cliente vSphere Client en el servidor vCenter para poder conectarnos. Ahora ya podríamos ir actualizando nuestros host’s ESX o ESXi.

Lo primero de todo, iremos a la web de VMware y nos descargamos los siguientes ficheros:

- Pre-upgrade package for ESX 4.0 to ESX 4.1.
- ESX 4.1 (upgrade ZIP from ESX 4.0).

Mediante WinSCP o cualquier programa de este tipo copiamos los ficheros al host.

Ejecutamos primero el comando: ‘esx-update –bundle=pre-upgrade-from-ESX4.0-to-4.1.0-XXXXX-release.zip update’

Después lo dicho, pondremos el equipo en modo mantenimiento para poder aplicar el upgrade, sobre el host en cuestión, botón derecho > “Enter Maintenance Mode”.

Una vez haya entrado en modo mantenimiento ya podremos aplicar el parche para actualizar nuestro host: ‘esxupdate –bundle=upgrade-from-ESX4.0-to-4.1.0-XXXXX-release.zip update’, tras unos minutos nos habrá actualizado el host, lo reiniciamos y listo! Ahora sólo queda actualizar las VMware Tools en las máquinas virtuales que vaya a hospedar, claro que lo haremos mediante un proceso manual al no tener VMware Update Manager.

ghettoVCB es un script que se debe ejecutar en el propio servidor VMware ESX(i), podremos programar que se ejecute mediante tareas ‘Cron’ o como en mi caso lo ejecutaré desde un equipo remoto mediante la utilidad plink.exe. Además, ghettoVCB almacena los backups en un datastore de ESX(i), en este documento veremos al final cómo hacer el backup en una carpeta Windows que tengamos gracias a NFS.

Lo primero de todo es bajarnos el script de AKI, además, tenéis la documentación oficial y el link de descargas en: http://communities.vmware.com/docs/DOC-8760.

Lo guardamos en el servidor ESX(i), podremos subirlo al servidor con alguna utilidad tipo WinSCP o FastSCP que mediante SSH podremos realizar transferencias seguras de ficheros a los host ESX(i) (previamente deberemos tener habilitado el acceso SSH a los host), lo guardamos en un datastore, donde querramos, lo descomprimimos con: ‘tar -zxvf ghettoVCB.tar.gz’

Entramos en el directorio que nos acaba de generar y editamos el fichero de configuración con: ‘vi ghettoVCB.conf’. En este fichero indicaremos donde se realizará el backup (VM_BACKUP_VOLUME), si queremos que sea el formato de la copia sólo de lo usado o respetando todo el tamaño (DISK_BACKUP_FORMAT thin o thick), si queremos comprimirlo, si queremos con destino NFS se configuraría aquí (por ahora en este ejemplo no está configurado)…

Podremos si queremos crear un fichero con un listado de las máquinas virtuales a realizar backup para posteriormente indicarlo a la hora de ejecutar el script con el parámetro -f, o si queremos hacer backup de todas las máquinas virtuales que se están ejecutando en este host pondríamos el parámetro -a. Ejecutando el script una vez configurado el fichero ghettoVCB.conf: ‘./ghettoVCB.sh -f FICHERO_LISTA_MV -g /PATH/FICHERO_CONFIGURACIÓN’

Dependiendo de la estructura de nuestros sistemas la copia tardará más o menos.

Si queremos, podremos programar mediante Cron la ejecución del script ghettoVCB.sh para que se ejecute de forma periódica desde los host VMware como se configuraría en cualquier linux. Si preferimos ejecutarlo de forma remota, podemos mediante plink.exe ejecutarlo desde un Windows e incluso configurando esto como un BAT/CMD y configurarlo como tarea programada. Para ejecutarlo: ‘plink.exe usuario@host -pw CONTRASEÑA “COMANDO A EJECUTAR”‘.

Si queremos, podemos realizar estas copias en datastores que los ubicaremos en nuestros Windows, para ello usaremos NFS, podemos instalar en un Windows el rol “Servicios para NEtwork File System” y compartir una carpeta de nuestros discos locales para almacenar ahí los backups, sea en un disco externo USB, en un disco local, una carpeta de red…

Una vez instalado ese rol, vamos a la carpeta que queremos compartir como destino NFS para que el host ESX(i) se conecte, en la pestaña “Seguridad” agregamos a “Anonymous” con todos los permisos.

A parte, entramos en su pestaña “Uso compartido de NFS” y compartimos la carpeta, marcaremos la opción “Permitir acceso anónimo” y ponemos “UID anónimo” a 0 y “GID anónimo” también a 0. Pulsamos en el botón “Permisos” y agregamos el/los host ESX(i) que querramos que accedan (o ponemos TODOS LOS EQUIPOS), ponemos “Lectura y escritura” y “Permitir acceso a la raiz”.

Además para que no nos de errores en las propiedades del “Servidor para NFS” desde la consola “Servicios para Network File System” y en protocolo de transporte ponemos sólo “TCP”. Y podemos también abrir con gpedit.msc la consola de directivas (GPO) locales, vamos a “Configuración de equipo” > “Configuración de Windows” > “Configuración de seguridad” > “Directivas locales” > “Opciones de seguridad” y habilitamos la directiva “Acceso a redes: permitir la aplicación de los permisos Todos a los usuarios anónimos”.

Ahora desde el host, desde “Configuration” > “Storage” pulsamos en “Add Storage…”, seleccionamos “Network File System” & “Next”,

En “Server” ponemos el nombre/IP del servidor NFS, en “Folder” la carpeta e indicamos el nombre del datastore.

Listo lo tenemos ahí montado. Ahora sólo queda que en el archivo ghettoVCB.conf modifiquemos/agregemos las siguientes líneas de configuración para que los backups se guarden en el dispositivo NFS:

UNMOUNT_NFS=0
NFS_SERVER=SERVIDOR_NFS
NFS_MOUNT=/RUTA
NFS_LOCAL_NAME=NOMBRE
NFS_VM_BACKUP_DIR=RUTA

Para habilitarlo desde local iremos a “Troubleshouting Options”,

Y aquí podremos habilitar el acceso local (Enable Local Tech Support) o acceso remoto mediante SSH (Enable Remote Tech Support (SSH), a parte podremos modificar el tiempo que queremos permitir esto habilitado (Modify Tech Support timeout) pudiendo indicar en minutos el tiempo que dejaremos las conexiones habilitadas.

Si en un momento dado necesitamos acceder de forma remota mediante SSH y no está habilitado, siempre podremos ir por “Security Profile” > “Properties”  e iniciar “Remote Tech Support (SSH)”.

Debemos tener en cuenta que las máquinas virtuales deben ejecutar versión 7 o superior de virtual hardware, además hay un listado de dispositivos USB soportados por lo que si no nos funcionase nuestro dispositivo USB no tendríamos soporte. He de decir que he realizado varias pruebas con varios dispositivos USB y todas ellas correctas.

Lo primero de todo es agregar el controlador USB a la máquina virtual, lo haremos de igual forma que agregaríamos cualquier hardware a la MV, editando su configuración y en la pestaña de “Hardware” > “Add”. Agregamos “USB Controller” y finalizamos el asistente. Sólo podremos configurar un controlador USB por máquina virtual.

Una vez tenemos el controlador, debemos agregar el dispositivo USB que nos interese (podremos hasta 20 por máquina virtual), en el asistente de agregar nuevo hardware agregamos “USB Device”, “Next”,

Y finalmente obtendremos un listado de los dispositivos USB que tenga nuestro host ESX o ESXi conectados, seleccionamos el dispositivo USB que nos interese y finalizamos el asistente. La máquina virtual ya verá cómo se le ha conectado un dispositivo USB y se le deberán instalar los drivers correspondientes si es necesario. Además si nos interesa, podremos habilitar el soporte de vMotion en esta máquina virtual al disponer de este USB conectado, logicamente perderá la conexión.

Es posible, que cuando reorganiceis vuestras listas de direcciones elimineis esta libreta porque no la vayais a usar y en este momento es cuando desde el OWA dejamos de poder ver las lista de direcciones con el siguiente error:

Esto se debe a que el parametro msExchResourceAddressList de vuestra organización, se ha quedado con el DistinguishedName de la libreta de direcciones eliminada.

Podemos comprobarlo desde la PowerShell con el comando:

[PS] C:\>Get-OrganizationConfig

Para solventar el problema, deberemos abrir el Editor ADSI:

1.- Desde la ventana ejecutar: adsiedit.msc

2.- Navegaremos hasta todas las libretas de direcciones para conocer el nuevo DistinguishedName que queremos poner

3.- Una vez tengamos el DistinguishedName de la nueva libreta: boton derecho sobre CN=TuOrganizacion y sustituimos el valor que hay en el atributo msExchResourceAddressList.

4.-Aplicamos, aceptamos y reiniciamos el servidor IIS.

Podremos comprobar desde OWA, que ya podemos volver a acceder a todas las libretas de direccionesque tengamos en nuestra organización configuradas.