Dentro de cada directorio donde VMware alberga una VM se crean unos cuantos ficheros que seguro que hemos visto más de una vez. Estos ficheros sirven para controlar la ejecución de la VM. Sabiendo qué hace cada fichero nos haremos una mejor idea de cómo funciona nuestro ESX.
.VMDK
Son los discos duros de la VM propiamente. Suelen ser los ficheros más grandes del directorio. Su tamaño es mas o menos el tamaño del disco(si usamos discos preallocated) o el tamaño de los datos almacenados en este momento (si usamos discos growables)
.NVRAM
Este fichero contiene la BIOS de la VM.
.VMX
Lo normal es que haya un fichero VMX por cada directorio. Contiene la información de configuracion de la VM en formato texto.(La expresión de Edit Settings en forma de texto). Es editable por un programa de edicion de texto (vi, pico...)
.VMXF
Este fichero, editable también, que está en formato XML, incluye información adicional de la VM si ésta ha estado o está en un team.
.VMTM
Para la VMs que estén formando parte activa de un team
.VMEM
Estos fichero contienen un backup de los ficheros de paginación de la VM. Son muy pequeños o no existirán si la VM está apagada, pero crecerán hasta el tamaño de la RAM configurada si se enciende la VM.
.VMSN y .VMSD
Cuendo creamos snapshot de la VM, estos ficheros se crean para mantener el estado de la VM.
EL fichero con extensión VMSN guarda el estado de ejecución de la VM, es decir, el delta entre el VMDK en el momento del snapshot y lo que ha sido procesado hasta ahora.
El fichero VMSD guarda la informacion de metadata sobre el propio snapshot.
.VMSS
Contiene el estado de suspendido de la VM si es que la hemos suspendido.
martes, 29 de julio de 2008
domingo, 27 de julio de 2008
ESX Server 3i Hosts Without Swap Enabled Cannot be Added to an HA Cluster
Recientemente VMware ha publicado una nota KB en la que se informa que los hosts con la 3i que no tengan habilitado la swap no pueden ser añadidos a un cluster VMware HA
Según el documento esto ocurre desde el VirtualCenter 2.5 Update 1, y los host que lleven la 3i y no tengan habilitada la swap mostrarán un mensaje asi, al intentar ser añadidos al cluster: "An error occurred during configuration of the HA agent of the host." (muy explicito...).
En la pestaña de Tareas y Eventos podemos ver una descripcion asi: "HA agent has an error : Host in HA Cluster must have userworld swap enabled".(esta ya es más explicita)
Para solventarlo y habilitar la swap podemos realizar los siguentes pasos:
Según el documento esto ocurre desde el VirtualCenter 2.5 Update 1, y los host que lleven la 3i y no tengan habilitada la swap mostrarán un mensaje asi, al intentar ser añadidos al cluster: "An error occurred during configuration of the HA agent of the host." (muy explicito...).
En la pestaña de Tareas y Eventos podemos ver una descripcion asi: "HA agent has an error : Host in HA Cluster must have userworld swap enabled".(esta ya es más explicita)
Para solventarlo y habilitar la swap podemos realizar los siguentes pasos:
- Ir a la pestaña Configuration, y a Advanced Settings.
- Elegir ScratchConfig.
- Establecer el parametro ScratchConfig.ConfiguredScratchLocation con un directorio valido con al menos 1GB.
- Seleccionar ScratchConfig.ConfiguredScratchLocation y darle a OK.
- Reboot del host ESX Server 3i.
jueves, 24 de julio de 2008
Cómo crear un Virtual Switch(vswitch) con un numero especifico de puertos
Un pequeño Tip, ahora que estoy volviendo a meterme en harina:
Con el comando esxcfg-vswitch podemos crear un vswitch y a la vez especificar el numero de puertos que queremos que tenga poniendo un ":" despues del nombre del switch.
Ejemplo:
#esxcfg-vswitch -a vSwitchTest:20
Otras acciones que podemos realizar con este comando son:
esxcfg-vswitch [options] [vswitch[:ports]]
-a|--add Add a new virtual switch.
-d|--delete Delete the virtual switch.
-l|--list List all the virtual switches.
-L|--link=pnic Set pnic as an uplink for the vswitch.
-U|--unlink=pnic Remove pnic from the uplinks for the vswitch.
-p|--pg=portgroup Specify a portgroup for operation
Use ALL for operation to work on all portgroups
-v|--vlan=id Set vlan id for portgroup specified by -p
0 would disable the vlan
-c|--check Check to see if a virtual switch exists.
Program outputs a 1 if it exists, 0 otherwise.
-A|--add-pg=name Add a new portgroup to the virtual switch.
-D|--del-pg=name Delete the portgroup from the virtual switch.
-C|--check-pg=name Check to see if a portgroup exists. Program
outputs a 1 if it exists, 0 otherwise.
-r|--restore Restore all virtual switches from the configuration file
(FOR INTERNAL USE ONLY).
-h|--help Show this message.
Con el comando esxcfg-vswitch podemos crear un vswitch y a la vez especificar el numero de puertos que queremos que tenga poniendo un ":" despues del nombre del switch.
Ejemplo:
#esxcfg-vswitch -a vSwitchTest:20
Otras acciones que podemos realizar con este comando son:
esxcfg-vswitch [options] [vswitch[:ports]]
-a|--add Add a new virtual switch.
-d|--delete Delete the virtual switch.
-l|--list List all the virtual switches.
-L|--link=pnic Set pnic as an uplink for the vswitch.
-U|--unlink=pnic Remove pnic from the uplinks for the vswitch.
-p|--pg=portgroup Specify a portgroup for operation
Use ALL for operation to work on all portgroups
-v|--vlan=id Set vlan id for portgroup specified by -p
0 would disable the vlan
-c|--check Check to see if a virtual switch exists.
Program outputs a 1 if it exists, 0 otherwise.
-A|--add-pg=name Add a new portgroup to the virtual switch.
-D|--del-pg=name Delete the portgroup from the virtual switch.
-C|--check-pg=name Check to see if a portgroup exists. Program
outputs a 1 if it exists, 0 otherwise.
-r|--restore Restore all virtual switches from the configuration file
(FOR INTERNAL USE ONLY).
-h|--help Show this message.
martes, 15 de julio de 2008
Vmware HA: Recopilación de Comandos, Logs y Archivos de configuración
Aquí os dejo una recopilación de comandos, logs y archivos de configuración relativos a VMware HA, ls cuales nos pueden servir para realizar troubleshooting cuando las cosas van mal.
Recomiendo primero leerse el post : Como funciona VMware HA?
AAM responde a Automated Availability Manager ("Administrador de Disponibilidad Automatica") y es el demonio que corre en la COS cuando creamos un cluster de VMware HA. Este software es una pieza del de Legato que ha sido renombrado a EMC AutoStart. El demonio mantiene en memoria una pequeña base de datos en los nodos activos del cluster y usa los heartbeats para coordinar los nodos activos y pasivos. Entre otras cosas, por esto se recomienda configurar la COS con 2 interfaces ethernet para no tener un unico punto de fallo.
Resolución de nombres:
La mayor dependencia de este componente es la resolucion de nombres, por ello es importante tener bien configurado estos archivos antes de "enable" VMware HA:
/etc/hosts
/etc/FT_HOSTS
/etc/resolv.conf
/etc/vmware/esx.conf
También antes de habilitar VMware HA se debe comprobar en todos los nodos que el comando #hostname -s nos devuelve el nombre corto de la Service Console, porque si no VMware HA fallará.
Log:
Los archivos de log (como ya comentamos) están en:
De especial antención a la hora de tener problemas es :
#cat /opt/LGTOaam512/log/aam_config_util_addnode.log
Red:
Para evitar situciones de "split brain" en el cluster los ESX pueden determinar cuando han sido aislados y podemos configurar su comportamiento. Cuando el agente de AAM pierde contacto con los demás nodos, lo intenta con el default gateway de la console realizando ICMP echo request (PING).
Si falla, pensará que está aislado y actuará en consecuencia. Por ello, es muy útil configurar varias isolationaddress (Advanced Conf: das.isolationaddress), puesto que si solo tenemos el heartbeat entre los nodos y el ping al gateway, imaginaros lo que ocurriría si cayese durante unos 15 segundo el switch/router al que están conectados nuestros ESX: Cada uno de ellos no veria a los demás y no llegaría con pings al gateway, con lo cual todos pensarian que estan aislados y actuarian en consecuencia(por ejemplo apagandose...).
Resultado: Por unos 15 segundos que nuestro switch/router ha dejado sin link a los ESX, TODAS las VMs han sido apagadas... Un buen marron, para un pequeño corte de red...
Por eso es bueno configurar otra/s das.isolationaddress por la que se puedan "ver" los ESX aunque no lleguen al gateway. (Creo que esto solo es posible en la 3.5)
Comandos y Archivos:
Siguendo con los comandos relacionados con VMware HA tenemos:
/opt/LGTOaam512/bin/ftcli
Esta utilidad nos permite ver los nodos activos en el cluster de HA y nos puede servir para determinar si el agente de HA está corriendo y que IPs están siendo visibles para el host.
Para usarlo primero debemos hacer FT_DIR=/opt/LGTOaam512 y luego export FT_DIR
/etc/FT_HOSTS
Este fichero se crea cuando Vmware HA se habilita y es una copia de /etc/hosts.
Si se tiene problemas con la resolucion de nombres y configurando HA (por ejemplo al cambiar de IP o de nombre a un ESX), podemos borrar este fichero y reconfigurar el nodo para VMware HA, el fichero FT_HOSTS sera recreado.
Recomiendo primero leerse el post : Como funciona VMware HA?
AAM responde a Automated Availability Manager ("Administrador de Disponibilidad Automatica") y es el demonio que corre en la COS cuando creamos un cluster de VMware HA. Este software es una pieza del de Legato que ha sido renombrado a EMC AutoStart. El demonio mantiene en memoria una pequeña base de datos en los nodos activos del cluster y usa los heartbeats para coordinar los nodos activos y pasivos. Entre otras cosas, por esto se recomienda configurar la COS con 2 interfaces ethernet para no tener un unico punto de fallo.
Resolución de nombres:
La mayor dependencia de este componente es la resolucion de nombres, por ello es importante tener bien configurado estos archivos antes de "enable" VMware HA:
/etc/hosts
/etc/FT_HOSTS
/etc/resolv.conf
/etc/vmware/esx.conf
También antes de habilitar VMware HA se debe comprobar en todos los nodos que el comando #hostname -s nos devuelve el nombre corto de la Service Console, porque si no VMware HA fallará.
Log:
Los archivos de log (como ya comentamos) están en:
- ESX 3.0.x: /opt/LGTOaam512/
- ESX 3.5: /opt/VMware/
De especial antención a la hora de tener problemas es :
#cat /opt/LGTOaam512/log/aam_config_util_addnode.log
Red:
Para evitar situciones de "split brain" en el cluster los ESX pueden determinar cuando han sido aislados y podemos configurar su comportamiento. Cuando el agente de AAM pierde contacto con los demás nodos, lo intenta con el default gateway de la console realizando ICMP echo request (PING).
Si falla, pensará que está aislado y actuará en consecuencia. Por ello, es muy útil configurar varias isolationaddress (Advanced Conf: das.isolationaddress), puesto que si solo tenemos el heartbeat entre los nodos y el ping al gateway, imaginaros lo que ocurriría si cayese durante unos 15 segundo el switch/router al que están conectados nuestros ESX: Cada uno de ellos no veria a los demás y no llegaría con pings al gateway, con lo cual todos pensarian que estan aislados y actuarian en consecuencia(por ejemplo apagandose...).
Resultado: Por unos 15 segundos que nuestro switch/router ha dejado sin link a los ESX, TODAS las VMs han sido apagadas... Un buen marron, para un pequeño corte de red...
Por eso es bueno configurar otra/s das.isolationaddress por la que se puedan "ver" los ESX aunque no lleguen al gateway. (Creo que esto solo es posible en la 3.5)
Comandos y Archivos:
Siguendo con los comandos relacionados con VMware HA tenemos:
/opt/LGTOaam512/bin/ftcli
Esta utilidad nos permite ver los nodos activos en el cluster de HA y nos puede servir para determinar si el agente de HA está corriendo y que IPs están siendo visibles para el host.
Para usarlo primero debemos hacer FT_DIR=/opt/LGTOaam512 y luego export FT_DIR
- Lista el manager del cluster: /opt/LGTOaam512/bin/ftcli -domain vmware -timeout 60 -cmd "listrules"
- Lista los nodos del cluster: /opt/LGTOaam512/bin/ftcli -domain vmware -connect %node% -port 8042 -timeout 60 -cmd "listnodes"(Sustituyendo %node%, claro)
/etc/FT_HOSTS
Este fichero se crea cuando Vmware HA se habilita y es una copia de /etc/hosts.
Si se tiene problemas con la resolucion de nombres y configurando HA (por ejemplo al cambiar de IP o de nombre a un ESX), podemos borrar este fichero y reconfigurar el nodo para VMware HA, el fichero FT_HOSTS sera recreado.
viernes, 11 de julio de 2008
Backup de VMware(Image Level, File Level) en Datastores NFS
Se está poniendo de moda usar NFS para albergar nuestras VMs con VMware. La principal desventaja que suelen esgrimir sus detractores es que no puedes usar Virtual Consolidated Backup (VCB).
Aqui tenemos un metodo para poder hacer Backup tanto de los VMDKS(image level) como de los ficheros que estén en los discos duros de nuestros servidores virtuales (ficheros dentro de los vmdk para entendernos) (llamado file level). Con este metodo tambien se puede hacer Restore, incluso provisionning:
El metodo consiste en utilizar un servidor de backup Linux con la distribucion a la que más acostumbrados estemos y montar el volumen NFS o un snapshot del mismo (via cabina, de NetApp, IBM o EMC).
Una vez que nuestro servidor de backup Linux tiene acceso al volumen NFS o a un snapshot del mismo, tendremos que instalar en el Linux, si queremos realizar backup o restore de VMs windows, el soporte de NTFS (si es que no viene instalado, que la mayoria de veces viene).
Lo siguiente es montar el export de NFS en el servidor:
# mount direccion_IP_de_la Cabina:/vol/nfs_de_pruebas /mnt/vm_nfs
Ahora mismo ya podriamos hacer backup de los ficheros VMDK (Image Level Backup) . En NetApp se puede encontrar los snapshots en el directorio .snapshot.
El siguiente paso es realizar backup de los ficheros que queramos que estan dentro de los VMDKs(File Level Backup). Para ello montamos el VMDK en el que estén los archivos que nos interesen.
En el caso de que queramos montar un VMDK de una VM Windows, (es decir el VMDK está formateado en NTFS):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(NTFS), que el acceso es de sólo lectura(dado que es un VMDK de NTFS), el offset del disco y el dispositivo loop.
Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_windows-flat.vmdk /mnt/disco_vmdk_con_NTFS -o ro,loop=/dev/loop2,offset=32256 -t ntfs
De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_NTFS
¿Cómo sabemos el offset?
Pues bien , en nuestra maquina virtual Windows (de la cual queremos hacer algunos file level backups), ejecutaremos msinfo32.exe, luego vamos a Components, a Storage y a Disks.
Anotamos el Partition Starting Offset(Desplazamiento Incial de Particion) y lo ponemos en el comando mount antes descrito.
Se necesita especificar cada offset de cada particion para montarlas. Por ejemplo si tensmos un VMDK formateado en NTFS que tiene dentro la unidad C: y D: . Anotaremos los offsets de ambas particiones y usaremos dos comandos mount para montarlas.
En el caso de que queramos montar un VMDK de una VM Linux, (es decir el VMDK está formateado en ext3 o ext2):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(ext3), que el acceso es de lectura/escritura(dado que es un VMDK de ext3), el offset del disco y el dispositivo loop.
Es muy importante saber que para montar un VMDK que tenga ext3 o ext2 debajo es NECESARIO que el volumen en el que está sea de acceso r/w. Por ejemplo con un snapshot de NetApp, no nos valdría, tendría que ser un FlexClone.
Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_linux-flat.vmdk /mnt/disco_vmdk_con_EXT3 -o loop,offset=32256 -t ext3
De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_EXT3
¿Cómo sabemos el offset?
Podemos usar fdisk -lu en nuestra maquina virtual Linux (de la cual queremos hacer algunos file level backups) para tener el starting sector de cada partition.
Multiplicando este valor por 512 bytes tendremos el valor del offset en bytes que lo colocaremos en la opcion del mount.
En el comando mount especificamos que el FS es ext3. Podemos ver el tipo de FS que es con #df -T
En el caso de una VM linux, existe un caso más: Que se use LVM:
Para montar las particiones no valdrá el metodo anterior. Deberemos usar un FlexClone(un snapshot de lectura/escritura) como en el caso de ext2 ó 3 y usar los comandos:
#mount direccion_IP_de_la Cabina:/vol/vmnfsXXXbk /mnt/vm_nfs
#losetup /dev/loop0 /mnt/vm_nfs/SERVIDORWEB/SERVIDORWEB-flat.vmdk
#kpartx -av /dev/loop0
#vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
#vgchange -ay VolGroup00
2 logical volume(s) in volume group "VolGroup00" now active
#lvs
LogVol00 VolGroup00 -wi-a- 10.0G
LogVol01 VolGroup00 -wi-a- 10.0G
#mount /dev/VolGroup00/LogVol00 /mnt/disco_vmdk_con_LVM
Espero que os resulte útil!
Aqui tenemos un metodo para poder hacer Backup tanto de los VMDKS(image level) como de los ficheros que estén en los discos duros de nuestros servidores virtuales (ficheros dentro de los vmdk para entendernos) (llamado file level). Con este metodo tambien se puede hacer Restore, incluso provisionning:
El metodo consiste en utilizar un servidor de backup Linux con la distribucion a la que más acostumbrados estemos y montar el volumen NFS o un snapshot del mismo (via cabina, de NetApp, IBM o EMC).
Una vez que nuestro servidor de backup Linux tiene acceso al volumen NFS o a un snapshot del mismo, tendremos que instalar en el Linux, si queremos realizar backup o restore de VMs windows, el soporte de NTFS (si es que no viene instalado, que la mayoria de veces viene).
Lo siguiente es montar el export de NFS en el servidor:
# mount direccion_IP_de_la Cabina:/vol/nfs_de_pruebas /mnt/vm_nfs
Ahora mismo ya podriamos hacer backup de los ficheros VMDK (Image Level Backup) . En NetApp se puede encontrar los snapshots en el directorio .snapshot.
El siguiente paso es realizar backup de los ficheros que queramos que estan dentro de los VMDKs(File Level Backup). Para ello montamos el VMDK en el que estén los archivos que nos interesen.
En el caso de que queramos montar un VMDK de una VM Windows, (es decir el VMDK está formateado en NTFS):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(NTFS), que el acceso es de sólo lectura(dado que es un VMDK de NTFS), el offset del disco y el dispositivo loop.
Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_windows-flat.vmdk /mnt/disco_vmdk_con_NTFS -o ro,loop=/dev/loop2,offset=32256 -t ntfs
De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_NTFS
¿Cómo sabemos el offset?
Pues bien , en nuestra maquina virtual Windows (de la cual queremos hacer algunos file level backups), ejecutaremos msinfo32.exe, luego vamos a Components, a Storage y a Disks.
Anotamos el Partition Starting Offset(Desplazamiento Incial de Particion) y lo ponemos en el comando mount antes descrito.
Se necesita especificar cada offset de cada particion para montarlas. Por ejemplo si tensmos un VMDK formateado en NTFS que tiene dentro la unidad C: y D: . Anotaremos los offsets de ambas particiones y usaremos dos comandos mount para montarlas.
En el caso de que queramos montar un VMDK de una VM Linux, (es decir el VMDK está formateado en ext3 o ext2):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(ext3), que el acceso es de lectura/escritura(dado que es un VMDK de ext3), el offset del disco y el dispositivo loop.
Es muy importante saber que para montar un VMDK que tenga ext3 o ext2 debajo es NECESARIO que el volumen en el que está sea de acceso r/w. Por ejemplo con un snapshot de NetApp, no nos valdría, tendría que ser un FlexClone.
Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_linux-flat.vmdk /mnt/disco_vmdk_con_EXT3 -o loop,offset=32256 -t ext3
De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_EXT3
¿Cómo sabemos el offset?
Podemos usar fdisk -lu en nuestra maquina virtual Linux (de la cual queremos hacer algunos file level backups) para tener el starting sector de cada partition.
Multiplicando este valor por 512 bytes tendremos el valor del offset en bytes que lo colocaremos en la opcion del mount.
En el comando mount especificamos que el FS es ext3. Podemos ver el tipo de FS que es con #df -T
En el caso de una VM linux, existe un caso más: Que se use LVM:
Para montar las particiones no valdrá el metodo anterior. Deberemos usar un FlexClone(un snapshot de lectura/escritura) como en el caso de ext2 ó 3 y usar los comandos:
#mount direccion_IP_de_la Cabina:/vol/vmnfsXXXbk /mnt/vm_nfs
#losetup /dev/loop0 /mnt/vm_nfs/SERVIDORWEB/SERVIDORWEB-flat.vmdk
#kpartx -av /dev/loop0
#vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
#vgchange -ay VolGroup00
2 logical volume(s) in volume group "VolGroup00" now active
#lvs
LogVol00 VolGroup00 -wi-a- 10.0G
LogVol01 VolGroup00 -wi-a- 10.0G
#mount /dev/VolGroup00/LogVol00 /mnt/disco_vmdk_con_LVM
Espero que os resulte útil!
miércoles, 9 de julio de 2008
Soporte de SVMotion y 10Gb Ethernet para SANs iSCSI en VMware
La semana del 24 de Junio VMware reportó que con la versión 3.5 Update 1 Storage VMotion es soportado oficialmente para las SANs iSCSI. Esto nos permite reorganizar las VMs sin down time para adecuarlas a nuestras necesidades de almacenamiento.
SVMotion nos permite:
Según explican, se pueden mover VMs:
Además ha aprovechado para soportar el uso de 10Gb Ethernet para iSCSI en un entorno de VMware Infrastructure.
SVMotion nos permite:
- Mover VM a un nuevo array para hacer operaciones sobre dicho array.
- Mover los discos de las VMs a una capa de almacenamiento diferente para adecuarls a las necesidades
- Resolver problemas de rendimiento causado por la configuracion del almacenamiento o demasiada carga en una LUN en concreto.
Según explican, se pueden mover VMs:
- De iSCSI SANs a otras iSCSI SANs
- De iSCSI SANs a FibreChannel SANs
- De FibreChannel SANs a iSCSI SANs
Además ha aprovechado para soportar el uso de 10Gb Ethernet para iSCSI en un entorno de VMware Infrastructure.
sábado, 5 de julio de 2008
P2V de Linux
Aquí os dejo cómo realizar P2V de un Linux de forma rapida, que hay muchas formas, esta es una de ellas:
Software necesario:
Red Hat / Fedora Linux CD1 (culaquier version)
VMware Converter 3.x / 4.x
Convirtiendo el Servidor Fisico:
Convertir el servidor físico a VM usando el VMware Converter bootcd.
Limpiamos la VM:
Una vez realizada la conversión, hacemos "edit properties" y quitamos hardware innecesario.
VMware Tools
Software necesario:
Red Hat / Fedora Linux CD1 (culaquier version)
VMware Converter 3.x / 4.x
Convirtiendo el Servidor Fisico:
Convertir el servidor físico a VM usando el VMware Converter bootcd.
Limpiamos la VM:
Una vez realizada la conversión, hacemos "edit properties" y quitamos hardware innecesario.
- Hacemos un Snapshot antes de cambiar nada.
- Quitamos USB controllers, Serial ports, parallel ports, floppy drives
- Cambiamos la controladora de HD de Buslogic a LSI logic si es necesario:
- Configuramos la VM para arrancar desd el CD en la bios de la VM
- Conectamos en CD1 de Red Hat. Ponemos: Connected y Connect at Power on
- Iniciamos la VM con el Redhat CD1. (aceptamos el cambio de HD type a LSI logic)
- Seguimos el articulo de VMware KB para reconfigurar el hardware de la VM
- Y comprobamos que la VM se inicia correctamente despues de los cambios.
VMware Tools
- Nos ponemos en la Console de la VM. Selecionamos Install/Upgrade VMware tools del menu.
- Montamos el cdrom virtual con el comando (por ejemplo): #mount /dev/hda/ /media/cdrom
- Instalamos el rpm: rpm –i /media/cdrom/VMwareTools-xxxx.xxx.rpm (el xxx dependerá de la version del ESX y del linux)
- Corremos vmware-config-tools.pl y completamos la instalación.
jueves, 3 de julio de 2008
Buscar Snapshots de VMs desde la Console
Pues nada, un comando que nos permite ver de forma rápida si en nuestro servidor ESX tenemos Snapshots y en qué VMs las tenemos.
Es algo muy tipico hacer un Snapshot y olvidarnoslo que lo tenemos, ocasionando perdida de rendimiento y a veces problemas muy graves.(Que se pueden solucionar usando el Converter)
Hay otras utilidades para verlo de forma más elegante (se llama SnapHunter y lo comenté aquí), pero esta es tan potente como directa:
# ls -Ral /vmfs/volumes/* | grep .vmsn
También podríamos usar:
# find /vmfs/volumes/ -iname "*-delta.vmdk"
Esto te puede encontrar Snapshots mal borrados además de los normales.
¿Alguien sabe alguna forma más?
Es algo muy tipico hacer un Snapshot y olvidarnoslo que lo tenemos, ocasionando perdida de rendimiento y a veces problemas muy graves.(Que se pueden solucionar usando el Converter)
Hay otras utilidades para verlo de forma más elegante (se llama SnapHunter y lo comenté aquí), pero esta es tan potente como directa:
# ls -Ral /vmfs/volumes/* | grep .vmsn
También podríamos usar:
# find /vmfs/volumes/ -iname "*-delta.vmdk"
Esto te puede encontrar Snapshots mal borrados además de los normales.
¿Alguien sabe alguna forma más?
martes, 1 de julio de 2008
La compra de B-hive por parte de Vmware
Recientemente (finales de Mayo) VMware ha comenzado el proceso de compra de la compañia B-Hive. Como reza el comunicado de prensa : "B-Hive proporciona una visión de infraestructura en el rendimiento de aplicaciones (albergadas por entornos virtuales) tales como el tiempo de respuesta del usuario en las transacciones, utilizaciones de VMs y dependencia cruzadas de VMs".
De lo que se trata es de proveer una mayor cantidad de datos a herramientas como DRS y soluciones de management de forma que se pueda resolver problemas de rendimiento de las aplicaciones de forma proactiva realizando acciones como reservar dinamicamente más recursos, migrar las aplicaciones a otro servidor, aprovisionar otras VMs, cambiar el rutado de las transacciones o incluso reinicar el sistema.
La idea basica detrás de un APM (Application Performance Manager) es medir la experiencia del usuario o el rendimiento de las aplicaciones (cómo de rapido esta la apliacion procesando transacciones o unidades de trabajo desde que llegan de los usuarios u otras aplicaciones)
B-hive mide el tiempo de respuesta desde la perspectiva del la capa de presentación(el web server por ejemplo). Las soluciones de APM más antiguas infieren el rendimiento de las aplicaciones mirando los recursos que usan lo cual no es buena aproximación para un entorno virtual.
Funcionamiento General:
B-hive escucha en un puerto mirror (spanned) en el switch que está más cercano a los usuarios, lo que le permite ver las transacciones. En un entorno virtual, B-hive es implementado (de momento) como una virtual appliance que se une al mirror port del virtual switch dentro del ESX.
Mide el tiempo de respuesta entre las peticiones y la respuesta de la apliacaion a determinadas transacciones atomicas (o casi). Dichas operaciones no son algo palpable(xej una pagina web) desde el punto de vista del usuario sino que son opreaciones más pequeñas que dan una idea al personal de IT de cómo va la aplicacion. (El nivel de las transacciones atomicas depende de la aplicacion. Para web son HTTP tiempo peticion/respuesta. Para las que no son web las transacciones son a nivel TCP/IP tiempo peticion/respuesta o a Base de Datos tiempo peticion/respuesta.)
Lo bueno del producto es que es sin agente e independiente del OS de la VM y da el primer paso para proporcionar mejores datos para implementar el modelo de Data center de nube dinamica que es lo que persigue VMware(yo creo que es un buen movimiento de VMware).
Con este producto VMware conseguirá varias cosas (en mi opinion): será capaz de darnos una idea muy concreta de cómo van nuestras aplicaciones virtualizadas, consiguiendo por un lado que podamos dar unos determinados SLAs y por otro que nos atrevamos a realizar virtualizacion de aplicaciones más criticas. Además, ha pegado un mazazo a Citrix Y Microsoft que ahora se tendran que poner las pilas y por ultimo ha provocado una carrera en el mercado de los APM para posicionarse en el mercado de la virtualización.
Aqui os dejo un grafico que ve de foma general el mercado de los APMs. Algunos de los mejor emplazados son Akorri, vmSight y B-Hive.
Se supone que habra movimientos en breve por parte de Microsoft, Citrix, y algunos APMs.
De lo que se trata es de proveer una mayor cantidad de datos a herramientas como DRS y soluciones de management de forma que se pueda resolver problemas de rendimiento de las aplicaciones de forma proactiva realizando acciones como reservar dinamicamente más recursos, migrar las aplicaciones a otro servidor, aprovisionar otras VMs, cambiar el rutado de las transacciones o incluso reinicar el sistema.
La idea basica detrás de un APM (Application Performance Manager) es medir la experiencia del usuario o el rendimiento de las aplicaciones (cómo de rapido esta la apliacion procesando transacciones o unidades de trabajo desde que llegan de los usuarios u otras aplicaciones)
B-hive mide el tiempo de respuesta desde la perspectiva del la capa de presentación(el web server por ejemplo). Las soluciones de APM más antiguas infieren el rendimiento de las aplicaciones mirando los recursos que usan lo cual no es buena aproximación para un entorno virtual.
Funcionamiento General:
B-hive escucha en un puerto mirror (spanned) en el switch que está más cercano a los usuarios, lo que le permite ver las transacciones. En un entorno virtual, B-hive es implementado (de momento) como una virtual appliance que se une al mirror port del virtual switch dentro del ESX.
Mide el tiempo de respuesta entre las peticiones y la respuesta de la apliacaion a determinadas transacciones atomicas (o casi). Dichas operaciones no son algo palpable(xej una pagina web) desde el punto de vista del usuario sino que son opreaciones más pequeñas que dan una idea al personal de IT de cómo va la aplicacion. (El nivel de las transacciones atomicas depende de la aplicacion. Para web son HTTP tiempo peticion/respuesta. Para las que no son web las transacciones son a nivel TCP/IP tiempo peticion/respuesta o a Base de Datos tiempo peticion/respuesta.)
Lo bueno del producto es que es sin agente e independiente del OS de la VM y da el primer paso para proporcionar mejores datos para implementar el modelo de Data center de nube dinamica que es lo que persigue VMware(yo creo que es un buen movimiento de VMware).
Con este producto VMware conseguirá varias cosas (en mi opinion): será capaz de darnos una idea muy concreta de cómo van nuestras aplicaciones virtualizadas, consiguiendo por un lado que podamos dar unos determinados SLAs y por otro que nos atrevamos a realizar virtualizacion de aplicaciones más criticas. Además, ha pegado un mazazo a Citrix Y Microsoft que ahora se tendran que poner las pilas y por ultimo ha provocado una carrera en el mercado de los APM para posicionarse en el mercado de la virtualización.
Aqui os dejo un grafico que ve de foma general el mercado de los APMs. Algunos de los mejor emplazados son Akorri, vmSight y B-Hive.
Se supone que habra movimientos en breve por parte de Microsoft, Citrix, y algunos APMs.
Suscribirse a:
Entradas (Atom)
Entradas
