El día 4 de Marz de 2015 Citrix libero la techpreview de StoreFront X1.
Tras un tiempo, ha llegado el momento de actualizar mi Storefront de laboratorio, y que mejor que un post ilustrando el proceso. Hay que tener en cuenta que esta TechPreview:
This tech preview does not provide an upgrade path for existing StoreFront installs.
Así pues necesitamos una máquina “limpia” dónde instalaremos nuestra Techpreview de X1.
El pasado día 13 de Enero se anunciaba a través de XenServer.org y Citrix.com la nueva versión de XenServer 6.5.
Como ya sabéis, en su versión 6.2 XenServer paso de ser un producto comercial (con versión Free) a producto plenamente OpenSource, liberado a la comunidad, en la cual existía una parte de licenciamiento a cargo de Citrix, en la que nos posibilitaba el uso de actualizaciones automáticas a través de XenCenter (así como soporte por parte de fabricante).
Citrix XenServer 6.5 incluye bastantes cambios. Algunos de ellos, recuperan algunas de las funcionalidades perdidas en 6.2, y nos alegramos de ello, pues sin duda son opciones que ya en su momento eran muy interesantes. XS 6.5 tambien incluye nuevos cambios en el licenciamiento. Continuaremos disponiendo de nuestra versión Free, pero en la opción comercial, nos encontramos a priori con dos opciones adicionales. La opción Standard y Enterprise. Posteriormente hablaremos de ello.
Durante las migraciones de nuestros servidores de XenServer a nuevas versiones recomendamos tener en cuenta lo siguiente:
– No es posible migrar VMs a una version mas vieja. Solo igual o superior.
– No se recomienda tener un entorno mixto por largos periodos. En este caso, siempre funcionara con el nivel funcional mas viejo y puede haber opciones que no esten disponibles.
– Si actualizamos un pool, siempre debe actualizar-se el Master primero.
– Los SR no son tocados durante el proceso de upgrade.
– Se recomienda un backup del statedb del Pool (xe pool-dump-database).
– Antes de empezar, descargar la última version de XenCenter, ya que tras actualizar XS solo podremos conectar a él con la última versión de XenCenter
– Quitar los CDs/DVDs asignados a todas las VMs.
– Des-habilitar el HA.
Además, debemos tener en cuenta, que durante la migración a XS6.2 de un pool…
– Todos los servidores del mismo pool disponen del mismo número de NICs y configuradas igual si es posible.
XS6.2 puede configurar las redes a nivel de Pool. Ello implica que todos los servidores deben tener la misma configuracion de red, tanto en número de NICs como en las configuraciones especificas del mismo, si no queremos tener problemas no controlados durante el proceso de upgrade:
Tal como indica la documentación…
“Before creating networks, note that the cabling must match on each host in the pool. That is, the NICs on each host must be plugged in to the same physical networks as the corresponding NICs on the other hosts in the pool “
“All XenServer hosts in a resource pool should have the same number of physical network interface cards (NICs), although this requirement is not strictly enforced when a XenServer host is joined to a pool.”
“If one XenServer host has a different number of NICs than other hosts in the pool, complications can arise because not all pool networks will be valid for all pool hosts. “
Cabe tener en cuenta que cualquier host añadido al Pool, recivira la misma configuración de red establecida en el pool y por ello la importancia de asignar igual las redes del host. Así, es imperativo esta recomendación?
NO, pero se recomienda si queremos evitar problemas no controlados durante los procesos de migración o/e inclusión de los servidores de XenServer en el Pool.
En la FAQ de XS6.2 podemos observar:
«What types of configurations can be made at the Resource Pool level?
Shared remote storage and networking configurations can be made at the resource-pool level. Once a configuration is shared on the Resource Pool, the master system automatically propagates configuration changes to all of the member systems.
Will new host systems added to a Resource Pool automatically be configured with shared settings?
Yes. Any new host systems added to a Resource Pool automatically receive the same configurations for shared storage and network settings.»
Así, pues antes de llevar a cabo una actualización de nuestro Pool de XenServer, comprobad las recomendaciones y planificar el proceso de Upgrade para evitar al máximo problemas conocidos del proceso.
Adicionalmente, entre las Release notes de XS6.2 encontramos:
If the Rolling Pool Upgrade Wizard discovers storage that is detached and cannot be reattached, it will fail (even when no VMs are using the storage). Customers should either fix the access to the storage repository or remove it from the XenServer pool before restarting the wizard. [CA-72541]
The XenCenter Rolling Pool Upgrade wizard should not be used with Boot from SAN environments. For more information on upgrading boot from SAN environments, see Appendix B of the XenServer 6.2.0 Installation Guide .
If a Rolling Pool Upgrade fails when upgrading a pool of XenServer hosts, customers should avoid migrating VMs with shared storage from an upgraded host to a non-upgraded host. Performing such migrations can cause the VMs to hang or crash. [CA-108234]
After upgrading XenServer hosts from version 6.0.2 and earlier to version 6.2.0, customers using Single Root I/O Virtualization (SR-IOV) with Intel NICs will be unable to start VMs. Customers should follow the procedure in CTX134054. [CA-89008].
The vSwitch Controller may fail to show dependant (slave) networks that had been bonded when NIC bonds are deleted. To resolve this issue, refresh the status of the pool or restart the vSwitch Controller. The networks should then reappear. [CA-65261]
iSCSI paths that are not available when a XenServer host is booted, do not get established automatically later. This can be resolved by either performing another host reboot or by detaching and re-attaching the SR. [CA-73867]
vCPU pinning information is not respected when VMs are migrated. [CA-96952]
After an upgrade to XenServer 6.2.0, details on the date and time VMs were started at may be lost. There is no workaround for this. However, the operation of the VM will be unaffected. [CA-97869]
After installing the XenServer Tools, customers should reboot their hosts when prompted by the Citrix XenServer Tools installer. After the XenServer Tools installer has closed, all paravirtualised drivers and the XenServer Tools are installed and a further reboot is not required. Customers can safely ignore any pop-up window requesting a further reboot. [CA-107094]
Customers upgrading from XenServer 5.6x who have not upgraded the XenServer Tools in their Windows VMs, will not be able to use quiesced snapshots. Customers should upgrade their XenServer Tools after host upgrade, to restore this functionality. [CA-108370]
Storage XenMotion is only possible on live VMs with XenServer Tools installed. In the event that a VM crashes during Storage XenMotion, the Storage XenMotion operation will abort. [CA-85053]
Para mas detalles consultar las Release notes de XS6.2.
Resources:
FAQ XenServer 6.2 http://support.citrix.com/article/CTX137836
Manual de Administrador XenServer 6.2 http://support.citrix.com/article/CTX137828
Release Notes XenServer 6.2 http://support.citrix.com/article/CTX137826
Como algunos sabréis, PHD virtual backup es una solución de backup para entornos virtuales que esta despegando muy fuerte en los últimos años. Dispone de versiones para XenServer y VMware.
PHDVB se basa en el uso de un virtual apliance que permite un rápido deploy de la solución y que permite empezar a funcionar en poco tiempo.
No es necesario conocimientos sobre backups pues su fuerza, su potencia esta en su facilidad de uso. Cualquier, y cuando digo cualquiera es cualquiera, puede realizar backups, programarlos y recuperar tanto maquinas como ficheros de una forma fácil y rápida.
Las características del producto podéis verlas en la propia web del fabricante: http://www.phdvirtual.com/
Que hay de nuevo viejo!
PHDVB 6.2 proporciona una nueva característica llamada CloudHook. Esta posibilita el uso de repositorios en la nueva para el almacenamiento de backups con las ventajas que ello propociona.
No vamos a explicar todo lo bueno que ofrece PHD. Si realmente queréis ver su potencia, nuestra recomendación es que lo descarguéis y lo probéis, pues sabemos que os gustará y no es necesario que os convenzamos al respecto.
Descarga-lo aquí: http://bit.ly/YcSDnF
El motivo de este post, es ver como debemos proceder para actualizar nuestro producto de backup favorito.
Actualizando PHD
Lo primero que debéis saber es que utilicen una versión inferior a la 6.0, NO DISPONEN de actualización directa a 6.2, con lo que deberán pasar por un proceso de migración.
Para versión 6.0 y 6.1, PHD proporciona un parche de actualización, descargable desde el siguiente link: http://www.phdvirtual.com/upgrade-packages
El paquete de actualización es de 211MB. Una vez descargado, procederemos según el siguiente manual:
Aquí encontraremos tanto las Tools para actualizar en los dispositivos Windows, como la actualización del cliente y del Exporter.
Actualizar el producto es MAS FACIL AUN que la instalación de la solución.
El proceso tarda pocos segundos y en breve aparece la ventana que PHD 6.2 ha sido instalado.
En este punto, ya solo nos queda abrir la consola de PHD y comprobar la nueva funcionalidad; puesto que PHD6.2 únicamente incluye como novedad CloudHook.
Actualizando nuestro appliance
El fichero de upgrade incluye un fichero llamado “PHDVirtualBackup_6_2_0.phd”
Este permitirá la actualización de nuestro appliance. Para su aplicación, realizaremos lo siguiente:
Detalles
VBA. Detalle del applicance en versión 6.2
En las opciones de Storage podremos ver las nuevas características de almacenamiento:
Esperemos ver pronto esta solución para Hyper-V. Oido?! 😛
