Hola, que tal? Soy Jose Maria Gris y como cada jueves estoy aquí con vosotros para hablar del ecosistema de VMware.
Curiosamente me he encontrado con dos situaciones iguales en dos entornos distintos, lo que me ha dado a pensar en que sería bueno postearlo. Veeam Backup es muy fácil de configurar en modo network a través de vCenter. Configuraciones en modo SAN o en modo en modo “Virtual Appliance” tienen su configuración especial, pros y contras.
Estamos en un entorno Veeam Backup 4.x donde la maquina veeam tiene iniciadores iSCSI de MS i “ve” las Luns, haciendo las copias en modo “SAN”. Una de las opciones que tenemos habilitada es usar el Traking de bloques cambiados para que las copias incrementales vayan más rápidas al monitorizar los cambios de bloques.
Todo el sistema funciona bien hasta que un día nos damos cuenta que la velocidad de la copia de seguridad baja de forma considerable y a la par baja el ratio de “copia”.
Investigas que ha pasado y no ves ningún cambio importante a la vista. Nuestro Veeam Backup está funcionando perfectamente, pero da unos mensajes “Verifing changed block tracking…”.
Analizando un poco más en profundidad, justo antes de empezar a ir lentos hicimos unos cambios, entre los que había cambios de ubicación de las VMs en otro datastore con StoragevMotion. Y ahí está el problema. Las referencias de los bloques han cambiado y el sistema no puede establecer “el diferencial” porque el entorno que tiene guardado y el que “ve” no cuadran. Hay que reconciliarlos.
Nos vamos a nuestro vCenter y a cada VM que hemos movido y hemos cambiado de Lun le cambiaremos el siguiente parámetro. En Edit Settings, pestaña options, General, veremos el botón Configuration Parameters.
Dentro de las opciones buscaremos el string ctkEnabled y cambiaremos su status a “False”.
Ello permitirá a Veeam volver a reconstruir el entorno de bloques y volver a nuestra velocidad que estábamos obteniendo hasta és momento.
Es importante tener el tema en cuenta porque lo que parece un cambio banal puede significar perder la ventana de backup ya que un job puede alcanzar a otro, dependiendo de cómo lo tengamos organizado. Otro día hablaremos de la configuración “Virtual Appliance” que es muy curiosa.
Saludos, take care.
Aquí esta la segunda entrega de la instalacion de VMware View 4.5. En la primera parte cubrimos las instalacion y personalizacion de VMware View 4.5.
En esta segunda entrega veremos como nos conectamos a nuestra máquina virtual usando el VMware View 4.5 Client.
Antes de continuar con la ejecución de nuestro cliente una vez descargado, os quería enseñar una vista de la carpeta donde se alojará nuestro Desktop Virtual con todos sus archivos.
La ruta será : C:\Users\”usuario”\AppData\Local\VMware\VDM\Local Desktops\”nombre del POOL”.
Y ahora si podremos conectarnos en MODO LOCAL. No debemos olvidar el “desmarcar” en este caso la opción : LOG IN AS CURRENT USER para conectarnos al escritorio que nos hemos descargado. Ya que de lo contrario intentará conectarse al POOL donde reside tu DESKTOP y nos dará el error de que estamos trabajando en MODO LOCAL y no podrá conectarse.
Volviendo de nuevo a mi portátil, ya podemos ver que nos indica que vamos a conectarnos en MODO LOCAL. Seleccionamos el botón CONNECT.
Y nos arranca un Hypervisor que nos permitirá ver el proceso de entrada a nuestro escritorio OFF LINE.
Y por fin dispondremos finalmente de nuestro escritorio en MODO LOCAL.
Como veis al ser la primera vez que corremos nuestro escritorio en MODO LOCAL, nos dará la advertencia de que necesitará automáticamente detectar nuestro hardware y nos llevará finalmente a hacer un REBOOT para guardar los cambios.
Una vez reiniciado nuestro escritorio podremos acceder al icono del ClENTE VIEW en el área de notificaciones de nuestro Windows 7 para ver todas las posibilidades que nos ofrece el cliente.
Tenemos la posibilidad de hacer un Backup completo o diferencial si este ya se ha realizado con anterioridad.
Y finalmente si vamos a la pestaña OPTIONS podremos realizar un CHECK IN DESKTOP de nuestro escritorio.
Para terminar, como sé que lo vais a preguntar con total seguridad os voy a aclarar las diferencias entre: CHECK OUT, CHECK IN ROLLBACK y BACKUP.
CHECK OUT DESKTOP: Nos permite bajarnos una copia de nuestro escritorio a nuestra máquina física y trabajar en MODO LOCAL.
CHECK IN DESKTOP: Nos permite sincronizar todos los cambios realizados en nuestro Desktop en MODO LOCAL y guardarlos en el POOL de escritorios (Manual,automático,etc..).
ROLLBACK: Nos permite ir a un estado anterior del escritorio antes de el último CHECK IN realizado.
BACKUP: Es cuando el usuario quiere guardar los cambios realizados en su DESKTOP de forma permanente e independientemente de si realizamos un ROLLBACK. Tiene sentido para aquellos documentos o trabajos que siempre deben permanecer en nuestro escritorio pase lo que pase.
Bueno!!!! Aquí me despido de vosotros esperando que os haya gustado el POST y os emplazo hasta la semana que viene.
Para determinar con precisión si la CPU de tu servidor VMWare vSphere ESX/ESXi se está comportando con normalidad, debes de revisar la información específica disponible sobre dicha CPU con las herramientas de monitorizacion incluidas en VMware vSphere.
La semana pasada, en la primera parte del video, vimos los conceptos de CPU used y CPU Ready y lo que significa cuando estos dos contadores aumentan durante un perido de tiempo prolongado.
En este episodio #42 te monstrare a extrapolar los datos de los dos contadores a porcentajes relativos y a identificar si realmente existe un cuello de botella a nivel CPU en tu entorno virtual.
Hola a todos, soy Florián Murillo, la semana pasada hablamos de Network I/O Control, de la que me declaro un entusiasta, con NetIOC podemos decidir que ancho de banda le damos a cada tipo de flujo, del total que tenemos en un uplink.
Pero si el uplink tiene varios interfaces, estoy presuponiendo que estos interfaces se van a ir “llenando” de tráfico cómo si fueran vasos comunicantes y esto es mucho suponer, ningún algoritmo de vSphere 4 controla el “llenado” de los interfaces, los algoritmos basados en Port-ID, MAC-source o IP-source-destination disponibles en vSphere 4 solo deciden el interfaz de salida, pero una vez asignado no cambia.
Con la llegada de vSphere 4.1 aparece un algoritmo nuevo, llamado Load Based Teaming, LBT para los amigos de los acronimos
LBT es capaz de cambiar el uplink de salida de una VM dependiendo del ancho de banda utilizado sobre los uplinks, proporcionando un balanceo dinámico por ancho de banda consumido, del que hasta ahora no disponíamos, solo trabaja cuando la ocupación del interfaz supera el umbral del 75%, entonces recalcula y reasigna los uplinks cada 30 segundos.
La configuración es tan simple como seleccionar “Route based on physical NIC load” en los settings del port-group
Cuestiones:
¿El tráfico de un VM por cuentos interfaces fluye simultáneamente?
LBT reparte el tráfico de las VM entre los diferentes, pero cada VM solo sale, por un interface, periódicamente, el algoritmo puede cambiar la VM de interfaz, pero SOLO sale por uno en cada momento. Esto permite que en los switches físicos no tengamos que configurar ningún tipo de port-channel.
¿Que licenciamiento necesito para utilizar LBT?
Esta funcionalidad solo se puede utilizar con switches distribuidos, por tanto, se requiere la licencia Enterprise Plus.
¿Puedo balancear entre interfaces de diferentes “tamaños”?
Si, se pueden mezclar interfaces de 100Mb, 1Gb y 10Gb
Esto es todo amigos, la semana próxima mas novedades de vSphere 4.1.
¿Que tal las vacaciones?. Soy Jose Maria Gris y como cada jueves vamos a ver aquellas historietas que nos hacen nuestra vida de consultor algo más “difícil”.
Cuantas veces después de un Converter, de un upgrade de Hardware virtual, o por otras circunstancias te encuentras con la pregunta de marras que además la primera vez te tienes que mirar dos veces.
¿Qué me pregunta realmente? ¿De qué otro adaptador me está hablando?
Y me ha vuelto a pasar esta semana y he pensado que era bueno comentarlo, verdad Roberto?.
Bien, pues el tema es que sencillamente el registro de Windows guarda la tarjeta anterior que ya no estamos usando y esa tarjeta, aunque no la vemos, tiene la ip de la tarjeta que estamos usando ahora.
Si sencillamente contestamos que NO queremos cambiar la ip de la tarjeta actual, funcionará sin problemas, pero vamos hacer Housekeeping y lo limpiamos.
Microsoft kb 269155 y vemos que podemos limpiar el registro. Traslado el procedimiento: (sic)
Con ello tendremos nuestro registro limpio sin la dichosa preguntita de marras.
En el post de hoy os explicaré como modificar la memoria máxima que puede usar un determinado template.
Para ello seguiremos los 3 sencillos pasos que os detallo a continuación:
1.- Comprobamos la memoria máxima del template:
xe template-list name-label=”Etiqueta del Template” params=memory-static-max,recommendations
2.- Le asignamos la memoria que consideremos
xe template-param-set uuid=”uuid del template memory-static-max=”Memoria limite en bytes”
3.- Volvemos a comprobar la memoria máxima del template para verificar si lo hemos hecho correctamente
xe template-list name-label=”Etiqueta del Template” params=memory-static-max,recommendations
Para terminar añado el siguiente enlace donde podréis descargaros la guía de administración de XenServer y poder echar un vistazo a los limites de memoria soportados.
Hola nuevo!!!!! Soy Miguel Ángel Alonso y aquí estoy con vosotros como cada martes para ofreceros un nuevo POST del mundo de la virtualización.
En el día de hoy vamos a hablar de VMware View 4.5 y en concreto del MODO LOCAL, antiguo (OFF-LINE) y que por fin corre de forma totalmente soportada en esta versión que además nos trae cosas nuevas y que iré explicando en futuros POSTs como son la integración con THINAPP, TRANSFER SERVER, y otras funcionalidades.
Básicamente VMware View en MODO LOCAL es el modo en el que un cliente de VIEW puede tener acceso a su escritorio de manera continuada, independientemente de si tenemos acceso a Internet y al BROKER o no la tenemos.
Lo que ocurrirá es que una vez nos conectemos a nuestro Cliente de View desde la primera vez, es que tendremos la posibilidad de descargarnos nuestro escritorio a nuestro máquina física para llevarlo a todos los sitios con nosotros. Esto lo veo muy práctico sobre todo para los clientes móviles de las empresas y que dependen mucho de las conexiones a INTERNET.
Antes de empezar y aunque en el próximo POST os explicaré como instalar y configurar este nuevo ROLE (Server) VIEW TRANSFER SERVER, deberá estar totalmente instalado y configurado desde nuestro View Broker, ya que sin este no podremos tener acceso a nuestro MODO LOCAL de ninguna manera.
Dicha esta pequeña matización comenzaremos con la instalación de MODO LOCAL:
Una vez tengamos funcionando a pleno rendimiento nuestro SERVER TRANSFER, instalaremos nuestro CLIENTE en MODO LOCAL, tanto
sea x86 como x64. No voy a poner SCREENSHOTS de la instalación ya que sólo cabe reseñar que deberemos introducir el FQDN o IP de nuestro BROKER y las credenciales para poder conectarnos. Por lo demás el proceso de instalación es bastante sencillo.
Una vez acabes con la instalación, te aparecera el icono en tu escritorio para poder conectarnos. Aquí cabría reseñar que este cliente (MODO LOCAL) sólo funciona exclusivamente y por el momento sobre máquina Físicas (os lo digo para que os ahorréis tiempo si alguno de vosotros va a hacer pruebas desde una Máquina Virtual aunque sea desde otra plataforma que no sea VMware).
Y además “no podréis” tener en vuestra máquina física instalada ni VMware Workstation ni VMware Server ya que al
instalar el MODO LOCAL se crearán tarjetas virtuales que serían incompatibles con las de los mencionados productos de VMware.
Antes de ejecutar el icono de nuestro Cliente quería ofreceros un par de panorámicas de cómo VIEW TRANSFER está instalado a través de la interfaz de nuestro BROKER (Vista 1) en la opción TRANSFER SERVER REPOSITORY.
Y otra segunda Vista desde la opción SERVERS de nuestro Broker:
Bueno una vez dicho esto, ejecutamos nuestro icono del Cliente de View (LOCAL MODE). ¡¡¡¡¡Ojo!!!!!!! Tendremos marcada la opción de LOG IN AS CURRENT USER para poder conectarnos con nuestro escritorio por primera vez o siempre que no usemos el MODO LOCAL.
Nos indicará un mensaje de Bienvenida si antes lo hemos configurado en nuestro BROKER y seleccionaremos OK.
Y seguidamente nos aparecerá una pantalla donde podemos cambiar el usuario que se va a loguear. Presionamos sobre el botón de LOGIN.
Una vez hemos logueados, arrancará nuestro escritorio e iremos a la pestaña de OPTIONS.
Y seleccionaremos: Check OUT Desktop para poder entrar en modo LOCAL y descargarnos el escritorio a nuestro PC o portátil.
Aquí se ve muy claro el aviso de la descarga del escritorio y nos recuerda que guardemos cualquier trabajo antes de comenzar con la descarga.
Aquí podemos ver una panorámica del % de la descarga de nuestro DESKTOP (MODO LOCAL).
Y aquí nos quedamos amigos, hasta el próximo martes con la entrega de la segunda parte.
Para determinar con precisión si la CPU de tu servidor VMWare vSphere ESX/ESXi se está comportando con normalidad, debes de revisar la información específica disponible sobre dicha CPU con las herramientas de monitorizacion incluidas en VMware vSphere.
Un aumento del contador CPU used y CPU ready por un periodo de tiempo corto, puede indicar que se está haciendo un uso adecuado de los recursos de CPU del servidor ESX/ESXi.
Sin embargo, si ambos valores estan constantemente altos, significa que el host ESX/ESXi está probablemente sobrecargado.
Generalmente, si el valor CPU used es superior al 90 por ciento, y el valor de CPU ready para una máquina virtual en concreto, es superior al 20 por ciento, se podría decir con toda firmeza que el rendimiento de dicha máquina virtual se veria afectada negativamente.
Los valores de muestreo obtenidos por el cliente de VMware vSphere y esxtop/resxtop difieren en sus intervalos. Así, por eljemplo, el cliente usa unos intervales de muestreo cada 20 segundos mientras que esxtop/resxtop usa unos intervalos de muestreo de 5 segundos por defecto.
Por consiguiente, asegurate de normalizar los valores antes de comparar los resultados de ambas herramientas de motitorizacion.
En este episodio #41, te mostrare la relación entre el contador CPU used y CPU ready y como medir dichos contadores de rendimiento:
Hola a todos, soy Florián Murillo y hoy toca describir una de las funcionalidades que creo que acabaremos utilizando todos (los que tengamos licenciamiento Enterprise Plus).
Network I/O Control, es el nombre que se le ha dado a las nuevas capacidades para repartir el ancho de banda de red entre los diferentes tipos de flujos de información, algo sumamente importante cuando tenemos interfaces de 10Gb.
Esta funcionalidad solo se puede utilizar con switches distribuidos, por tanto, como decíamos al inicio, requiere la licencia Enterprise Plus.
La forma de implementarlo es sencilla ya que utilizan dos viejos conocidos: shares y limits.
Para activar NetIOC (es el acrónimo que se está difundiendo) nos vamos a la vista de networking y al hacer click sobre el switch destribuido nos aparece en la ventana de laizquierda la pestaña “Resource Allocation”, si hacemos click en el hiperlink “Properties” nos aparece el checkbox de activación, como en la imagen de la cabecera.
En la imagen anterior podemos ver en la columna “Network resource pool” los tipos de tráfico definidos por defecto, con el ancho de banda asignado y la prioridad a la hora de obtener ancho de banda (share).
Con el botón de la derecha sobre un flujo de tráfico, nos aparece la opción “Edit Settings”, pudiendo cambiar el limit y el share.
¿Puedo combinar NetIOC que se aplica a nivel de switch con Traffic Shaping que se aplica a nivel de port-group?
Por supuesto, yo puedo dar un ancho de banda y prioridad concreta al tráfico de las VM con NetIOC y luego tener varios port-groups con VMs, cada uno de ellos con su configuración de Traffic Shaping para aplicar diferentes calidades de servicio entre los port-groups.
Creo que es una gran ayuda para repartir el tráfico en interfaces de red de 10Gb, aunque con interfaces de 1Gb también nos puede ayudar a garantizar anchos de banda por servicio.
Tener en cuenta que para que un switch distribuido tenga la funcionalidad NetIOC se ha de crear en host con vSphere 4.1.
Esto es todo amigos, la semana próxima hablaremos de otra interesante novedad de VMware vSphere ESX/ESXi 4.1.
Todo el sistema funciona bien hasta que un día nos damos cuenta que la velocidad de la copia de seguridad baja de forma considerable y a la par baja el ratio de “copia”.
