Siguiendo con los comandos de la herramienta que nos ocupa, vim-cmd, esta semana me gustaría centrarme en aquellos comandos que nos permiten gestionar aquellos aspectos más relacionados directamente con el host ESX(i) al que estamos conectados.

Por hacer un poco de memoria, la semana pasada os animaba a ejecutar el comando vim-cmd vimsvc/license –show. Como podréis suponer, este comando muestra información acerca de la licencia que está asignada a nuestro ESX(i):

~ # vim-cmd vimsvc/license –show
[200] Sending request for installed licenses…[200] Complete, result is:
serial: H468P-0E050-58E39-018H0-1RQ05
vmodl key: esxBasic
name: vSphere 4 Hypervisor
total: 0
used: 1
unit: cpuPackage:6core
Properties:
[ProductName] = VMware ESX Server
[ProductVersion] = 4.0
[count_disabled] = This license is unlimited
[feature] = maxRAM:256g (“Up to 256 GB of memory”)
[feature] = vsmp:4 (“Up to 4-way virtual SMP”)
[FileVersion] = 4.1.0.8
[LicenseFilePath] = /usr/lib/vmware/licenses/site/license-esx-40-e1-4core-200803
…
[200] End of report.

Este comando en particular no presenta opciones mucho más espectaculares que esta, salvo la gestión de tareas mediante los subcomandos tasks_list, tasks_info, tasks_description y tasks_cancel y la gestión de roles del subcomando auth. Al igual que ocurría con las máquinas virtuales, para poder hacer cualquier operación con las tareas tendremos que localizar el identificador de tarea mediante el comando tasks_list.

Permitidme que no me pare mucho en el comando vimsvc, ya que el comando del que os quiero hablar a continuación lo encuentro mucho más interesante, hostsvc. Y es que el interés y la importancia de este comando destacan por sí mismas en el momento en el que listamos los subcomandos de los que dispone:

~ # vim-cmd help hostsvc
Commands available under hostsvc/:
advopt/ enable_local_tsm queryconnectioninfo
autostartmanager/ enable_remote_tsm querydisabledmethods
datastore/ firewall_disable_ruleset refresh_firewall
datastorebrowser/ firewall_enable_ruleset refresh_services
firmware/ hostconfig runtimeinfo
net/ hosthardware set_hostid
rsrc/ hostsummary standby_mode_enter
storage/ login standby_mode_exit
summary/ logout start_local_tsm
vmotion/ maintenance_mode_enter start_remote_tsm
connect maintenance_mode_exit stop_local_tsm
cpuinfo memoryinfo stop_remote_tsm
disable_local_tsm pci_add task_list
disable_remote_tsm pci_remove

Debido a motivos de espacio del post, y sobre todo por no aburriros con todos los detalles, no entraré en todas las opciones que presenta este comando, pero al menos sí que me gustaría hacer una descripción somera de las más importantes y, al igual que la semana pasada, repasar un par de ejemplos con vosotros.

• Advopt, nos da acceso a las opciones avanzadas del host. Sería equivalente al menú de “Advanced Settings” que tenemos disponible en el vClient, en la pestaña “Configuration” del host.
• Autostartmanager, se encarga de gestionar las opciones de inicio y parada automáticos de las máquinas virtuales. Equivalente al menú “Virtual Machine Startup/Shutdown”
• Datastore, habla por sí solo. Veremos un ejemplo en detalle.
• Datastorebrowser, en teoría nos debería permitir explorar los datastores configurados en el host, pero en la práctica no está implementado y por lo tanto no es operativo.
• Firmware, es el encargado de gestionar las actualizaciones y el backup de nuestro ESXi
• Net, realmente interesante, ya que nos permite configurar muchos de los aspectos del ESX(i) relacionados con la red. Veremos un ejemplo en detalle.
• Rsrc, está destinado a gestionar los grupos de recursos.
• Storage, también bastante interesante, es el subcomando encargado de gestionar los aspectos relacionados con el almacenamiento desde el punto de vista hardware.
• Summary, nos presenta un resumen de los dispositivos de almacenamiento.
• Vmotion, encargado de gestionar los aspectos de configuración relacionados con vmotion.

A continuación me gustaría profundizar un poco más alguno de los puntos que comentaba anteriormente con un par de ejemplos.
En el primer ejemplo veremos como añadir un datastore de tipo NFS a nuestro ESXi. Si revisamos la ayuda del comando vemos:

~ # vim-cmd help hostsvc/datastore/nas_create
Usage: nas_create name remoteHost remotePath readonly

Add a NAS datastore.
readonly is a boolean value, 1 for readonly and 0 for rw access.

Con lo que nuestro comando quedaría de la siguiente forma:

~ # vim-cmd hostsvc/datastore/nas_create NFS_Datastore NFS_Host /backups 0
~ #

Al igual que ocurre con los datastores de tipo NAS, podremos crear datastores locales mediante el comando localds_create o datastores “compartidos” mediante el comando vmfs_create. Particularmente importante e interesante es el hecho de que debemos consultar las opciones hardware disponibles a la hora de crear un datastore “compartido” mediante el comando vmfs_query_create_options.

Otras opciones relacionadas con el almacenamiento que no quería dejar escapar son las que se encuentran bajo el comando storage. Si bien, de nuevo, por no hacer muy extenso el post no vamos a entrar en detalle en ellas, creo que es importante mencionar al menos algunas de las más útiles e importantes:

• storage/multipath_info, muestra información acerca de la política de multipath configurada por cada LUN.
• storage/hba_rescan, que permite realizar un re-escaneo de la hba que se le pase como parámetro

Continuando con los ejemplos de algunos de los subcomandos de hostsvc, veremos ahora como crear un nuevo virtual switch y asignarle su correspondiente NIC física y portgroups.

En primer lugar crearemos un virtual switch sin asociaciones ninguna, es decir el “esqueleto” de lo que será un vSwitch completamente funcional:

~ # vim-cmd hostsvc/net/vswitch_add vSwitch_TEST
~ #

A continuación crearemos y asociaremos los portgroups que nos interesen. En este caso agregaremos un portgroup de tipo Virtual Machine:

~ # vim-cmd hostsvc/net/portgroup_add vSwitch_TEST VM_PortGroup
~ #

Es importante consultar la ayuda de este comando, ya que en el apartado OPTIONS encontraremos las diferentes variantes y políticas que podremos configurar para el portgroup, bien durante su creación o posteriormente con el comando portgroup_set.

En este punto añadiremos las NIC físicas para dar servicio a nuestro vSwith:

~ # vim-cmd hostsvc/net/vswitch_setbondbridge –vsbridge-bond-pnics=vmnic1 vSwitch_TEST
~ #

Con lo que tendremos nuestro virtual switch configurado y listo para el servicio.

Es importante recordar que muchas de las opciones y políticas que tenemos disponibles en el vClient a través de las propiedades de los port groups o los virtual switches, las tenemos también disponibles en las opciones de los comandos encargados de gestionar estos elementos, por lo que resulta fundamental consultar la ayuda de estos comandos para realizar los ajustes que más nos interesen.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

En el post de la semana pasada os hacía una breve introducción de un comando que personalmente uso cuando me tengo que enfrentar a situaciones un poco delicadas, donde la administración de la plataforma virtual no es posible mediante otros medios.

Esta semana me gustaría profundizar algo más en alguna de las opciones del comando vim-cmd, la gestión de máquinas virtuales mediante el comando vmsvc.

Si hacemos un listado de las opciones o subcomandos que nos presenta este comando podemos ver cosas interesantes:

~ # vim-cmd help vmsvc
Commands available under vmsvc/:
acquiremksticket get.configoption power.on
acquireticket get.datastores power.reboot
connect get.disabledmethods power.reset
convert.toTemplate get.environment power.shutdown
convert.toVm get.filelayout power.suspend
createdummyvm get.guest power.suspendResume
destroy get.guestheartbeatStatus queryftcompat
device.connection get.managedentitystatus reload
device.connusbdev get.networks setscreenres
device.disconnusbdev get.runtime snapshot.create
device.diskadd get.snapshotinfo snapshot.dumpoption
device.diskaddexisting get.summary snapshot.get
device.diskremove get.tasklist snapshot.remove
device.getdevices getallvms snapshot.removeall
device.toolsSyncSet gethostconstraints snapshot.revert
device.vmiadd login snapshot.setoption
device.vmiremove logout tools.cancelinstall
devices.createnic message tools.install
get.capability power.getstate tools.upgrade
get.config power.hibernate unregister
get.config.cpuidmask power.off upgrade
~ #

Antes de poder trabajar con la mayoría de estos comandos es necesario que obtengamos el vmid asociado a la máquina virtual con la que queremos trabajar. Si recordamos último ejemplo del post de la semana anterior podemos ver como localizar fácilmente este vmid:

~ # vim-cmd vmsvc/getallvms
Vmid Name File Guest OS Version Annotation
1024 VM1 [DS001] VM1/VM1.vmx windows7_64Guest vmx-07 PLANTILLA BASE – Windows Server 2008 R2 Standard SELLADO
1072 VM2 [DS001] VM2/VM2 .vmx other26xLinuxGuest vmx-07
1136 VM3 [DS001] VM3/VM3.vmx windows7Server64Guest vmx-07
1184 VM4 [DS001] VM4/VM4.vmx windows7_64Guest vmx-07 PLANTILLA BASE – Windows Server 2008 R2 Standard SELLADO
272 VM5 [DS001] VM5/ VM5.vmx other26xLinuxGuest vmx-07

Donde la primera columna es precisamente el valor que estamos buscando. Una vez que tenemos localizado este identificador, trabajar con la(s) maquina(s) virtual(es) es cuestión de usar el comando correcto.

Por ejemplo, como podréis haber adivinado, los comandos power.* gestionarán el encendido, apagado, hibernación, etc de la máquina virtual que elijamos. Como ejemplo de uso, supongamos que queremos reiniciar la máquina con el ID 1024…
Nos aseguramos que la máquina está iniciada:

~ # vim-cmd vmsvc/power.getstate 1024
Retrieved runtime info
Powered on
~ #

Para a continuación reiniciarla:

~ # vim-cmd vmsvc/power.reboot 1024
~ #

Para estos comandos, ocurre igual que con las acciones que podemos realizar directamente desde el vClient, algunas opciones estarán disponibles si las vmware tools están instaladas, que como podeis ver también podremos instalar usando los comandos tools.install o tools.upgrade, dependiendo del caso.

Sin embargo si hay un grupo de comandos que sean especialmente interesante son aquellos que muestran información sobre la máquina virtual, get.*

Veamos un par de ejemplos. El siguiente comando nos devolverá la configuración específica de una máquina virtual:

~ # vim-cmd vmsvc/get.config 1024 | less

(vim.vm.ConfigInfo) {
dynamicType = ,
changeVersion = “2011-04-08T07:52:44.57038Z”,
modified = “1970-01-01T00:00:00Z”,
name = ” VM1″,
guestFullName = “Microsoft Windows 7 (64-bit)”,
version = “vmx-07″,
uuid = “564d3715-27e9-ffe0-1d09-c769b43733a6″,
instanceUuid = “52c515e0-95e4-db75-99f1-abc05705718b”,
npivWorldWideNameType = “”,
npivDesiredNodeWwns = ,

La salida del comando ha sido reducida en favor del espacio del post. Debido a la cantidad de información que devuelve este comando es más que recomendable pasarlo por un less que nos pagine la salida.

De un modo muy similar podremos consultar la información sobre las interfaces de red virtuales:

~ # vim-cmd vmsvc/get.networks 1024
Networks:

(vim.Network.Summary) {
dynamicType = ,
network = ‘vim.Network:HaNetwork-PGPPRQOS001′,
name = “PGPPRQOS001″,
accessible = true,
ipPoolName = “”,
}
~ #

Desafortunadamente, la documentación existente sobre este interesante comando de mantenimiento resulta un tanto laxa, por lo que en ocasiones puede resultar un poco complejo.

La semana que viene continuaremos con otro grupo de comandos, pero para ir abriendo boca, os invito a que ejecutéis el comando vim-cmd vimsvc/license –show

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

A pesar de lo escandaloso que pueda resultar el título del post de hoy, estoy seguro que la inmensa mayoría de nosotros nos hemos encontrado en al menos una ocasión en la que hemos tenido que lidiar con situaciones como esta.

En esta semana me gustaría hacer un pequeño repaso de una herramienta que nos será de gran utilidad cuando nos las tengamos que ver con situaciones delicadas, vim-cmd. Este comando, disponible desde la línea de comandos de nuestro ESX(i) nos permitirá acceder a multitud de información de nuestro host, así como realizar tareas de administración como crear snapshots, activar/desactivar el modo de mantenimiento del host, y otras diversas funciones que iré comentando en este y futuros posts.

Es importante recordar que alguna de las acciones que realicemos durante nuestra operativa en la consola o Tech Support Mode puedan incurrir en alguna violación del contrato de soporte, por lo que es siempre importante revisar las políticas de soporte de VMware . Sin embargo, esto no debería causaros rechazo en usar el TSM, ya que si se usa adecuadamente es perfectamente seguro, realmente potente y nos puede salvar el cuello en más de una ocasión.

En lo que atañe al comando, contamos con una serie de opciones básicas y típicas para conectarnos con otro host, suministrar credenciales de conexión o modificar el nivel de depuración. A continuación os pongo la salida de la opción de ayuda del comando:

~ # vim-cmd -h
Usage: vim-cmd [options]… command [cmd_arg1] [cmd_arg2] …
Options:
-h Display this help message and exit
-v Display version information and exit
-H Host name to connect
-O Port number to connect
-U User name to use for login
-P Password to use for login
-d Show verbose debug output. (info, verbose, trivia)

Use the help command to get information on the commands available.

~ # vim-cmd help [command]

Hasta aquí nada especialmente espectacular, ya que lo realmente interesante está en la penúltima línea, vim-cmd help [command]

Por explicarlo un poco mejor os diré que vim-cmd es una especie de “shell” que opera directamente con comandos propios. Estos comandos se organizan en una estructura de árbol y se han dividido por ámbito de uso. Cada uno de estos comandos tiene una lista de argumentos diferente, por lo que usaremos con cierta frecuencia el comando help.

A continuación tenemos la salida del comando help, que nos muestra el primer nivel del árbol de comandos de vim-cmd.

~ # vim-cmd help
Commands available under /:
hostsvc/ proxysvc/ supportsvc_cmds/ vmsvc/
internalsvc/ solo/ vimsvc/ help
~ #

Iremos viendo cada uno de estas secciones en sucesivos posts, pero por ir adelantando un poco e ir terminando me gustaría mostraros la salida de un comando que personalmente me ha resultado muy útil en multitud de ocasiones:

~ # vim-cmd vmsvc/getallvms
Vmid Name File Guest OS Version Annotation
1024 VM1 [DS001] VM1/VM1.vmx windows7_64Guest vmx-07 PLANTILLA BASE – Windows Server 2008 R2 Standard SELLADO
1072 VM2 [DS001] VM2/VM2 .vmx other26xLinuxGuest vmx-07
1136 VM3 [DS001] VM3/VM3.vmx windows7Server64Guest vmx-07
1184 VM4 [DS001] VM4/VM4.vmx windows7_64Guest vmx-07 PLANTILLA BASE – Windows Server 2008 R2 Standard SELLADO
272 VM5 [DS001] VM5/ VM5.vmx other26xLinuxGuest vmx-07

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, soy Florián Murillo. Cuando hemos de revisar por primera ver una instalación en producción de vSphere, probablemente la primera tarea a realizar es averiguar la versión instalada, tanto de vSphere como de vCenter Server.

Esta información la leemos desde vCenter Server, pero no nos da visibilidad directa acerca del “update” instalado ¿Que nivel de update tiene la instalación?

vSphere 4.0 tiene 2 updates, por tanto 3 versiones, es decir v.4.0, v.4.0 U1 y v.4.0 U2. vSphere 4.1 tiene un update, por tanto 2 versiones, la v.4.1 y la v.1 U1.

¿Cual de estas 5 versiones tiene el vSphere que tenemos delante? La respuesta está en el “build” ese número de 6 dígitos que acompaña a la versión.

Desde el prompt también tenemos varias formas de conocer el build, os adjunto algunas:

# vmware -v

VMware ESXi 4.1.0 build-348481

# uname -a

VMkernel host01.cc.local 4.1.0 #1 SMP Release build-348481 …

También podemos recurrir a PowerCLI para conocer el build, tras conectarnos al host:

$o_host = Get-VMHost

write-output $o_host.build

Una vez tenemos el build, ya sea desde vCenter Server o desde el prompt, recurrimos a una tabla como la que os adjunto, para conocer la versión exacta:

Espero que os sea útil este post. Hasta la semana próxima.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Hola amigos, soy Florián Murillo y en el post prevacacional de hoy vamos a responder a pequeñas dudas que nos surgen en nuestro día a día con la vMA, en concreto:

¿Que versión de vMA tenemos instalada?

[vi-admin@vma01 ~]$ cat /etc/vima-release | head -1
vMA 4.0.0 BUILD-161992

donde head nos enseña las primeras líneas del archivo (el parámetro es el número de líneas)

¿Como aumento el espacio del disco de la vMA?

Primero verificamos el estado del disco antes de hacer los cambios

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
496M 20M 452M 5% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm

[vi-admin@vma01 ~]$ sudo fdisk -l

Disk /dev/sda: 5368 MB, 5368709120 bytes
255 heads, 63 sectors/track, 652 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
[vi-admin@vma01 ~]$

Recordemos que /dev/sda es el disco duro y el número que le sigue es la partición.

Ahora paramos la vMA para hacer un grow del disco con:

[vi-admin@vma01 ~]$ sudo shutdown -h now

Ampliamos el disco de 5GB a 10GB desde vCenter (recuerda de borrar los snapshots para poder ampliar el disco) y levantamos la vMA

[vi-admin@vma01 ~]$ sudo fdisk -l
Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
[vi-admin@vma01 ~]$

Observa que el tamaño del disco /dev/sda ha cambiado a 10.7GB

Ahora cramos una partición con el nuevo espacio:

[vi-admin@vma01 ~]$ sudo fdisk /dev/sda

The number of cylinders for this disk is set to 1305.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n <--- Nueva partición
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 3 <--- crearemos /dev/sda3
First cylinder (653-1305, default 653):
Using default value 653
Last cylinder or +size or +sizeM or +sizeK (653-1305, default 1305):
Using default value 1305

Command (m for help): t <--- Cambiamos el tipo de partición a 8e para Linux Volume Manager
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)

Command (m for help): w <--- Grabamos los cambios realizados (importante)
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

[vi-admin@vma01 ~]$ sudo fdisk -l

Disk /dev/sda: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 652 5132767+ 8e Linux LVM
/dev/sda3 653 1305 5245222+ 8e Linux LVM
[vi-admin@vma01 ~]$

Ahora reiniciamos:

[vi-admin@vma01 ~]$ sudo reboot

Tras reiniciar, preparamos la nueva partición, para ampliar /var:

Como estamos en un entorno Linux Volume Manager, nos hemos de adaptar a sus reglas:

Primero creamos el Volumen Lógico

[vi-admin@vma01 ~]$ sudo pvcreate /dev/sda3
Physical volume “/dev/sda3″ successfully created

Ahora añadimos extendemos en Volume Group VolGroup00 (que vimos en el df -h) con el Volumen Físico creado

[vi-admin@vma01 ~]$ sudo vgextend VolGroup00 /dev/sda3
/dev/hda: open failed: No medium found
Volume group “VolGroup00″ successfully extended

Verificamos que tenemos espacio libre no asignado, y que coincide, como esperabamos con el Volumen Físico añadido:

[vi-admin@vma01 ~]$ sudo vgdisplay | grep -i free
Free PE / Size 160 / 5.00 GB

Ampliamos Volumen Lógico /var que hay dentro del Volume Group VolGroup00 con el espacio que nos aporta /dev/sda3

[vi-admin@vma01 ~]$ sudo lvextend -L+5G /dev/VolGroup00/var
Extending logical volume var to 5.50 GB
Logical volume var successfully resized

Verificamos que hemos ampliado /var

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
496M 20M 452M 5% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm

Está igual !!!! esto es debido a que hemos ampliado el Volumen Lógico /var pero no se ha formateado para el S.O., esto lo realizamos a continuación:

[vi-admin@vma01 ~]$ sudo resize2fs -p /dev/VolGroup00/var
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/var is mounted on /var/log; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/var to 5767168 (1k) blocks.
The filesystem on /dev/VolGroup00/var is now 5767168 blocks long.

Ahora si, ya podemos seguir recolectando logs sin llenar el disco.

[vi-admin@vma01 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
3.3G 1.5G 1.7G 46% /
/dev/mapper/VolGroup00-var
5.4G 21M 5.1G 1% /var/log
/dev/sda1 99M 16M 79M 17% /boot
tmpfs 250M 0 250M 0% /dev/shm
[vi-admin@vma01 ~]$

¿Como cambiar la dirección IP de la vMA?

Es simple:

Paso 1: Modificamos el archivo /etc/sysconfig/network-scripts/ifcfg-eth0
Paso 2: sudo /etc/init.d/network restart

ya tenemos nueva IP, verifica que en /etc/hosts aparece la nueva IP.

Bueno amigos, con este repaso de Linux me despido temporalmente, deseando que paséis unos días tranquilos (o no) y nos volvemos a encontrar en septiembre con las novedades de la versión 4.1 que tenemos disponible desde el día 13 de julio. Ser felices.

Hola Amigos,

En el post de hoy os describiré algunos comandos muy útililes para el uso de snapshots. Como sabéis con un snapshot de XenServer y la máquina virtual podemos trasladarla a un estado anterior.

Realizar un snapshot regular desde linea de comandos, crearemos un snapshot consistente de cualquier máquina virtual, ya sea windows o linux.

xe vm-snapshot vm=”maquina virtual” new-name-label=”nombre del snapshot”

Si queremos hacer uso del soporte VSS para hacer un snapshot de un windows 2003 server o 2008 server podemos hacer uso de la siguiente opción:

xe vm-snapshot-with-quiesce vm=”maquina virtual” new-name-label=”nombre del snapshot”

Comando para listar los diferentes snapshots almacenados:

xe template-list is-a-snapshot=true params=all

Comando para listar los diferentes snapshots almacenados de una máquina virtual concreta:

xe template-list snapshot_of=”uud de la máquina virtual”

Comando para borrar un snapshot:

xe vm-uninstall uuid=”etiqueta del snapshot” force=true

Con todo esto nos servirá para familiarizarnos con los imprescindibles snapshots. Si me vais siguiendo a lo largo de los post veréis que le doy gran importancia a los backups y continuidad de negocio, creo que es algo que hay que tenerlo muy presente y siempre preparado.

En futuros post y una vez familiarizados con estos comandos descritos os mostraré un script desde el cual podremos hacer un backup del snapshot y exportarlo como template sobre un almacenamiento NFS.

Nada mas amigos, espero que sea de utilidad.