Volviendo al Belkin F5L009EA, decir que lo bueno que tiene es que es compatible con Windows 2008, que es fácil de configurar, y por otro lado decir que si el programa o el control se pusiera como servicio, ya sería la leche. Ya que en mi caso, se activa antes que nada el programa Logred de Logic Control, que es el que controla la mochila, y por lo tanto no es capaz de ver el dongle, por que todavía no ha cargado el controlador de mochilas de Belkin.

Imagino que ya lo irán puliendo

BELKIN F5L009EA comparte dongles USB en VMWARE

La tarea de configurar el cronjobs para sistemas operativos ESX de VMware no es muy diferente a los demás sistemas operativos Linux, pero en VMware ESXi por el contrario, hay que tener francamente en cuenta por que los cambios realizados no persisten cuando reiniciamos el sistema VMware.

Una vez tenemos descargado ghettoVCB de http://communities.vmware.com/docs/DOC-8760 , lo único que tenemos que hacer es un upload a un datastore de VMware en el que queramos alojar el script ghettoVCB.

Podemos acceder con Putty a la consola de nuestro sistema ESXi, desde aquí podréis ir a descargar directamente a la web oficial el programa Putty, A Free Telnet/SSH Client

Y algunos os preguntaréis ¿Cómo abrir el puerto ssh en VMware ESXi?, pues ahí está.

Ejecutamos Putty, y le ponemos la IP del host VMware donde vamos a conectarnos, usuario y contraseña.

Y vamos a suponer lo siguiente:

/vmfs/volumes/datastore2/backup

Será el sitio donde pondremos el script ghettoVCB y el archivo “machines” donde especificaremos las vm que queremos efectuar copia

/vmfs/volumes/datastore3/logs

Será el sitio donde pondremos los logs que genere el script de ghettoVCB
 
Vamos a programar cronjobs para ghettoVCB
 
Vamos a:

vi /var/spool/cron/crontabs/root

Y añadimos al final del archivo lo siguiente:

~ # 0 21 * * * /vmfs/volumes/datastore2/backup/ghettoVCB.sh -f /vmfs/volumes/datastore2/backup/machines > /vmfs/volumes/datastore3/logs/ghettoVCB-backup-$(date +\%s).log

Donde pone 21 le ponemos la hora a la que queramos hacer el backup.

Salimos grabando del comando vi con ESC y tecleamos

:wq!

Eliminaremos la anterior programación de CRONJOBS de la siguiente manera:

~ # kill $(cat /var/run/crond.pid)
~ # busybox crond

Y luego editaremos el rc.local y nos encontraremos lo siguiente (en verde) y le añadiremos (lo azul), ejecutando:

~ # vi /etc/rc.local

~ # cat /etc/rc.local
#! /bin/ash
export PATH=/sbin:/bin

#execute all service retgistered in /etc/rc.local.d
if [http:// -d /etc/rc.local.d |http:// -d /etc/rc.local.d ]; then
   for filename in `find /etc/rc.local.d/ | sort`
      do
         if [ -f $filename ] && [ -x $filename ]; then
            log "running $filename"
            $filename
         fi
      done
fi
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 21 * * * /vmfs/volumes/datastore2/backup/ghettoVCB.sh -f /vmfs/volumes/datastore2/backup/machines > /vmfs/volumes/datastore3/logs/ghettoVCB-backup-\$(date +\\%s).log" >> /var/spool/cron/crontabs/root
/bin/busybox crond


Salimos grabando del comando vi con ESC :wq!

Para asegurarnos que el CRONJOB se creará después de reiniciar físicamente el HOST ejecutaremos lo siguiente:

~ # /sbin/auto-backup.sh

Y nos aparecerá algo como esto que pongo más abajo en naranja

config implicitly loaded
local.tgz
etc/vmware/vmkiscsid/vmkiscsid.db
etc/dropbear/dropbear_dss_host_key
etc/dropbear/dropbear_rsa_host_key
etc/opt/vmware/vpxa/vpxa.cfg
etc/opt/vmware/vpxa/dasConfig.xml
etc/sysconfig/network
etc/vmware/hostd/authorization.xml
etc/vmware/hostd/hostsvc.xml
etc/vmware/hostd/pools.xml
etc/vmware/hostd/vmAutoStart.xml
etc/vmware/hostd/vmInventory.xml
etc/vmware/hostd/proxy.xml
etc/vmware/ssl/rui.crt
etc/vmware/ssl/rui.key
etc/vmware/vmkiscsid/initiatorname.iscsi
etc/vmware/vmkiscsid/iscsid.conf
etc/vmware/vmware.lic
etc/vmware/config
etc/vmware/dvsdata.db
etc/vmware/esx.conf
etc/vmware/license.cfg
etc/vmware/locker.conf
etc/vmware/snmp.xml
etc/group
etc/hosts
etc/inetd.conf
etc/rc.local
etc/chkconfig.db
etc/ntp.conf
etc/passwd
etc/random-seed
etc/resolv.conf
etc/shadow
etc/sfcb/repository/root/interop/cim_indicationfilter.idx
etc/sfcb/repository/root/interop/cim_indicationhandlercimxml.idx
etc/sfcb/repository/root/interop/cim_listenerdestinationcimxml.idx
etc/sfcb/repository/root/interop/cim_indicationsubscription.idx
Binary files /etc/vmware/dvsdata.db and /tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db differ
config implicitly loaded
Saving current state in /bootbank
Clock updated.
Time: 20:40:36   Date: 08/14/2009   UTC


Y ya está configurado cronjobs para que cuando se reinicie nuestro host VMware ESXi, se puedan efectuar las copias de seguridad con el script ghettoVCB

Como programar tarea ghettoVCB en Cronjobs para VMware ESXi

Somos muchos los que utilizamos ghettoVCB por la patilla en productos ESX y ESXi de VMware, este maravilloso script que nos hace la vida tan cómoda, imagino que en todos los niveles, desde los que tenemos entornos virtualizados no muy complejos hasta los que ya no lo son tanto. Por otro lado también somos muchos los que hemos sufrido sus pequeñeces pero eso no tiene realmente gran importancia si lo comparamos con el tesón, motivación y sobre todo ganas de compartir su conocimiento técnico de William Lam para que podamos estar tranquilos con nuestras copias de seguridad de vm’s en VMware.

De verdad, nosotros personalmente, estamos muy agradecidos, por que si no fuera por gente como William Lam y en este caso ghettoVCB, la virtualización de entornos pequeñitos no sería posible ya que los costes de los programas de copias de seguridad para VMware son para pequeñas empresas prohibitibos. Por esto, queremos dar las gracias a William Lam por hacer de ghettoVCB más que un simple script de código.

Agradecimientos a William Lam por todo su trabajo en el Script de ghettoVCB

Esta sería otra manera de programar una copia de seguridad en ghettoVCB.sh con la aplicación Plink.exe. En los enlaces podemos pinchar para descargar este software. También podremos descargar el archivo template para que ghettoVCB.sh pueda llamar a las VMs que queremos efectuar copia de seguridad.

Primero de todo deberemos de habilitar el puerto 22 de ssh en nuestro ESXi.

Descargaremos este software y lo pondremos en una carpeta en nuestra máquina de Windows Lanzadera. Llamémosla “Lanzadera”

Configuraremos ghettoVCB.sh (destino de copia, que historial de copias queremos, etc) y prepararemos el archivo template como si estuviera puesto en un servidor ESXi.

Una vez está preparada desde el VI CLient(ESXi v3.5) o VSphere Client (ESXi v4.0) crearemos en algún datastore del servidor ESXi una carpeta que por ejemplo se llame “backup”, y subiremos el archivo ghettoVCB.sh y el archivo_template donde ya habremos puesto los nombres de las VMs virtuales a copiar.

Una vez subido los archivos al datastore, crearemos un archivo con extensión .bat en el equipo con Windows, que lo podremos llamar como queramos.

Y en su interior indicaremos los siguiente:

Sintaxi:

plink -ssh -pw nuestro_password  usuario_poder@ipservidor_esxi  /ruta_archivo.sh/archivo.sh

Ejemplo práctico:

plink -ssh -pw Pass root@172.26.0.250 /vmfs/volumes/datastore1/backup/ghettoVCB.sh

Donde Pass será nuestro password del root en el host ESXi.

Guardaremos el archivo.bat y lo podemos ejecutar, veremos que se lanza el Plink.exe y comienza a hacer la copia de seguridad con ghettoVCB

Y ya para rematarlo, podremos incluir en nuestro Programador de tareas el trabajo.

Y listo

 Programar una copia de seguridad de ghettoVCB.sh con Plink.exe

Aprovecho a pasar el link de las HCL de VMware, el VMware Compatibility Guide http://www.vmware.com/resources/compatibility/search.php 

Y así, iremos más sobre seguro. 

Dell T110 con controladora S100 RAID no compatible con VMware

Vamos a hacer una tabla tipo empírico donde iremos nutriendo de datos referente a copias de máquinas virtuales vmdk de VMware a otros dispositivos como pueden ser un NAS o un disco duro.

Tendremos en cuenta que tipo de equipo (procesador, gigas de RAM, si tiene RAID, tipos de discos), el tipo de red, el swtich, si la máquina está o no encendida dependiendo de si el software permite efectuar la copia, el tamaño de la máquina virtual vmdk y el software utilizado para hacerlo.

De Dell T110 a Qnap TS239ProII

De Dell T610 a Qnap TS239ProII

De Dell T610 a Qnap TS239ProII

De Qnap TS239ProII a Dell T110 con I/O Perc 6iR w/Battery con ghettoVCB

Comparativa velocidad copias VMware vmdk con programas de terceros

ghettoVCB.sh – alternativa gratuita para hacer copias de seguridad para la máquina virtual ESX (i) 3,5 y 4,0 +

Artículo sacado de http://communities.vmware.com/docs/DOC-8760 y traducido por Google Translator

VERSIÓN 47 Publicado

Creado en: Nov 17, 2008 7:04 PM por lamw — Última modificación: Nov 25, 2009 2:39 PM por lamw

Tabla de Contenidos:

• �
  • Descripción
  • Características
  • Requisitos
  • Configuración
  • Configuraciones
  • Uso
  • Ejemplo de ejecución de
    • Copia de seguridad de máquinas virtuales almacenadas en una lista de
    • Copia de seguridad de máquinas virtuales utilizando las diferentes políticas de copia de seguridad de
    • Modo de depuración de copia de seguridad
    • Dry Run Mode
  • Habilitar la compresión de las copias de seguridad
  • Restaurar copias de seguridad (ghettoVCB-restore.sh)
  • Cronjob FAQ
  • Preguntas frecuentes
  • Enlaces de interés
  • Change Log

Descripción:

Este script realiza copias de seguridad de las máquinas virtuales que residen en ESX (i) + 3.5/4.0 servidores utilizando una metodología similar a la VMware VCB herramienta. El script toma imágenes de las máquinas virtuales en vivo, apoya la VMDK maestro (s) y luego una vez finalizada, se elimina la instantánea hasta que la próxima copia de seguridad. La única salvedad es que utiliza los recursos disponibles para la consola de servicio del servidor ESX ejecutando las copias de seguridad en vez de seguir el método tradicional de descarga de copias de seguridad de la máquina virtual a través de un proxy de VCB.

Este script ha sido probado en 3.5/4.0 ESX y ESXi 3.5/4.0 y apoya a los medios de copia de seguridad siguientes: Almacenamiento local, SAN y NFS. El guión no es interactiva y puede ser configurado para funcionar a través de crontab. Actualmente, este script acepta un archivo de texto que enumera los nombres de pantalla de la máquina virtual (s) que deben ser respaldados. Además, se puede especificar una carpeta que contiene archivos de configuración en una base por VM para el control granular sobre políticas de backup.

Además, para los entornos de ESX que no tienen almacenes de datos persistentes NFS designadas para copias de seguridad, la secuencia de comandos ofrece la posibilidad de que se conecte automáticamente al servidor ESX a un NFS exportado carpeta y luego al término de copia de seguridad, desconecte del servidor ESX. La conexión se establece mediante la creación de un enlace de NFS almacén de datos que permite monolítico (o grosor) VMDK copias de seguridad en lugar de utilizar la habitual * nix comando mount que requiere romper los archivos en el formato VMDK 2gbsparse para copia de seguridad. Habilitación de este modo se explica por sí mismo y, evidentemente, será por lo que cuando la secuencia de comandos de edición (Nota: VM_BACKUP_VOLUME variable se ignora si ENABLE_NON_PERSISTENT_NFS = 1 ).

En su configuración actual, la secuencia de comandos permitirá un máximo de 3 copias de seguridad exclusivo de la máquina virtual antes de que pueda sobrescribir las copias de seguridad anteriores, lo que sin embargo, puede ser modificado para ajustarse a los procedimientos en caso necesario. Por favor, ser diligente en la ejecución del script en una prueba o ensayo medio ambiente antes de utilizarlo en la producción en vivo de máquinas virtuales, lo que las funciones de script y dentro de nuestro ambiente, pero existe la posibilidad de que no puede encajar bien en otros ambientes.

Características

• Soporte para disco VMDK múltiples (s) de copia de seguridad por VM
• Sólo VMDK válido (s) presentado a la máquina virtual será respaldado
• En línea una copia de seguridad de VM (s) de
• Posibilidad de apagar guestOS e iniciar el proceso de copia de seguridad y el poder en VM después con la opción de tiempo de espera hardpower
• Permitir espacios en VM (s) de la lista de copia de seguridad (no se recomienda y no como una mejor práctica)
• Asegúrese de que proceso de eliminación instantánea completa antes de continuar en la próxima copia de seguridad de VM
• VM (s) que inicialmente contienen instantáneas no será una copia de seguridad y será ignorado
• La capacidad de especificar el número de rotaciones de copia de seguridad de VM
• Salida de copia de seguridad de VMDK (s) en cualquiera de ZEROEDTHICK (comportamiento por defecto) o 2GB escasa o THIN o EAGERZEROEDTHICK formato
• Soporte para discos SCSI e IDE
• No persistentes de copia de seguridad de NFS
• Apoyo plenamente VMDK (s) almacenados en almacenes de datos múltiples
• Capacidad de comprimir las copias de seguridad (soporte experimental)
• Capacidad de configurar las diferentes políticas de copia de seguridad VM ¡NUEVO!
• Posibilidad de incluir / excluir VMDK específico (s) por máquina virtual (VM instalación individual requiere la política de copia de seguridad) ¡NUEVO!
• Posibilidad de configurar el registro de salida a archivo ¡NUEVO!
• Conciencia de disco independiente (ignorará VMDK) ¡NUEVO!
• Las variables de tiempo de espera de nuevo para apagar y creaciones de instantáneas ¡NUEVO!
• Posibilidad de configurar las instantáneas con la memoria y / o inactividad opciones ¡NUEVO!
• Capacidad de disco de formato adaptador de configurar ¡NUEVO!
• De información de depuración adicional que incluye la ejecución en seco ¡NUEVO!
• Soporte para las máquinas virtuales con tanto virtuales / RDM física (pRDM serán ignoradas y no una copia de seguridad) ¡NUEVO!

Requisitos:

• Máquinas virtuales se ejecutan en ESX (i) + 3.5/4.0
• SSH para acceso a la consola ESX / ESXi de acogida

Instalación:

1) Descarga ghettoVCB.sh ya sea a su sistema de ESX o ESXi

2) Cambiar los permisos de la secuencia de comandos para asegurarse de que puede ser ejecutado:

[root @ Himalaya ~] # chmod + x ghettoVCB.sh

Configuraciones:

Las siguientes variables deben ser definidas en el script o en la política de VM de copia de seguridad antes de la ejecución.

Definir el almacén de datos de copia de seguridad y la carpeta en la que se almacenan las copias de seguridad (si la carpeta no existe, se creará automáticamente): = VM_BACKUP_VOLUME / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS

Definir el formato de disco de copia de seguridad (zeroedthick, eagerzeroedthick, delgado, y 2gbsparse están disponibles):
DISK_BACKUP_FORMAT = delgada

Definición de la rotación de copia de seguridad por VM:
VM_BACKUP_ROTATION_COUNT = 3

Definir si la VM está apagado o no antes de la copia de seguridad (1 = activar, 0 = desactivado):

Nota: VM (s) que están apagados no requerirá snapshoting
POWER_VM_DOWN_BEFORE_BACKUP = 0

Definir si la máquina virtual puede ser difícil de apagado cuando “POWER_VM_DOWN_BEFORE_BACKUP” está habilitada y VM no se han instalado las herramientas de VMware
ENABLE_HARD_POWER_OFF = 0

Si “ENABLE_HARD_POWER_OFF” está habilitado, entonces se define el número de (60 segundos) iteraciones de la secuencia de comandos antes de que la ejecución de un poder de desactivación cuando:
ITER_TO_WAIT_SHUTDOWN = 3

El número (60 segundos) iteraciones de la secuencia de comandos esperar cuando apagar la máquina virtual y le dará e ignoran la máquina virtual de particular para copia de seguridad:
POWER_DOWN_TIMEOUT = 5

El número (60 segundos) iteraciones de la secuencia de comandos esperar la hora de tomar una instantánea de una máquina virtual y le dará e ignoran la máquina virtual de particular para copia de seguridad:

El valor por defecto debería ser suficiente
SNAPSHOT_TIMEOUT = 15

Definir si debe o no habilitar la compresión (1 = activar, 0 = desactivado):
ENABLE_COMPRESSION = 0

Definir el tipo de adaptador para copia de seguridad de VMDK (BusLogic y lsilogic están disponibles):
ADAPTER_FORMAT = BusLogic

Definir si la memoria de la máquina virtual se quebró y si quiescing está habilitado (1 = activar, 0 = desactivado):

Nota: Por defecto, ambos son personas de movilidad reducida
VM_SNAPSHOT_MEMORY = 0 VM_SNAPSHOT_QUIESCE = 0

* Definición de VMDK (s) de copia de seguridad de una máquina virtual particular, ya sea una lista de vmdks o “todos”
VMDK_FILES_TO_BACKUP = "myvmdk.vmdk"

Asegúrese de que usted no edita pasado esta sección:
########################## NO MODIFIQUE EL PASADO DE ESTA LÍNEA ################## ########

Uso:

[root @ Himalaya ~] #. / ghettoVCB.sh ################################################## ############################# # GhettoVCB # para ESX / ESXi 3.5 y 4.x + # Autor: William Lam # Http://www.engineering.ucsb.edu/ ~ / duonglt vmware / # Creado: 11/17/2008 # Última modificación: 11/14/2009 # ################################################## ############################# Uso:. / GhettoVCB.sh-f [VM_BACKUP_UP_LIST]-c [VM_CONFIG_DIR]-l [log_file] OPCIONES:    -F Lista de máquinas virtuales para copia de seguridad    -c directorio de configuración de copias de seguridad de VM    -L a la salida del archivo de registro    el nivel de depuración-d [info | | depuración dryrun] (por defecto: info) (por ejemplo) Copia de seguridad de máquinas virtuales almacenadas en una lista de         . / ghettoVCB.sh-f vms_to_backup Copia de seguridad de máquinas virtuales basadas en la configuración específica situada en el directorio de         . / ghettoVCB.sh vms_to_backup-f-c vm_backup_configs Salida de registro en / tmp / ghettoVCB.log         . / ghettoVCB.sh vms_to_backup-f-l / tmp / ghettoVCB.log Marcha en seco (no copia de seguridad se llevará a cabo)         . / f-ghettoVCB.sh vms_to_backup-d dryrun

La entrada a este script es un archivo que contiene el nombre de pantalla de la máquina virtual (s) separados por un salto de línea. Al crear este archivo en un sistema non-Linux/UNIX, puede introducir el carácter ^ M, que puede hacer que el script para miss-se comportan. Para garantizar que esto no ocurra, plesae crear el archivo en el ESX / ESXi de acogida.

Aquí está una muestra de lo que el archivo se vería así:

[root @ Himalaya ~] vms_to_backup # cat VCAP VIMA VMA-2

Ejemplo de ejecución:

• Copia de seguridad de máquinas virtuales almacenadas en una lista de
• Copia de seguridad de máquinas virtuales basadas en las diferentes políticas de copia de seguridad de VM
• Modo de depuración
• Dry Run Mode

Copia de seguridad de máquinas virtuales almacenadas en una lista de

• Verbosidad Log: info (por defecto)
• Salida de registro: stdout (por defecto)

[root @ Himalaya ~] #. / ghettoVCB.sh-f vms_to_backup 2009-11-12 06:14:10 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-12 06:14:10 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:14:10 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:14:10 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:14:10 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:14:10 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:14:10 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:14:10 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-12 06:14:10 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:14:10 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:14:10 - info: config - log_level = info 2009-11-12 06:14:10 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:14:10 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:14:10 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:14:10 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:14:15 - info: Iniciar la copia de seguridad para VCAP Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_1.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP-0.vmdk' ... Clon: 100% hecho. 2009-11-12 06:15:15 - Información: Duración de copia de seguridad: 60 segundos 2009-11-12 06:15:15 - info: copia de seguridad con éxito para VCAP! 2009-11-12 06:15:17 - info: Iniciar la copia de seguridad para VIMA 2009-11-12 06:15:17 - info: Creación de instantáneas "ghettoVCB instantánea-2009-11-12" para VIMA Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. 2009-11-12 06:16:40 - info: instantánea Eliminación de VIMA ... 2009-11-12 06:16:43 - Información: Duración de copia de seguridad: 1,43 minutos 2009-11-12 06:16:43 - info: copia de seguridad con éxito para VIMA! 2009-11-12 06:16:47 - info: Iniciar la copia de seguridad para VMA-2 Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho. 2009-11-12 06:18:14 - Información: Duración de copia de seguridad: 1,45 minutos 2009-11-12 06:18:14 - info: copia de seguridad con éxito para VMA-2! 2009-11-12 06:18:14 - info: ============================== ghettoVCB LOG FIN === =============================

Copia de seguridad de máquinas virtuales basadas en las diferentes políticas de copia de seguridad de VM y registro de salida a / tmp / ghettoVCB.log

• Verbosidad Log: info (por defecto)
• Registra el resultado: / tmp / ghettoVCB.log (por defecto)

1. Crear carpeta para almacenar las diferentes políticas de VM de copia de seguridad (puede tener cualquier nombre):
[root @ Himalaya ~] # mkdir backup_config

2. Crear copia de seguridad de las diferentes políticas de máquina virtual para cada máquina virtual que asegurar que cada archivo se llama exactamente como el nombre de pantalla de la máquina virtual se copia de seguridad (uso de la plantilla proporcionada para crear duplicados “):
[root @ Himalaya backup_config] ghettoVCB # cp-vm_backup_configuration_template VCAP [root @ Himalaya backup_config] ghettoVCB # cp-vm_backup_configuration_template VIMA

Listado de la política de máquina virtual de directorio de configuración de copia de seguridad de copia de seguridad de
[root @ Himalaya backup_config] # ls ghettoVCB-vm_backup_configuration_template VCAP VIMA

La política de copia de seguridad de “VCAP” (copia de seguridad VMDKs sólo 2 específicos)
[root @ Himalaya backup_config] # cat VCAP = VM_BACKUP_VOLUME / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS DISK_BACKUP_FORMAT = delgada VM_BACKUP_ROTATION_COUNT = 3 POWER_VM_DOWN_BEFORE_BACKUP = 0 ENABLE_HARD_POWER_OFF = 0 ITER_TO_WAIT_SHUTDOWN = 4 POWER_DOWN_TIMEOUT = 5 SNAPSHOT_TIMEOUT = 15 ENABLE_COMPRESSION = 0 ADAPTER_FORMAT = BusLogic VM_SNAPSHOT_MEMORY = 0 VM_SNAPSHOT_QUIESCE = 0 VMDK_FILES_TO_BACKUP = "VCAP.vmdk, VCAP_2.vmdk"

La política de copia de seguridad de VM “VIMA” (copia de seguridad de todos los VMDKs encontrados)
[root @ Himalaya backup_config] # cat VIMA = VM_BACKUP_VOLUME / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS DISK_BACKUP_FORMAT = delgada VM_BACKUP_ROTATION_COUNT = 3 POWER_VM_DOWN_BEFORE_BACKUP = 0 ENABLE_HARD_POWER_OFF = 0 ITER_TO_WAIT_SHUTDOWN = 4 POWER_DOWN_TIMEOUT = 5 SNAPSHOT_TIMEOUT = 15 ENABLE_COMPRESSION = 0 ADAPTER_FORMAT = BusLogic VM_SNAPSHOT_MEMORY = 1 VM_SNAPSHOT_QUIESCE = 0 VMDK_FILES_TO_BACKUP = "todos"

Nota: Al especificar la opción-c (individual VM modo la política de copia de seguridad), si una máquina virtual aparece en la lista de copia de seguridad, pero NO tener una política de copia de seguridad correspondiente, la máquina virtual se complementará con la configuración predeterminada encuentra dentro de la secuencia de comandos ghettoVCB.sh.

Ejecución de copia de seguridad
[root @ Himalaya ~] #. / f-ghettoVCB.sh vms_to_backup-c backup_config-l / tmp / ghettoVCB.log Registro de salida a "/ tmp / ghettoVCB.log" ... Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho.

Nota: Al especificar la opción-l (registro de salida de archivo), vmkfstools copia también se registra la salida estándar. Esto se hace principalmente para fines de depuración.

Registro de salida de copia de seguridad de
[root @ Himalaya ~] # cat / tmp / ghettoVCB.log 2009-11-12 06:26:53 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-12 06:26:56 - info: config - mediante una configuración FILE = backup_config / VCAP 2009-11-12 06:26:56 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:26:56 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:26:56 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:26:56 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:26:56 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:26:56 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:26:56 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:26:56 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:26:56 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:26:56 - info: config - log_level = info 2009-11-12 06:26:56 - info: config - BACKUP_LOG_OUTPUT = / tmp / ghettoVCB.log 2009-11-12 06:26:56 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:26:56 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:26:56 - info: config - VMDK_FILES_TO_BACKUP = VCAP.vmdk, VCAP_2.vmdk 2009-11-12 06:26:58 - info: Iniciar la copia de seguridad para VCAP Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. 2009-11-12 06:26:59 - Información: Duración de copia de seguridad: 1 segundos 2009-11-12 06:26:59 - info: copia de seguridad con éxito para VCAP! 2009-11-12 06:26:59 - info: config - mediante una configuración FILE = backup_config / VIMA 2009-11-12 06:26:59 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:26:59 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:26:59 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:26:59 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:26:59 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:26:59 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:26:59 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:26:59 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:26:59 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:26:59 - info: config - log_level = info 2009-11-12 06:26:59 - info: config - BACKUP_LOG_OUTPUT = / tmp / ghettoVCB.log 2009-11-12 06:26:59 - info: config - VM_SNAPSHOT_MEMORY = 1 2009-11-12 06:26:59 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:26:59 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:27:02 - info: Iniciar la copia de seguridad para VIMA 2009-11-12 06:27:02 - info: Creación de instantáneas "ghettoVCB instantánea-2009-11-12" para VIMA Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. 2009-11-12 06:29:28 - info: instantánea Eliminación de VIMA ... 2009-11-12 06:29:31 - Información: Duración de copia de seguridad: 2,48 minutos 2009-11-12 06:29:31 - info: copia de seguridad con éxito para VIMA! 2009-11-12 06:29:31 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:29:31 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:29:31 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:29:31 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:29:31 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:29:31 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:29:31 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-12 06:29:31 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:29:31 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:29:31 - info: config - log_level = info 2009-11-12 06:29:31 - info: config - BACKUP_LOG_OUTPUT = / tmp / ghettoVCB.log 2009-11-12 06:29:31 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:29:31 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:29:31 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:29:35 - info: Iniciar la copia de seguridad para VMA-2 Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho. 2009-11-12 06:31:05 - Información: Duración de copia de seguridad: 1,50 minutos 2009-11-12 06:31:05 - info: copia de seguridad con éxito para VMA-2! 2009-11-12 06:31:05 - info: ============================== ghettoVCB LOG FIN === =============================

El modo de depuración de copia de seguridad

• Verbosidad Log: depuración
• Salida de registro: stdout

[root @ Himalaya ~] #. / ghettoVCB.sh vms_to_backup-f-c-d backup_config depuración 2009-11-13 19:51:47 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-13 19:51:47 - debug: Build Host: VMware ESX 4.0.0 construir-164009 2009-11-13 19:51:47 - debug: HOSTNAME: himalaya.primp-industries.com 2009-11-13 19:51:51 - info: config - mediante una configuración FILE = backup_config / VCAP 2009-11-13 19:51:51 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-13 19:51:51 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-13 19:51:51 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-13 19:51:51 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-13 19:51:51 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-13 19:51:51 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-13 19:51:51 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-13 19:51:51 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-13 19:51:51 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-13 19:51:51 - info: config - log_level = debug 2009-11-13 19:51:51 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-13 19:51:51 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-13 19:51:51 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-13 19:51:51 - info: config - VMDK_FILES_TO_BACKUP = VCAP.vmdk, VCAP_2.vmdk 2009-11-13 19:51:52 - info: Iniciar la copia de seguridad para VCAP 2009-11-13 19:51:52 - debug: findVMDK () - En busca de VMDK: "VCAP_2.vmdk" para copia de seguridad 2009-11-13 19:51:52 - debug: findVMDK () - Encontrado VMDK! - "VCAP_2.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Storage/VCAP/VCAP_2.vmdk' ... Clon: 100% hecho. 2009-11-13 19:51:53 - debug: findVMDK () - En busca de VMDK: "VCAP_1.vmdk" para copia de seguridad 2009-11-13 19:51:53 - debug: findVMDK () - En busca de VMDK: "VCAP.vmdk" para copia de seguridad 2009-11-13 19:51:53 - debug: findVMDK () - Encontrado VMDK! - "VCAP.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmdk' ... Clon: 100% hecho. 2009-11-13 19:51:53 - debug: findVMDK () - En busca de VMDK: "VCAP-0.vmdk" para copia de seguridad 2009-11-13 19:51:54 - Información: Duración de copia de seguridad: 2 segundos 2009-11-13 19:51:54 - info: copia de seguridad con éxito para VCAP! 2009-11-13 19:51:54 - info: config - mediante una configuración FILE = backup_config / VIMA 2009-11-13 19:51:54 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-13 19:51:54 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-13 19:51:54 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-13 19:51:54 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-13 19:51:54 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-13 19:51:54 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-13 19:51:54 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-13 19:51:54 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-13 19:51:54 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-13 19:51:54 - info: config - log_level = debug 2009-11-13 19:51:54 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-13 19:51:54 - info: config - VM_SNAPSHOT_MEMORY = 1 2009-11-13 19:51:54 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-13 19:51:54 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-13 19:51:56 - info: Iniciar la copia de seguridad para VIMA 2009-11-13 19:51:56 - info: Creación de instantáneas "ghettoVCB instantánea-2009-11-13" para VIMA 2009-11-13 19:51:58 - debug: Lugar para ghettoVCB instantánea "instantánea-2009-11-13" que se cree 2009-11-13 19:51:58 - debug: tiempo de espera de instantáneas establece en: 900 segundos 2009-11-13 19:52:01 - debug: Lugar para la creación de instantáneas para ser completada - Iteración: 0 - dormir para 60secs (Duración: 0 segundos) 2009-11-13 19:53:03 - debug: findVMDK () - En busca de VMDK: "VIMA.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmdk' ... Clon: 100% hecho. 2009-11-13 19:54:27 - info: instantánea Eliminación de VIMA ... 2009-11-13 19:54:32 - Información: Duración de copia de seguridad: 2,60 minutos 2009-11-13 19:54:32 - info: copia de seguridad con éxito para VIMA! 2009-11-13 19:54:32 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-13 19:54:32 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-13 19:54:32 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-13 19:54:32 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-13 19:54:32 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-13 19:54:32 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-13 19:54:32 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-13 19:54:32 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-13 19:54:32 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-13 19:54:32 - info: config - log_level = debug 2009-11-13 19:54:32 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-13 19:54:32 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-13 19:54:32 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-13 19:54:32 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-13 19:54:35 - info: Iniciar la copia de seguridad para VMA-2 2009-11-13 19:54:35 - debug: findVMDK () - En busca de VMDK: "VMA-2.vmdk" para copia de seguridad Formato de disco de destino: VMFS delgada provisionados La reproducción del disco '/ vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmdk' ... Clon: 100% hecho. 2009-11-13 19:56:10 - Información: Duración de copia de seguridad: 1,58 minutos 2009-11-13 19:56:10 - info: copia de seguridad con éxito para VMA-2! 2009-11-13 19:56:10 - info: ============================== ghettoVCB LOG FIN === =============================

Dry Run Mode (no copia de seguridad se llevará a cabo)

• Verbosidad Log: drymode
• Salida de registro: stdout

[root @ Himalaya ~] #. / ghettoVCB.sh vms_to_backup-f-c-d backup_config dryrun 2009-11-12 06:32:57 - info: ============================== ghettoVCB Iniciar registro === =========================== 2009-11-12 06:33:01 - info: config - mediante una configuración FILE = backup_config / VCAP 2009-11-12 06:33:01 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:33:01 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:33:01 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:33:01 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:33:01 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:33:01 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:33:01 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:33:01 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:33:01 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:33:01 - info: config - log_level = dryrun 2009-11-12 06:33:01 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:33:01 - info: config - VMDK_FILES_TO_BACKUP = VCAP.vmdk, VCAP_2.vmdk 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - dryrun: Virtual Machine: VCAP 2009-11-12 06:33:01 - dryrun: VM_ID: 2784 2009-11-12 06:33:01 - dryrun: VMX_PATH: / vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP / VCAP.vmx 2009-11-12 06:33:01 - dryrun: VMX_DIR: / vmfs/volumes/himalaya-local-SATA.RE4-GP: Almacenamiento / VCAP 2009-11-12 06:33:01 - dryrun: VMX_CONF: VCAP / VCAP.vmx 2009-11-12 06:33:01 - dryrun: VMFS_VOLUME: Himalaya-local-SATA.RE4 GP: Almacenamiento 2009-11-12 06:33:01 - dryrun: VMDK (s): 2009-11-12 06:33:01 - dryrun: VCAP_2.vmdk 2009-11-12 06:33:01 - dryrun: VCAP_1.vmdk 2009-11-12 06:33:01 - dryrun: VCAP.vmdk 2009-11-12 06:33:01 - dryrun: VCAP-0.vmdk 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - info: config - mediante una configuración FILE = backup_config / VIMA 2009-11-12 06:33:01 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:33:01 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:33:01 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:33:01 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:33:01 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:33:01 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:33:01 - info: config - ITER_TO_WAIT_SHUTDOWN = 4 2009-11-12 06:33:01 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:33:01 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:33:01 - info: config - log_level = dryrun 2009-11-12 06:33:01 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_MEMORY = 1 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:33:01 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - dryrun: Virtual Machine: VIMA 2009-11-12 06:33:01 - dryrun: VM_ID: 4064 2009-11-12 06:33:01 - dryrun: VMX_PATH: / vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA / VIMA.vmx 2009-11-12 06:33:01 - dryrun: VMX_DIR: / vmfs / volúmenes / Himalaya-local-SAS.Savvio / VIMA 2009-11-12 06:33:01 - dryrun: VMX_CONF: VIMA / VIMA.vmx 2009-11-12 06:33:01 - dryrun: VMFS_VOLUME: Himalaya-local-SAS.Savvio 2009-11-12 06:33:01 - dryrun: VMDK (s): 2009-11-12 06:33:01 - dryrun: VIMA.vmdk 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - info: config - VM_BACKUP_VOLUME = / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / WILLIAM_BACKUPS 2009-11-12 06:33:01 - info: config - VM_BACKUP_ROTATION_COUNT = 3 2009-11-12 06:33:01 - info: config - DISK_BACKUP_FORMAT = delgada 2009-11-12 06:33:01 - info: config - ADAPTER_FORMAT = BusLogic 2009-11-12 06:33:01 - info: config - POWER_VM_DOWN_BEFORE_BACKUP = 0 2009-11-12 06:33:01 - info: config - ENABLE_HARD_POWER_OFF = 0 2009-11-12 06:33:01 - info: config - ITER_TO_WAIT_SHUTDOWN = 3 2009-11-12 06:33:01 - info: config - POWER_DOWN_TIMEOUT = 5 2009-11-12 06:33:01 - info: config - SNAPSHOT_TIMEOUT = 15 2009-11-12 06:33:01 - info: config - log_level = dryrun 2009-11-12 06:33:01 - info: config - BACKUP_LOG_OUTPUT = stdout 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_MEMORY = 0 2009-11-12 06:33:01 - info: config - VM_SNAPSHOT_QUIESCE = 0 2009-11-12 06:33:01 - info: config - VMDK_FILES_TO_BACKUP = all 2009-11-12 06:33:01 - dryrun: #################################### ########### 2009-11-12 06:33:01 - dryrun: Virtual Machine: VMA-2 2009-11-12 06:33:01 - dryrun: VM_ID: 4960 2009-11-12 06:33:01 - dryrun: VMX_PATH: / vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2/vMA-2.vmx 2009-11-12 06:33:01 - dryrun: VMX_DIR: / vmfs/volumes/himalaya-local-SAS.Constellation/vMA-2 2009-11-12 06:33:01 - dryrun: VMX_CONF: vMA-2/vMA-2.vmx 2009-11-12 06:33:01 - dryrun: VMFS_VOLUME: Himalaya-local-SAS.Constellation 2009-11-12 06:33:01 - dryrun: VMDK (s): 2009-11-12 06:33:02 - dryrun: VMA-2.vmdk 2009-11-12 06:33:02 - dryrun: #################################### ########### 2009-11-12 06:33:02 - info: ============================== ghettoVCB LOG FIN === =============================

Habilitar la compresión para copias de seguridad:

Para hacer uso de esta función, modificar la variable de ENABLE_COMPRESSION 0 a 1. Tenga en cuenta, no se mezclan con las copias de seguridad sin comprimir las copias de seguridad comprimido. Asegúrese de que los directorios seleccionados para copias de seguridad no contienen las copias de seguridad con las versiones anteriores de ghettoVCB antes de habilitar y aplicar la función de copias de seguridad comprimidas.

Restaurar copias de seguridad (ghettoVCB-restore.sh):

Para recuperar una máquina virtual que ha sido procesado por ghettoVCB, por favor, eche un vistazo a este documento: Ghetto Tech Preview – ghettoVCB-restore.sh – Restauración de VM copia de seguridad desde ghettoVCB a ESX (i) 3,5 y 4,0 +

Cronjob Preguntas frecuentes:

Por favor tome un momento para leer sobre lo que es un “cronjob” y cómo crear uno, antes de continuar

La tarea de configurar cronjobs en el clásico servidores ESX (con Service Console) no es diferente de cronjobs tradicionales en los sistemas operativos * nix (este procedimiento se describe en el enlace anterior). Con ESXi Por otra parte, otros factores deben tenerse en cuenta al establecer cronjobs en el depósito limitada de la consola llamada Busybox porque los cambios realizados no pasan a través de un reinicio del sistema. El siguiente documento se resumen las medidas necesarias para garantizar que las configuraciones se guardan cronjob y presentar al momento de reiniciar el sistema.

Tarea: GhettoVCB.sh configurar para ejecutar una copia de seguridad de cinco días a la semana (lunes a viernes) a las 12AM (medianoche) todos los días y enviar el resultado a un archivo de registro único

Configurar en ESX:

1. Como root, usted instalar su cronjob mediante la emisión de:
[root @ Himalaya ~] # crontab-e

2. Añada la siguiente entrada:
0 0 * * 1-5 / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / ghettoVCB.sh / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / backuplist> / vmfs / volúmenes / dlgCore-NFS -bigboi.VM-Backups/ghettoVCB-backup- $ (date + \% s). log

3. Guardar y salir
[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] # crontab-e no crontab de root - usando una vacía crontab: crontab de instalar nuevos

4. Lista y verificar la cronjob que se acaba de crear:
[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] # crontab-l 0 0 * * 1-5 / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / ghettoVCB.sh / vmfs / volúmenes / dlgCore-NFS-bigboi.VM-copias de seguridad / backuplist> / vmfs / volúmenes / dlgCore-NFS -bigboi.VM-Backups/ghettoVCB-backup- $ (date + \% s). log

Estás listo!

Configurar en ESXi:

1. Configuración de la cronjob añadiendo la siguiente línea a / var / spool / cron / crontab / root:

0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs/volumes/simplejack-local-storage/ghettoVCB-backup- $ (date + \% s). log

2. Matar a los crond actual (cron daemon) y luego reiniciar el crond para que los cambios surtan efecto:

El ESXi <3.5u3
kill $ (ps | grep crond | cut-f 1-d '')

El ESXi 3.5u3 +
~ # Kill $ (pidof crond) ~ # Crond

El ESXi 4.0
~ # Kill $ (/ cat var / run / crond.pid) ~ # Crond busybox

3. Ahora que el cronjob está listo para ir, usted necesita asegurarse de que este cronjob persistirá a través de un reinicio. Usted tendrá que añadir las dos líneas siguientes a la / etc / rc.local (asegurarse de que la entrada de cron coincide con lo que se ha definido anteriormente)

El ESXi 3.5
/ bin / kill $ (pidof crond) / bin / echo "0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB-backup-\ $ (date + \ \% s). log ">> / var / spool / cron / crontab / root crond

El ESXi 4.0
/ bin / kill $ (/ cat var / run / crond.pid) / bin / echo "0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB-backup-\ $ (date + \ \% s). log ">> / var / spool / cron / crontab / root / bin / busybox crond

Después, el archivo debe tener el siguiente aspecto:

~ # Cat / etc / rc.local #! / bin / ash export PATH = / sbin: / bin log () (    echo "$ 1"    init logger "$ 1" ) # ejecutar todos los servicios retgistered en / etc / rc.local.d si [http://-d / etc / rc.local.d | http://-d / etc / rc.local.d], y luego    el nombre de archivo para encontrar en `/ etc / rc.local.d / | ordenar`       hacer          if [-f $ fichero] & & [-x $ fichero]; a continuación,             registro "ejecutando $ fichero"             $ nombre_archivo          fi       hecho fi / bin / kill $ (/ cat var / run / crond.pid) / bin / echo "0 0 * * 1-5 / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB.sh / vmfs / volúmenes / simplejack-local-de almacenamiento / backuplist> / vmfs / volúmenes / simplejack-local-de almacenamiento / ghettoVCB-backup-\ $ (date + \ \% s). log ">> / var / spool / cron / crontab / root / bin / busybox crond

Esto asegurará que el cronjob se vuelve a crear a un reinicio del sistema a través de un script de inicio

2. Para garantizar que esta se guarda en la configuración de ESXi, tenemos que iniciar manualmente una copia de seguridad ESXi ejecutando:
~ # / Sbin / auto-backup.sh configuración de carga implícitamente local.tgz / vmware etc / vmkiscsid / vmkiscsid.db etc / dropbear / dropbear_dss_host_key etc / dropbear / dropbear_rsa_host_key etc / opt / vmware / vpxa / vpxa.cfg etc / opt / vmware / vpxa / dasConfig.xml etc / sysconfig / network / vmware etc / hostD / authorization.xml / vmware etc / hostD / hostsvc.xml / vmware etc / hostD / pools.xml / vmware etc / hostD / vmAutoStart.xml / vmware etc / hostD / vmInventory.xml / vmware etc / hostD / proxy.xml / vmware etc / ssl / rui.crt / vmware etc / ssl / rui.key / vmware etc / vmkiscsid / initiatorname.iscsi / vmware etc / vmkiscsid / iscsid.conf etc / vmware / vmware.lic etc / vmware / config etc / vmware / dvsdata.db etc / vmware / esx.conf etc / vmware / license.cfg etc / vmware / locker.conf etc / vmware / snmp.xml etc / group etc / hosts etc / inetd.conf etc / rc.local etc / chkconfig.db etc / ntp.conf etc / passwd etc / random-seed etc / resolv.conf / etc / shadow etc / sfcb repositorio / root / interoperabilidad / cim_indicationfilter.idx etc / sfcb repositorio / root / interoperabilidad / cim_indicationhandlercimxml.idx etc / sfcb repositorio / root / interoperabilidad / cim_listenerdestinationcimxml.idx etc / sfcb repositorio / root / interoperabilidad / cim_indicationsubscription.idx Los archivos binarios / etc / vmware dvsdata.db y / tmp/auto-backup.31345.dir/etc/vmware/dvsdata.db difieren configuración de carga implícitamente La economía del estado actual en / bootbank Reloj actualizada. Hora: 20:40:36 Fecha: 08/14/2009 UTC

Ahora usted está realmente listo!

Si sigues teniendo problemas para que el cronjob al trabajo, asegúrese de que haya especificado los parámetros correctos y no hay errores en el texto en cualquier parte de la sintaxis.

Asegúrese crond (demonio cron) se está ejecutando:

ESX:

[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] # ps-ef | grep crond | grep-v grep 2625 1 0 raíz Ago13? 00:00:00 crond

ESXi:
~ # Ps | grep crond | grep-v grep 5196 5196 busybox crond

Asegúrese de que la fecha y hora de alojar su ESX (i) está configurado correctamente:

ESX (I):
[root @ Himalaya dlgCore-NFS-bigboi.VM-copias de seguridad] Fecha # Vie Ago 14 23:44:47 PDT 2009

Nota: La atención cuidadosa debe tenerse en cuenta si más de una copia de seguridad se realiza por día. Ventanas de copia de seguridad debe ser escalonada para evitar la afirmación o la saturación de los recursos durante estos períodos.

Preguntas frecuentes:

1T: Soy X error al obtener al utilizar la secuencia de comandos o no estoy recibiendo ningún error, la copia de seguridad ni siquiera tienen lugar. ¡Oh, qué podría estar mal?
1A: Sírvase proporcionar toda la producción de una ejecución manual (modo de depuración y dryrun) o si está iniciando sesión en la salida \ (código \) etiquetas, una breve descripción de su entorno y el tipo de máquina virtual (s) que está tratando de copia de seguridad voy a tratar de brindar alguna ayuda.

2Q: Te he enviado mensajes privados o correo electrónico, pero no he recibido una respuesta? ¿Qué pasa?
2A: No acepto temas / bugs reportados a través de AM o por correo electrónico, voy a responder de nuevo, te permite acceder a publicar en el foro VMTN adecuada (que es lo que es para). Si los datos y resultados que usted está proporcionando es verdaderamente Senstive a su entorno de yo te escucharé, pero el 99,99% no lo está, así que por favor no messsage / correo electrónico directamente. Puedo hacer un seguimiento todos los foros que contienen mi script incluidos los foros VMTN normal y tratar de recuperar a su pregunta tan pronto como me sea posible y el tiempo lo permite. Por favor, sea paciente, no eres la única persona que utiliza el script (100.000 visitas), gracias.

3Q: ¿Puedo programar copias de seguridad que tendrá lugar cada hora, diario, mensual, anual?
3A: Sí, hacer una búsqueda en línea para crontab.

4T: Me gustaría cronjob de instalación de ESX (i) 3,5 o 4,0?
4A: Echa un vistazo a la sección de Preguntas Cronjob en este documento.

5Q: Quiero programar mi copia de seguridad en Windows, ¿cómo puedo hacer esto?
5A: Haga una búsqueda para plink. Asegúrese de que ha vinculado el programa de instalación de ssh entre su sistema Windows y ESX / ESXi de acogida.

6Q: Sólo tengo una gran ESXi único. Quiero realizar copias de seguridad y guardarlas en otro lugar. El problema es: no tengo NFS, iSCSI, ni FC SAN. ¿Qué puedo hacer?
6A: Usted puede utilizar el almacenamiento local para almacenar las copias de seguridad suponiendo que haya suficiente espacio en el almacén de datos de destino. Después, puede utilizar el programa scp (WinSCP / FastSCP) para transferir las copias de seguridad del host ESXi en el escritorio local.

7Q: Estoy furioso, la copia de seguridad está tomando demasiado tiempo. Mi almacén de datos es de tipo X?
7A: YMMV, eche un vistazo a la configuración de almacenamiento y asegurar que se ha optimizado.

8Q: Me di cuenta de que la rotación de copia de seguridad se produce después de una copia de seguridad. Yo no tengo suficiente espacio de almacenamiento local, se puede cambiar el proceso?
8A: Esto se hace para asegurar que usted tiene al menos una buena copia de seguridad en caso de que la nueva copia de seguridad falla. Si desea modificar la secuencia de comandos, es más que bienvenido a hacerlo.

9Q: ¿Cuál es la mejor configuración de almacenamiento de tipo X de almacén de datos?
9A: Los foros VMTN búsqueda, hay varias configuraciones para los diferentes tipos de almacenamiento, etc.

10Q: Quiero configurar un servidor NFS para ejecutar mis copias de seguridad. ¿Cuál es la mejor y debe ser virtual o físico?
10A: Por favor remitirse a la respuesta 7A. Por experiencia, hemos visto casos física de los servidores NFS para ser más rápido que sus contrapartes virtuales. Como siempre, tu caso es distinto.

11Q: He máquinas virtuales que se han instantáneas. Quiero de nuevo estas cosas, pero el guión no me deja hacerlo. ¿Cómo puedo solucionarlo?
11a: Instantáneas VM no están destinados a mantenerse por períodos largos. Cuando la copia de seguridad de una máquina virtual que contiene una instantánea, debe asegurarse de todas las instantáneas han sido cometidos antes de ejecutar una copia de seguridad. No se harán excepciones … nunca.

12Q: Me gustaría restaurar la copia de seguridad, ¿cuál es el mejor método?
12A: El proceso de restauración será único para cada entorno y debe ser determinado por la copia de seguridad o planes de recuperación. En un nivel superior tiene la opción de montar el almacén de datos de copia de seguridad y el registro de la máquina virtual en cuestión o una copia de la máquina virtual desde el almacén de datos de copia de seguridad a la ESX / ESXi de acogida. Este último se recomienda para que no se está ejecutando la vida VM en el almacén de datos de copia de seguridad o sin querer modificar su máquina virtual de copia de seguridad (s).

13Q: Cuando trato de ejecutar el script que recibe: “-bash:. / ghettoVCB.sh: Permission denied”, ¿Qué pasa?
13A: Es necesario cambiar el permiso en el guión sea ejecutable, chmod + x ghettoVCB.sh

14Q: ¿Dónde puedo descargar la última versión del guión?
14A: La última versión está disponible en esta página en la parte inferior.

15Q: Me gustaría sugerir / recomendar la característica X, ¿puedo conseguirlo? ¿Cuándo puedo conseguirlo? ¿Por qué no está aquí, ¿qué pasa?
15A: El objetivo general de este script es para proporcionar una solución de copia de seguridad en torno a máquinas virtuales VMware. Cualquier función adicional fuera de ese proceso se tendrán en cuenta en función de la cantidad de tiempo, el número de peticiones y la utilidad real en su conjunto a la comunidad más que a una persona.

16Q: ¿Cuáles son los diferentes tipos de copia de seguridad de los casos los usos que son compatibles con ghettoVCB?
16A: Live copia de seguridad 1) de la máquina virtual con el uso de una instantánea, y 2) de copias de seguridad de una máquina virtual sin una instantánea. Estos son los únicos dos casos de uso con el apoyo de la secuencia de comandos.

Enlaces de interés:

Detalle las instrucciones sobre cómo configurar / ghettoVCB programación en Windows (The Raj Perumal de Carreras Mundial sobre la Tecnología de blog):

Parte 1
Parte 2
Parte 3

Cambio de registro:

11/17/09 – Los siguientes mejoras y correcciones se han implementado en esta versión de ghettoVCB. Un especial agradecimiento a todos los probadores ghettoVCB BETA para proporcionar el tiempo y sus entornos para poner a prueba características y correcciones de la nueva secuencia de comandos!

Mejoras:

• Política de copia de seguridad individual VM
• Incluir / excluir VMDK específico (s)
• Registrar en archivo
• Las variables de tiempo de espera
• Memoria instantánea Configur / inactividad
• Adaptador de formato de
• Modo adicional de registro + dryrun
• Apoyo a la física / RDMS virtual

Correcciones:

• Disco independiente consciente

Adjuntos:

• ghettoVCB-vm_backup_configuration_template (380 bytes)
• ghettoVCB.sh (28,8 K)

 ghettoVCB.sh ESX(i) 3.5 y 4.0

Información proporcionada por lu1f3r y extraída de http://lu1f3r.loxi.ca/?q=es/node/24 . Gracias por estas aportaciones a la red

VMWare ESXi incluye una funcionalidad muy interesante y poco documentada: La posibilidad de tener acceso a una consola remota usando VNC. Para poder habilitar esta funcionalidad se deben seguir los siguientes pasos:

1. Detener la maquina virtual para la cual se desea habilitar la consola remota.

2. Habilitar el modo vnc para la consola en la maquina virtual. Para hacer esto se necesita modificar el archivo .vmx que define la maquina virtual y agregar:

RemoteDisplay.vnc.enabled = "true"
RemoteDisplay.vnc.port = "5901"

El puerto esta identificado por la linea RemoteDisplay.vnc.port. Se pueden usar multiples puertos segun el numero de maquinas virtuales a las que se les desee habilitar la consola remota.

3. Habilitar el servicio de Servidor VNC en el firewall del servidor ESXi. Para hace esto se debe acceder con el usuario root al servidor ESXi y ejecutar:

esxcfg-firewall --enableService vncServer


Este comando crea una regla en IPTABLES para permitir conexiones al servidor:

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpts:5900:5964


Como se puede apreciar, el maximo numero de consolas remotas es 64.

4. Se debe iniciar la maquina virtual modificada.

Despues de esto se puede usar cualquier cliente VNC para acceder a la consola de la maquina virtual. Los parametros necesarios son: la direccion IP del SERVIDOR ESXi y el puerto en el cual se habilito la consola remota

La funcionalidad de consola remota es muy util cuando se estan haciendo pruebas para ambientes que requieren una red privada compartida por varias maquinas virtuales. Bueno, es hora de jugar con las consolas remotas en VMWare ESXi!

Habilitar consolas remotas en VMWare ESXi con VNC

Información extraída de la web de VMware. La información es una traducción automática. La siguiente tabla compara VMware ESX / ESXi 3.5 con el recientemente lanzado Microsoft Hyper-V y el hipervisor muestra cómo la tecnología Hyper-V se presentan importantes limitaciones en todos los aspectos críticos de un hipervisor:

Características	VMware ESX / ESXi 3.5	Microsoft Hyper-V RTM	Comparación hipervisores
Thin expresamente construida Arquitectura
Huella en el disco Pequeños			Hyper-V es totalmente dependiente de un SO de propósito general (Windows 2008). Mejor de Microsoft huella en el disco caso es 2.6GB (Hyper-V + Server Core), que es más de 80x veces más grande que ESXi’s (32MB). Hyper-V + Windows Server 2008 es aún mayor con una huella de aproximadamente 10 GB. El gran tamaño de ambas opciones se crea un blanco más fácil para los ataques a la seguridad y la sobrecarga de rendimiento cada vez mayor. Además, los parches para Windows Server 2008 / Server Core afectará a los clientes la tecnología Hyper-V.VMware ESXi en cambio es un hipervisor en pleno funcionamiento en la huella de un 32 MB de disco, lo que reduce el riesgo de tiempo de inactividad y aumenta la fiabilidad.
Independencia del sistema operativo			Hyper-V depende de Windows 2008 y, en consecuencia, favorecer a los clientes de Windows cuando se trata de hacer pleno uso de los recursos de hardware disponibles: Hyper-V apoyo a las operativos invitados de Windows se limita sólo a Novell SUSE Hyper-V apoyo a la 4-VSMP formas está limitada a Windows Server 2008. Para Windows 2003, Hyper-V sólo admite un máximo de 2-vías VSMP VMware ESX / ESXi está optimizado para la virtualización, ofrece la apoyo más amplio OS (5 versiones de Windows, 9 versiones de Linux, NetWare y Solaris) y permite que todos los sistemas operativos de apoyo a los resultados de manera óptima utilización de los recursos disponibles (4-VSMP forma está disponible en todos los sistemas operativos de servidor compatible)
Conductores endurecido			Windows 2008 es un sistema operativo de propósito general que se basa en los controladores de dispositivos genéricos construidas por terceros que no están diseñados para la virtualización. Este hecho aumenta drásticamente la probabilidad de problemas de rendimiento, el tiempo de inactividad relacionados con parches de conductor, y los fallos del sistema, a pesar de que los conductores pasar por el proceso de certificación de Microsoft. Los controladores de Windows ya pasar por la certificación de Microsoft hoy en día y todavía existen problemas de controladores.Por otra parte, VMware colabora estrechamente con IHV para probar y optimizar sus drivers para su uso con ESX / ESXi para garantizar, la fiabilidad y el rendimiento general cuando se ejecuta simultáneamente las cargas de trabajo virtualizadas.
Eficiencia de recursos
La gestión de memoria avanzada			La gestión de memoria del sistema es en la mayoría de los casos el factor dominante que determina el número de máquinas virtuales simultáneas que se pueden ejecutar en una máquina física. Hyper-V no puede cometer más de la memoria de acogida porque no es no es compatible con las características tales como la transparencia que comparten la memoria de página y globos de memoria para recuperar la memoria física de inactividad. En consecuencia Hyper-V ofrece una menor densidad de la máquina virtual, y la proporción de bajas en comparación con la consolidación de servidores VMware ESX / ESXi.VMware ESX / ESXi apoya plenamente overcommit de memoria, lo que permite altas tasas de densidad de VM al tiempo que ofrece un rendimiento consistente. Los clientes de VMware utiliza regularmente overcommit de memoria en sus centros de datos de producción a un ritmo de 1,5 X a 2,5 veces sin ningún tipo de impacto notable a los usuarios finales.
Gestión avanzada de almacenamiento			Hyper-V utiliza el sistema de archivos NTFS para el almacenamiento. NTFS no es un sistema de archivos en clúster. Por lo tanto, Hyper-V no ofrece soporte nativo para discos virtuales compartidos y la migración en vivo. Hyper-V de la falta de un sistema de archivos en clúster significa que con la migración rápida de Microsoft (basados en la agrupación de acogida) todas las máquinas virtuales en un LUN se migrará al mismo tiempo. Para evitar este resultado no deseado, el usuario debe asignar una VM por LUN, que crea una pesadilla de almacenamiento. La única otra opción es la compra de un tercero en el sistema de archivos en cluster de concesión de licencias adicionales y gastos de apoyo.VMware ESX / ESXi viene con VMFS, un sistema de archivos en clúster diseñado específicamente para la virtualización. VMFS apoya plenamente la migración en vivo, y permite a varias máquinas virtuales para compartir un único LUN y todavía emigran / conmutación por error de máquinas virtuales individuales.
Gestión avanzada de redes			Hyper-V no es compatible con NIC física nativo trabajo en equipo, en lugar que requiere de 3 controladores de hardware independientes (Intel, Broadcom). Esta limitación impide que Hyper-V de proporcionar fuera de la protección de la caja, independiente del hardware de un fallo de la NIC. Además, la tecnología Hyper-V para los conductores NIC apoyo no se virtualización consciente, no pueden ser controlados desde el hipervisor, y se deben cargar en la partición de los padres.VMware ESX / ESXi apoya plenamente NIC trabajo en equipo, resultando en una sencilla, completa de la solución de cuadro de conmutación por error de la NIC.
Performance Acceleration
Escalabilidad I / O			Hyper-V utiliza un “controlador indirecto” modelo que mantiene todos los controladores de dispositivo en una instancia de Windows 2008 almacena en la partición de los padres de Hyper-V y se basa en el sistema operativo de propósito general para manejar la E / S de tráfico. Este diseño de los cuellos de botella de E / S, como todo lo que resultados peticiones E / S debe viajar a través de Windows Server 2008 (o Server Core), que no está optimizado para la virtualización. El resultado es problemas de escalabilidad cuando se ejecuta muchas máquinas virtuales bajo carga. Este problema se limita la escalabilidad ratios de consolidación.VMware ESX / ESXi emplea un modelo de controlador directo con un planificador construyó específicamente para manejar las demandas de múltiples cargas de trabajo de alto. Esto da lugar a la escalabilidad de las relaciones más altas, mientras que la densidad de VM con la entrega consistente y de alto rendimiento.
Distributed Resource Allocation			Hyper-V carece de muchas capacidades para distribuir de manera óptima los recursos de hardware., Con base en tiempo real las condiciones de carga de trabajo. A diferencia de ESX / ESXi, Hyper-V no es compatible con: El tráfico de red para la configuración de equilibrio de carga Storage I / O se asegura de que el establecimiento de prioridades para máquinas virtuales crítica prioridad de acceso a dispositivos de almacenamiento La priorización de intercambio de memoria (inflamación de la memoria) VMware ESX / ESXi tiene una solución probada para la distribución de los recursos de hardware, que incluye soporte completo para el tráfico de la configuración de la red, I / O el establecimiento de prioridades, y globos de memoria para la gestión de memoria y el establecimiento de prioridades.
Apoyo para las Tecnologías de Mejora del Rendimiento			Hyper-V carece de apoyo de varias tecnologías que mejoran el rendimiento, tales como: AMD RVI (tablas anidadas página), incluido en la última versión de la CPU AMD Barcelona Páginas de memoria grande, que permite mejorar el rendimiento cuando la virtualización de bases de datos VMware ESX / ESXi es compatible con las tablas de páginas y páginas anidadas grandes cantidades de memoria y por lo tanto capaz de un rendimiento superior, incluso en los entornos más exigentes. Aplicaciones de misión crítica e intensivos, como una base de datos de Oracle se desempeñan mejor en un entorno virtual de VMware.
Soporte Linux virtualizado			Hyper-V es compatible con la “vieja manera” de hacer Linux para la virtualización, donde los administradores mantienen dos núcleos, uno para la física y otro para las máquinas virtuales. Este adicionales de mantenimiento mayor complejidad y los costes de gestión.Por otra parte, VMware ESX / ESXi apoya para Linux-a través de la virtualización paravirt_ops / VMI (Virtual Machine Interface) – la nueva industria aceptado forma de para-virtualizar Linux. Esta nueva forma no requiere de los administradores de TI para mantener y apoyar los núcleos separados para máquinas físicas y virtuales – es todo en un solo núcleo. En la actualidad, SLES 10, y Ubuntu 7 todo paravirt-ops/VMI apoyo.
Avanzadas características de virtualización
La tecnología de seguridad virtual de			Hyper-V no ofrece dedicada capacidades de los proveedores de seguridad para ampliar sus capacidades de seguridad para entornos virtualizados.VMsafe, Una característica de las próximas VMware ESX / ESXi, permitirá un rico ecosistema de soluciones de seguridad de terceras partes para los entornos virtualizados. VMsafe es una tecnología de seguridad virtual que proporciona una visibilidad de grano fino de los recursos de máquina virtual, que permite supervisar todos los aspectos de la ejecución del sistema y detener los virus antes indetectable, rootkits y malware antes de que se puede infectar un sistema.

VMware ESX – ESXi 3.5 vs. Microsoft Hyper-V

Abrir puerto SSH en ESXi

Pues muy sencillo.

Pinchamos ALT + F1 y nos saldrá una pantalla donde escribiremos a ciegas UNSUPPORTED

Nos pedirá usuario y password de nuestra consola de ESXi

Ejecutaremos:

vi /etc/inetd.conf

Nos abrirá el fichero de configuración y buscaremos una linea en la que hay #ssh y le quitaremos la almohadilla

Guardaremos presionando :wq!

Y reiniciamos nuestro ESXi

Ya podemos acceder por SSH a nuestro ESXi

Abrir puerto SSH en ESXi