# rm-rf.es » Virtualización

Clonar una máquina virtual KVM con virt-clone

Alex — Sun, 26 Feb 2012 18:02:32 +0000

Clonar una máquina virtual es realmente sencillo. En el caso de KVM es tan simple como apagar la máquina virtual para tener consistencia de datos y utilizar el comando virt-clone.

Podemos hacerlo de dos formas, siguiendo un asistente ejecutando virt-clone con el parámetro –prompt o pasar a mano todos los parámetros necesarios.

En el primer caso simplemente respondemos las preguntas que van saliendo, que básicamente son:

Nombre de la máquina virtual a clonar
Nombre para la máquina virtual resultante
Ruta al disco o discos clonados (discos destino).

# virt-clone --prompt
What is the name of the original virtual machine?
virtual01
What is the name for the cloned virtual machine?
clon_virtual01
What would you like to use as the cloned disk (file path) for '/var/lib/libvirt/images/virtual01.img'?
/var/lib/libvirt/images/clon_virtual01.img
Allocating 'clon_virtual01.img'      5% [=-             ]  29 MB/s | 437 MB     04:25
...
...
Clone clon_virtual01 created successfully

Este mismo ejemplo podríamos ejecutarlo directamente de esta forma (si ejecutáis un –help veréis todos los paramétros:

# virt-clone -o virtual01 -n clon_virtual01 -f /var/lib/libvirt/images/clon_virtual01.img
Cloning virtual01.img 4% [==- ] 134 MB/s | 390 MB 00:58 ETA

Otra opción que hace aún más sencillo el trabajo es dejar al propio sistema que elija automáticamente el nombre de la máquina virtual destino y las rutas a los nuevos discos. Para ello usamos el parámetro auto-clone:

# virt-clone -o virtual01 --auto-clone

Un consejo: la primera vez que arranquéis un clon, hacedlo en single-user, runlevel 1 o cualquiera que os permita modificar la configuración de red para evitar conflictos, MAC e IPs duplicadas, etc.

Instalar una máquina virtual KVM con Kickstart

Alex — Sat, 10 Dec 2011 10:20:41 +0000

Ya he hablado en otras ocasiones de Kickstart, explicando el modo de automatizar instalaciones de CentOS con Kickstart. En este caso el proceso es igual, pero aplicándolo a la automatización en virtualización. Si desconocéis como funciona Kickstart/Anaconda os recomiendo revisar antes ese post.

Vamos a ver como automatizar la instalación de máquina virtuales, en este caso KVM, pero es aplicable a Xen y otros sistemas de virtualización.

Vamos a hacer uso de la herramienta virt-install para las instalaciones. Esta es la línea de comandos que podemos usar para instalar una máquina virtual Scientific Linux (sería igual para RHEL, CentOS, Fedora…) sin intervención manual:

# virt-install  --name testKS \
                --ram 512 \
                --disk /var/lib/libvirt/images/testks.img,size=5 \
                 -l "ftp://ftp.scientificlinux.org/linux/scientific/6.1/x86_64/os/" \
                 -x "ks=ftp://192.168.1.130/pub/ks.cfg"

Starting install...
Retrieving file .treeinfo...                           |  768 B     00:00 ...
Retrieving file vmlinuz...                             | 7.4 MB     00:05 ...
Retrieving file initrd.img...                          |  68 MB     00:53 ...
Creating domain...                                     |    0 B     00:00

Los parámetros utilizados son los siguientes:

–name: nombre de la máquina virtual.
–ram: tamaño de memoria RAM en MB.
–disk: ruta y nombre del fichero .img que será utilizado como disco duro virtual. Tras la ruta a la imagen se especifica el tamaño en GB de la imágen (5).
-l (–location): especifica el lugar donde se encuentra el instalador del sistema (vmlinuz e initrd.img), en este caso especificamos el respositorio oficial de Scifi Linux y la ruta exacta para 64bits.
-x (–extra-args): especificamos argumentos extra para la instalación, en este caso tiene que ser la ruta al fichero Kickstart que tiene toda la configuración del proceso de instalación.

Y esto es todo. Si el fichero Kickstart está bien, se realizará una instalación totalmente desatendida del sistema operativo.

Solaris Zones ERROR: the zonepath must be a ZFS dataset

Alex — Sun, 04 Dec 2011 18:36:32 +0000

A la hora de crear una zona en Solaris (Solaris Zones|Solaris Containers), es imprescindible que el zonepath, que es el lugar físico en el que se va a alojar sea un sistema de ficheros zfs independiente, también llamado ZFS dataset. En caso contrario recibiremos este error a la hora de instalarla:

ERROR: No zonepath dataset; the zonepath must be a ZFS dataset.

El error es lo suficientemente descriptivo. A la hora de configurar la zona, establecemos el zonepath del siguiente modo dentro del modo de configuración de la zona:

# zonecfg -z zona01
zonecfg:zona01> set zonepath=/ruta/a/la/zona

El paso previo es entonces crear el dataset correspondiente:

# zfs create /rpool/zones
# zfs create /rpool/zones/zona01

Una vez realizado, podemos establecer como zonepath “/rpool/zones/zona01″, verificar la configuración con “verify”, hacer el “commit” e instalar la zona:

# zoneadm -z zona01 install

Instalar una versión específica de Parallels Virtuozzo Containers

Alex — Fri, 26 Aug 2011 15:30:07 +0000

El otro día se publicó una KB de Parallels sobre algo que llevaba tiempo intentando poder hacer. Cuando te bajas el instalador de Parallels Virtuozzo Containers para Linux, al comenzar la instalación siempre te fuerza a instalar la última versión disponible. En caso de estar obligado a instalar una versión específica, podemos hacerlo siguiendo estos pasos:

Lo primero es bajar el instalador como lo haríamos normalmente:

# wget http://download.parallels.com/pvc/47/lin/vzinstall-linux-x86_64.bin
# chmod a+x vzinstall-linux-x86_64.bin

Una vez descargado, con el parámetro ‘list‘ podemos ver las versiones y arquitecturas disponibles para la instalación:

# ./vzinstall-linux-x86_64.bin list
Downloading index files...
Templates set: (Default set)
Version  Platform  Architecture  Download size
4.7.0-94 Linux     i386          544MB
4.7.0-94 Linux     x86_64        789MB
4.6.0-187Linux     i386          607MB
4.6.0-187Linux     x86_64        782MB
4.0.0-448Linux     i386          848MB
4.0.0-448Linux     ia64          940MB
4.0.0-448Linux     x86_64        1.0GB
4.0      w2k3      i386          41MB
4.0      w2k3      ia64          60MB
4.0      w2k3      x86_64        48MB

Ahora solo queda elegir la versión, plataforma y arquitectura para nuestra instalación. Si quisieramos instalar la versión 4.6.0-187 para 64 bits Linux:

# ./vzinstall-linux-x86_64.bin install --archs x86_64 --dist-ver 4.6.0-187 --platforms Linux

VMware P2V: Unable to query the live Linux source machine

Alex — Sat, 13 Aug 2011 08:25:53 +0000

Vamos a ver la posible solución a este problema, que se nos presenta cuando intentamos convertir un sistema Linux de una máquina física a una máquina virtual (vmware p2v) de VMware con la herramienta VMware vCenter Converter Standalone.

El problema se reproduce después de introducir los datos correctos de conexión SSH al servidor. Estos datos vemos que son correctos porque si ponemos unos incorrectos salta el error. Además, en la máquina que intentamos migrar si hacemos un tcpdump vemos que efectivamente está llegando bien.

Este es el error que recibimos en el primer paso de la conversión:

VMware: Unable to query the live Linux source machine

En nuestro caso, el problema no tenía que ver ni con el firewall del sistema, ni con restricciones TCP Wrappers, ni con SELinux, etc. El problema tenía origen en las restricciones establecidas en la partición temporal /tmp. Nosotros montamos /tmp con los bits noexec y nosuid. Algo común en servidores con cPanel:

/usr/tmpDSK on /tmp type ext3 (rw,noexec,nosuid,loop=/dev/loop0)

Al parecer VMware intenta ejecutar y realizar acciones en /tmp, y debido a esto no puede. Podemos solucionarlo entonces montando /tmp temporalmente con los bits de ejecución:

# mount -o remount  -t ext3 /usr/tmpDSK /tmp -o rw,exec,nodev -o loop

Y cuando acabemos securizar de nuevo:

# mount -o remount  -t ext3 /usr/tmpDSK /tmp -o rw,noexec,nosuid -o loop

Cloud computing o servidores dedicados: ¿qué elegir?

Alex — Wed, 10 Aug 2011 15:27:04 +0000

En los últimos días, debido al problema acontecido en el servicio de Cloud Computing de Amazon provocado por la caída de un rayo en el CPD de Irlanda, ha vuelto a surgir el debate sobre los beneficios del Cloud Computing frente a otro tipo de soportes más convencionales, como por ejemplo los servidores dedicados. Cada producto tienes sus ventajas e inconvenientes, así que vamos a intentar ver a que tipo de cliente puede ir dirigido uno y otro.

Imagen: www.racksstore.com

Puesta en marcha

En una infraestructura Cloud Computing/cloud hosting puedes poner en marcha un buen número de instancias de servidores, balanceadores, redes, firewalls, etc en escasos minutos. Esto es impensable en servidores dedicados, en los que normalmente se tarda entre 24 y 48 horas como mínimo en tener el servicio activo.

Escalabilidad

La filosofía básica del Cloud Computing es la de pagar por los recursos que utilizas, nada más. Si tú necesitas durante X tiempo un número mayor de recursos (memoria, disco, cpu, etc) puedes ampliar tus instancias de forma prácticamente instantanea y una vez finalizado volver a la normalidad. Esto es un gran avance respecto a un servidor dedicado, en el que desde un primer momento contratas una máquina física con unos recursos concretos, los cuales puedes estar desaprovechando (probablemente) o llegar un momento en el que se queden cortos y sea más laborioso la ampliación de piezas.

Precio y costes

Este punto va íntimamente relacionado con el de la escalabilidad. Es de suponer que siempre será más caro contratar un servidor dedicado que alojar un proyecto en la nube. Esto es debido a que mientras que en la nube conforme necesitas más recursos los vas contratando, en un servidor dedicado has de disponer desde un principio de unos recursos fijos, los uses o no. No obstante este punto puede variar según el proyecto, requerimientos, etc.

Administración de tú infraestructura

La mayoría de proveedores de hosting ofrecen la posibilidad de contratar un paquete completo de servidor dedicado + administración. Esto implica que es el proveedor el encargado de la puesta en marcha del servidor, los servicios y de brindarte soporte ante cualquier tipo de problema que encuentres. Por otro lado, la mayoría de proveedores de Cloud Computing no ofrecen servicio de administración, lo que implica que eres tú el encargado de mantener tus máquinas virtuales alojadas en la nube.

Alta disponibilidad

El Cloud Computing es la panacea de la alta disponibilidad, al no depender directamente del hardware las posibilidades de parada debido a fallos físicos se reducen casi al 99%, excepto casos especiales como lo sucedido estos días en Amazon, algo que, en caso de tener nuestras instancias virtuales replicadas en distintos centros de datos haría imposible la posibilidad de caída por fallos físicos. En cambio, en un servidor dedicado estás supeditado a cualquier problema físico: fallos de discos (para evitarlo siempre hay que contratar servidores dedicados con raid por hardware), fallos de fuentes de alimentación, memoria, etc. Los servidores con los componentes redundados suelen salir bastante más caros.

Rendimiento

En temas de rendimiento es probable que el servidor dedicado salga ganando. Sabes que no compartes tu infraestructura física con ningún otro cliente, dispones del 100% del hardware para ti, mientras que en la nube siempre tendrás una “porción del pastel” al igual que el resto de clientes alojados en la nube, esparcidos a lo largo de X número de servidores.

Seguridad y privacidad

Este punto estaría más enfocado al hecho de llevar aplicaciones a la nube en lugar de mantenerlas en equipos físicos (aplicaciones de ofimática, contabilidad, correo…). Nosotros no conocemos el nivel de seguridad de la nube y nuestros datos pueden estar al alcance de cualquiera en caso de un fallo de seguridad.

Espero que os hayan servidor de ayuda estos puntos para aclararos sobre los beneficios de cada opción. Al final, lo mejor es probarlo por ti mismo y seleccionar la mejor opción según nuestras necesidades.

Virtuozzo Containers: plantilla de CentOS 6 OS disponible

Alex — Tue, 19 Jul 2011 18:40:29 +0000

Ya está disponible la plantilla EZ del sistema operativo CentOS 6 para sistemas de virtualización Virtuozzo Containers. La plantilla es compatible tanto para Virtuozzo Containers for Linux 4.6 como Virtuozzo Containers for Linux 4.0.

La plantilla está disponible tanto para 32 como 64 bits a través de los siguientes rpm:

centos-6-x86-ez-4.0.0-2.noarch.rpm
centos-6-x86_64-ez-4.0.0-2.noarch.rpm

Y las aplicaciones disponibles son las siguientes:

32-bit:

cyrus-imap-centos-6-x86-ez-4.0.0-1.noarch.rpm
devel-centos-6-x86-ez-4.0.0-1.noarch.rpm
jre-centos-6-x86-ez-4.0.0-1.noarch.rpm
jsdk-centos-6-x86-ez-4.0.0-1.noarch.rpm
mailman-centos-6-x86-ez-4.0.0-1.noarch.rpm
mod_perl-centos-6-x86-ez-4.0.0-1.noarch.rpm
mod_ssl-centos-6-x86-ez-4.0.0-1.noarch.rpm
mysql-centos-6-x86-ez-4.0.0-1.noarch.rpm
php-centos-6-x86-ez-4.0.0-1.noarch.rpm
postgresql-centos-6-x86-ez-4.0.0-1.noarch.rpm
spamassassin-centos-6-x86-ez-4.0.0-1.noarch.rpm
tomcat-centos-6-x86-ez-4.0.0-1.noarch.rpm
vsftpd-centos-6-x86-ez-4.0.0-1.noarch.rpm
webalizer-centos-6-x86-ez-4.0.0-1.noarch.rpm

64-bit:

cyrus-imap-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
devel-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
jre-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
jsdk-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mailman-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mod_perl-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mod_ssl-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
mysql-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
php-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
postgresql-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
spamassassin-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
tomcat-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
vsftpd-centos-6-x86_64-ez-4.0.0-1.noarch.rpm
webalizer-centos-6-x86_64-ez-4.0.0-1.noarch.rpm

Si no sabéis instalar plantillas de sistemas operativos o aplicaciones en Virtuozzo revisad este otro artículo: Instalar plantillas en Virtuozzo.

OpenVZ & Virtuozzo: activar noatime para un contenedor

Alex — Mon, 09 May 2011 15:25:46 +0000

El otro día escribí un artículo en el que se explicaban las diferencias entre atime, noatime y relatime, podéis leerlo si queréis saber las diferencias entre cada una de estos atributos asignables a los sistemas de ficheros.

En esta entrada vamos a ver la forma correcta de modificar este atributo a una máquina virtual o contenedor en los sistemas de virtualización Virtuozzo y OpenVZ. En lugar de asignar los atributos a nivel de /etc/fstab debemos hacerlo mediante el comando

vzctl set

. En el siguiente ejemplo asignamos el atributo noatime al contenedor con ID 150, lo haremos en el nodo hardware:

# vzctl set 150 --noatime yes --save
Setting noatime mount flag for Container
Saved parameters for Container 150

Una vez realizado, podemos acceder a la máquina virtual y verificar que el cambio se ha realizado correctamente:

# mount
/dev/vzfs on / type vzfs (rw,noatime)

Backups en Virtuozzo 4.6 con vzabackup / vzarestore

Alex — Fri, 15 Apr 2011 14:43:26 +0000

vzabackup y vzarestore son las utilidades designadas a la gestión de copias de seguridad tanto para nodos Hardware y máquinas virtuales Virtuozzo.

vzabackup

vzabackup permite hacer copia de seguridad tanto del propio nodo Hardware como de uno, varios o todos los contenedores del mismo. También permite hacer backups de nodos remotos. A continuación podéis ver todas las opciones disponibles:

vzabackup [BACKUP OPTIONS...] NODE1 ... [CT OPTIONS...]

[BACKUP OPTIONS]
-F, -I, --Tfull
	Create a full backup.
-i, --Tinc
	Make an incremental backup or, if no full backups are available, a full backup.
--Tdiff
	Make a differential backup or, if no full backups are available, a full backup
-o,--rm-old
	Create a backup and then remove the oldest backups.
-d,--rm-tag
	Create a backup and then remove the backup with the
	specified backupID. You can learn the backup IDs of the
-J
	Do backing up nodes simultaneously if more than one source node specified.
--force
	Don't stop on errors during backup of Container. Should be used when more than
	one Container's specified to backup.
--view-folder
	 Show current backup storage configuration.
--set-folder-creds [USER[:PASSWORD]]
	 Set backup storage login credentials.
--backup-folder-path PATH
	Path to a custom backup storage location.
--backup-folder-login USER
	Username for a custom backup storage on a samba share.
--backup-folder-passwd PASSWORD
	Password for a custom backup storage on a samba share.
--set-folder
	Use --backup-folder-* options values to change backup storage configuration.
-D DESCRIPTION
	Set backup description.
-C
	Set compression level in range from 0 to 3.
--storage [USER[:PASSWD]]@ADDRESS
	Set address and credentials for storage server, where backup is stored.
NODE
	NODE parameter specifies the node to be backed up.

	 Node should be specified in format: [USER[:PASSWD]]@ADDRESS.

[CT OPTIONS]
-e
	List of Containers to backing up. Back up all the Containers if omitted.
-x
	List of Containers to skip. Do not skip any Containers if omitted.
--include-files
	Paths(files) to include in backups.
--exclude-files
	Paths(files) to exclude from backups.

Vamos a hacer un ejemplo práctico en el que queremos hacer una copia de seguridad de todos los contenedores del nodo Hardware local en la ruta /backup (en este caso una unidad montada por NFS):

# vzabackup --backup-folder-path /backup -i localhost

Con -i indicamos que queremos hacer backups incrementales y con “localhost” que son para el nodo local. Si quisieramos hacerlo en un storage remoto y de un nodo remoto sería así:

# vzabackup  --storage root:password@192.168.0.100 root:password_remoto@192.168.0.111

Si quisieramos hacerlo únicamente del contenedor 101:

# vzabackup --backup-folder-path /backup -i localhost -e 101

El resto es jugar con las opciones, la compresión, el tipo de backup, etc. A la hora de hacer backups de servidores remotos hay que asegurarse que la conectividad SSH es satisfactoria y que pueden comunicarse mediante llave SSH.

vzarestore

Lo primero que debemos saber de vzarestore es que permite mostrar un listado de los backups disponibles en el nodo seleccionado. Si quisieramos ver los backups disponibles en el nodo local y en la ruta /backup:

# vzarestore --list --backup-folder-path /backup
Show existing backups...
CTID    Title                   Creation date/time     Type Size
2719275 vps1                2011-04-15T111346+0002 full 213.19 Mb
305470  vps2                2011-04-15T110646+0002 full 262.13 Mb
3574391 vps3               2011-04-15T110041+0002 full 245.63 Mb
5195637 vps4               2011-04-15T111616+0002 full 710.83 Mb
8426989 vps5               2011-04-15T113722+0002 full 291.22 Mb

Para ver los backups en nodos remotos utilizaríamos el parámetro –storage:

# vzarestore --list --storage root:password_remoto@192.168.0.110

Bien, para restaurar un backup únicamente tendríamos que seleccionar su ID (CTID) y en caso de estar en una ubicación remota especificarla:

Remoto:

# vzarestore 101 --storage root:password_remoto@192.168.200.200

Local:

# vzarestore 101

En caso de contar con backups incrementales, podríamos especificar el punto de restauración con el parámetro “-b” seguido del identificador del backup (no el del contenedor). A continuación la ayuda del comando:

vzarestore is the utility to restore Container's which were backed up by means
of vzbackup. Also it can be used to remove, listing backups
and browsing contents of backups.

vzarestore [CTID[:New CTID] | -e  | -x ] [RESTORE OPTIONS] [STORAGE SERVER]
vzarestore -r, --remove  [STORAGE SERVER]
vzarestore -l,--list [LIST OPTIONS...] [STORAGE SERVER]
vzarestore --browse backupID [BROWSE OPTIONS...] [STORAGE SERVER]
vzarestore --print-ve-config BackupID [STORAGE SERVER]
vzarestore -h,--help

RESTORE OPTIONS:
-B
	Treat parameters for -e and -x options as backup ID's.
--force
	Don't stop on errors during restore of Container.
--files
	Separate files to restore, FILE is the full path to the file.
--skip-ve-config
	Do not restore Container config.
-b backupID
	Backup ID to restore files, if omitted then last backup will used.
--skip-locked
	Don't stop on errors during restore of locked files.

LIST OPTIONS
-f,--full
	Show full information (this option can be used only with --list).
--latest
	Show latest backups only (this option can be used only with --list).
-e
	List of Container's to show.
-B
	Treat parameters for -e option as backup ID's.

BROWSE OPTIONS
-d,--dir DIR
	Set the paths to the folder whose contents is to be shown.

STORAGE SERVER
--storage [USER[:PASSW]]@ADDRESS
	Set address and credentials to storage server.
	When this argument is omitted then local node will be used as storage server.
--backup-folder-path PATH
	Path to a custom backup storage location.

Virtuozzo: Averiguar a que contenedor pertenece un proceso

Alex — Mon, 21 Feb 2011 16:06:05 +0000

Dentro de un nodo físico Virtuozzo, si ejecutamos un top podemos ver los procesos que más CPU y memoria están consumiendo, pero no podemos averiguar a simple vista a que máquina virtual pertenece. Para averiguarlo tenemos dos opciones.

La primera es sustituir el uso de top por vztop. Se trata de una versión de top modificada por Virtuozzo a través de la cual aparece una nueva columna que muestra el ID de la máquina virtual.

$ vztop

vztop - 16:59:44 up 72 days,  5:11,  1 user,  load average: 2.04, 2.60, 2.76
Tasks: 528 total,   1 running, 522 sleeping,   0 stopped,   5 zombie
Cpu(s): 19.6% us,  7.4% sy,  0.2% ni, 62.2% id,  9.9% wa,  0.0% hi,  0.6% si
Mem:   4038416k total,  3948496k used,    89920k free,   173288k buffers
Swap:  4192956k total,      160k used,  4192796k free,  1701956k cached

 CTID   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  104 20875 nobody    15   0 41748  32m 1508 S   11  0.8   0:00.17 httpd
  104 11085 nobody    15   0 41904  33m 1564 S   10  0.8   0:01.53 httpd
  104 20899 nobody    15   0 41748  32m 1508 S   10  0.8   0:00.09 httpd
  104 18757 nobody    15   0 42016  33m 1556 S    8  0.8   0:00.64 httpd
  104 21077 527       18   0     0    0    0 Z    8  0.0   0:00.04 php
  104 21079 527       18   0     0    0    0 Z    8  0.0   0:00.04 php
  104 18752 nobody    15   0 41632  32m 1536 S    6  0.8   0:00.50 httpd
  104 19390 nobody    15   0 41748  32m 1532 S    6  0.8   0:00.44 httpd
  104 20884 nobody    15   0 41932  33m 1600 S    6  0.8   0:00.11 httpd

La otra opción es utilizar otro comando propio de Virtuozzo,

vzpid

. Su uso es sencillo, hay que pasar como parámetro el PID y nos dirá el contenedor/máquina virtual al que pertenece:

# vzpid 20845
Pid	VEID	Name
20845	109	httpd

109 es el ID de la máquina virtual, ejecutando un

vzlist

veremos el hostname y más información sobre la misma:

# vzlist 109
      CTID      NPROC STATUS    IP_ADDR         HOSTNAME
       109        90 running   192.168.0.155       vps1.test.com

# rm-rf.es » Virtualización

Clonar una máquina virtual KVM con virt-clone

También te puede interesar:

Instalar una máquina virtual KVM con Kickstart

También te puede interesar:

Solaris Zones ERROR: the zonepath must be a ZFS dataset

También te puede interesar:

Instalar una versión específica de Parallels Virtuozzo Containers

También te puede interesar:

VMware P2V: Unable to query the live Linux source machine

También te puede interesar:

Cloud computing o servidores dedicados: ¿qué elegir?

Puesta en marcha

Escalabilidad

Precio y costes

Administración de tú infraestructura

Alta disponibilidad

Rendimiento

Seguridad y privacidad

También te puede interesar:

Virtuozzo Containers: plantilla de CentOS 6 OS disponible

También te puede interesar:

OpenVZ & Virtuozzo: activar noatime para un contenedor

También te puede interesar:

Backups en Virtuozzo 4.6 con vzabackup / vzarestore

vzabackup

vzarestore

También te puede interesar:

Virtuozzo: Averiguar a que contenedor pertenece un proceso

También te puede interesar: