[rsuarez]

muchas gracias por el tutorial amigo.. me funciono muy bien, gracias.

[ralosevilla]

Muchisimas gracias por el tutorial, lo estoy siguiendo y todo ok salvo una cosilla que me gustaria preguntar:

Una vez terminada la parte basica del tutorial y reiniciado no consigo ver en el manager la unidad backups_nodo1 y por tanto no puedo realizar backups, no entiendo que puede pasar puesto que he seguido a pie juntillas todos los pasos del tutorial.

Gracias de nuevo, espero pueda ayudarme. Saludos.

[landy1103]

Era problema del manager no realizaba las particiones como se le solicitaba

[yo_david]

Tiene pinta de que la configuracion de IPTABLES en /etc/vz/vz.conf no es la misma en un nodo que en otro.
En el tutorial de Power:
http://foros.ovh.es/showthread.php?t=9807
se configura en /etc/vz/vz.conf el parametro IPTABLES así:

si, en los 2 estan igual.. exactamente como tu pusiste, de todas formas he decidido reinstalar todo, este finde lo hare.

una cosa Guille!
veo que has experimientado con IPv6 en proxmox

los nuevos KS de OVH que dan IPv6 aparece en el manager como
2001:31d0:a:1008::1/128 (IP CAMBIADA)
¿significa eso que no tengo mas IPs?

¿y si quisiera usar esa IPv6 en un CT proxmox, podria?
he añadido la ip tal cual a un CT y no resuelve, la IPv6 comentada junto con la IPv4 van las 2 dirigidas al server proxmox.. no se si habria forma de anular la IPv6 del server y ponerla al CT

tambien veo raro que OVH de solo 1 IPv6, joe! con la cantidad de IPs que hay y que dudo que se puedan agotar en los proximos 200años mal gastandolas a chorros.. no entenderia esa politica.

[amorales]

Muy buen tutorial! Con este tuto y con el de Power ya no hay (casi) secretos con Proxmox

A ver... yo no he usado SolusVM y es una opción que me planteo por el tema de la nueva versión de Proxmox 3.1 y el famoso popup avisando que no se tiene una licencia.

Por lo que he podido ver siempre es posible apuntar a los repositorios de test de Proxmox, que aunque dicen que no lo aconsejan para entornos de producción si que son más o menos estables. La única diferencia es que en cada login al panel de Proxmox aparece el popup, pero esto no hace que deje de funcionar el sistema (ya hay parches rulando por ahí que quitan esto).

Proxmox es de base un proyecto Opensource aunque veo correcto que esta empresa quiera cobrar por su trabajo y soporte.

Por el momento mantengo dos servidores con Proxmox apuntando a las fuentes de Test. Aunque me quedo algo preocupado por futuras actualizaciones.

[Guille]

Error: undump failed: Invalid argument
Restoring failed:
Error: iptables-restore exited with 1
Error: Most probably some iptables modules are not loaded
Error: or CT's iptables utilities are incompatible with this kernel (version is older than 1.4.0)

Tiene pinta de que la configuracion de IPTABLES en /etc/vz/vz.conf no es la misma en un nodo que en otro.
En el tutorial de Power:
http://foros.ovh.es/showthread.php?t=9807
se configura en /etc/vz/vz.conf el parametro IPTABLES así:

IPTABLES="ipt_REJECT ipt_recent ipt_owner ipt_REDIRECT ipt_tos ipt_TOS ipt_LOG ip_conntrack ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state iptable_nat ip_nat_ftp"

[prointernet]

¿¿y estos errores al enviar un MV usando vzmigrate??
despues de varias horas esperando que se transfiera al acabar me sale..

Error: undump failed: Invalid argument
Restoring failed:
Error: iptables-restore exited with 1
Error: Most probably some iptables modules are not loaded
Error: or CT's iptables utilities are incompatible with this kernel (version is older than 1.4.0)
Error: (Offline migration and iptools upgrade might help).
Error: rst_restore_net: -22
Container start failed
Can't umount /var/lib/vz/root/100: Device or resource busy
Error: Failed to undump container

Hacen falta más pistas. Todo lo que me puedas contar sobre que tenías instalado en cada servidor, en que dirección hiciste la migración, que particionado tienes en cada servidor y cosas así. Logs que puedas tener sobre los errores. Haber si te puedo ayudar.
Te adelanto que he migrado del Proxmox 1.x a SolusVM, de SolusVM a Proxmox 3.0 y próximamente de Proxmox 3.0 a SolusVM 1.14. Siempre funcionando a la primera. Lo único, que el archivo .conf de las máquinas tenía más variables estando en SolusVM, cosas que Proxmox no utiliza porque, como la variable que limita el ancho de banda máximo. En mi migración hacia Proxmox 3.0 tuve que cambiar en esos archivos una ruta, que el propio Proxmox me advertía al hacer un backup live. Pero las máquinas siempre han funcionado en cuanto se acababa la migración usando vzmigrate. Yo siempre lo hice desde consola.

Con esto te quiero decir que lo más seguro es que alguno de los dos servidores esté mal montado. Si no no podía tener tantos errores.

[yo_david]

¿¿y estos errores al enviar un MV usando vzmigrate??
despues de varias horas esperando que se transfiera al acabar me sale..

Error: undump failed: Invalid argument
Restoring failed:
Error: iptables-restore exited with 1
Error: Most probably some iptables modules are not loaded
Error: or CT's iptables utilities are incompatible with this kernel (version is older than 1.4.0)
Error: (Offline migration and iptools upgrade might help).
Error: rst_restore_net: -22
Container start failed
Can't umount /var/lib/vz/root/100: Device or resource busy
Error: Failed to undump container

[prointernet]

¿que usais en /etc/apt/sources.list?

es que entre el nuevo cambio de politica de proxmox y la mierda de http://debian.mirrors.ovh.net/debian/ que falla cada 2x3, no se como dejarlo

que usais vosotros?

Yo le he dejado la lista predeterminada, sin modificar.

De todas formas, comentar que a 4.16€/mes por poder tener un entorno de producción..... me vuelvo a SolusVM

No descarto el mantener este tutorial, pero desde luego para mi fue un error volver a Proxmox. Suerte que tengo sólo 4 máquinas y se pueden migrar fácil.
Me cogeré una licencia Mini para Master sin OpenVZ y otra Mini Slave para poder tener las 5 máquinas y listo. Por $7,50/mes tengo mejor servicio y algunas características que sólo tiene SolusVM, como limitar el ancho de banda que ahora se vuelve más interesante con el aumento delos nuevos servers. Y es que al final sólo se aprecia lo que se tiene cuando se pierde.

SolusVm es superior

Supongo que mi próximo tutorial será como instalar SolusVM con master independiente y sin usar la preinstalación de OVH, que dudo que sea la idónea.

Saludos

[yo_david]

¿que usais en /etc/apt/sources.list?

es que entre el nuevo cambio de politica de proxmox y la mierda de http://debian.mirrors.ovh.net/debian/ que falla cada 2x3, no se como dejarlo

que usais vosotros?

[tecneca]

Magnífico tutorial!! Muchísimas gracias!

Hay algunos puntos de lo más interesantes, que seguro que para próximas instalaciones, me vendrán de perlas.

De nuevo, mil gracias!

[Power]

Hola prointernet,

Magnífica la idea de un tutorial de CSF.
Es un tema sobre el que muchos colegas andan un poco perdidos.
Sería genial tener todo el tutorial recopilado en un solo hilo.

Te animo a crearlo.
Una vez hecho, con las aportaciones de todos seguro que se mejora hasta hacerlo un tutorial imprescindible.

Saludos y gracias por todo.
PD: Siento no poder ayudar más, pero en estos momentos tengo sobrecarga de trabajo.

[prointernet]

Hola,

Magnífico tutorial.
¡ Muchas gracias !

Sólo anotar un pequeño error:
Donde dice poner bwlimit: 50000 en /etc/vzdump.conf
El valor de bwlimit, en vzdump.conf, debe estar expresado en KB/s (Kbytes por segundo), no en Kb/s (Kbits por segundo).
El valor 50000 limitaría a 50.000 KB/s (Kbytes por segundo) = 400.000 Kb/s (Kbits por segundo) = 400 Mb/s (Mbits por segundo)
(Más o menos )

Saludos y, de nuevo, mi agradecimiento

Power, tienes razón. Por si acaso, contrasté el dato en varios sitios , pero estabas en lo cierto. Corregido en todo el tutorial con el valor correcto para los Mbps que quería representar.
Además he corregido unas cuantas faltas de ortografía de las que parece que todos nos olvidamos, pero que también son fallos.

Comentar que este tutorial pretendía ser una versión mejorada, actualizada y razonada del tuyo. Creo que al final me salió bien gracias a tu guión.

Mi próximo trabajo será un tutorial para instalar y configurar CSF correctamente en los CT y el nodo. Es algo que me gustaría implementar y que todavía no me queda bien. Todos los que queráis aportar enlaces con documentación sobre el tema, enviádmelos por privado.

Y si algún habilidoso se anima, creo que el tutorial podría servir como guión para crear un script que nos ejecute todos los pasos excepto los opcionales. Ahí dejo la idea

Saludos a todos

[Power]

Hola,

Magnífico tutorial.
¡ Muchas gracias !

Sólo anotar un pequeño error:
Donde dice poner bwlimit: 50000 en /etc/vzdump.conf
El valor de bwlimit, en vzdump.conf, debe estar expresado en KB/s (Kbytes por segundo), no en Kb/s (Kbits por segundo).
El valor 50000 limitaría a 50.000 KB/s (Kbytes por segundo) = 400.000 Kb/s (Kbits por segundo) = 400 Mb/s (Mbits por segundo)
(Más o menos )

Saludos y, de nuevo, mi agradecimiento

[Guille]

Muchas gracias. Un excelente aporte.

[prointernet]

Instrucciones para instalar Proxmox sin RAID en OVH y alternativas prácticas al cluster Proxmox sin multicast

Revisado para Proxmox VE 3.0
rev. 28/08/2013

Tiempo de ejecución: 30 minutos

Equipo utilizado para este ejemplo:

mSP 2013 (32GiB de RAM y 2x2TB de disco)

TODO lo explicado en el tutorial fue utilizado en equipos en producción con excelentes resultados

Fuentes de información:

Foros de OVH.es (principalmente)
Web Oficial de Proxmox
Búsquedas en Google
Pruebas ensayo-error

Manager OVH
Reinstalar con estas particiones eligiendo particionado personalizado formateando sólo el primer disco.

1	primaria	ext3	/		-	10240MB
2	primaria	swap	none		-	2048MB

En nuestro servidor de DNS o registrador de dominios hacemos un registro de tipo A con el hostname que vamos a usar en nuestro servidor Proxmox y su IP como destino.

Luego vamos al Manager de OVH → Servicios → Inversa IPv4

Ponemos el nombre de máquina que decidimos para el registro A

Accedemos al servidor por consola SSH

ssh -p 22 root@nodo1.sudominio.com

Actualizamos el sistema y cambiamos el password que nos mandó OVH

aptitude update && aptitude upgrade -y && passwd

Editamos /etc/hostname y dejamos sólo una línea con nuestro hostname. Ej: nodo1.midominio.com

nano /etc/hostname

Editamos /etc/hosts y editamos la línea que aparece con el hostname generado por OVH y lo adaptamos al que elegimos nosotros. Ej: xxx.xx.xx.xxx nodo1.sudominio.com nodo1

nano /etc/hosts

Reiniciamos para que tenga efecto:

reboot

Regeneramos y reemplazamos nuestra clave public/private con el mismo nombre y sin passphrasse, para que reflejen nuestro nuevo nombre host:

ssh-keygen -t rsa

Cambiamos nuestro puerto de SSH por otro no estándar. Ej: Port 2222

nano /etc/ssh/sshd_config && /etc/init.d/ssh restart

Volvemos a acceder al servidor usando el nuevo puerto

ssh -p 2222 root@nodo1.clondns.com

Info: aquí yo veo interesante hacer el punto 3 del apartado “Cosas Opcionales” que hay al final de este manual, aplicándolo entre nuestro ordenador de trabajo y el servidor. Se trata de utilizar la llave que hemos generado para hacer login y evitarnos tener que escribir la contraseña cada vez que nos conectamos por ssh.

Ahora, paramos el servicio VZ, copiamos el directorio /var/lib/vz a /tmp, eliminamos el enlace simbólico /vz y eliminamos el contenido de /var/lib/vz, todo con esta línea. NO REINICIAR O PERDEREMOS /vz

/etc/init.d/vz stop && cp -ar /var/lib/vz /tmp/ && unlink /vz && rm -rf /var/lib/vz/*

Ahora vamos a modificar el particionado
Vaciamos completamente el disco 2 cambiando la tabla actual a MSDOS.

parted /dev/sdb mklabel msdos && partprobe

Creamos la partición 3 en el disco 1 ocupando todo el espacio libre. Fijarse en marcar justo el número de cluster siguiente al de END de la segunda partición (swap), porque fdisk va a sugerirnos un pequeño espacio al principio del disco. Con esta línea tendremos el dato mano para copiarlo bien.

fdisk -l && fdisk /dev/sda

Elegimos estas opciones por orden: Nueva partición, primaria, partición 3

n
p
3

Cambiamos el tipo de partición y grabamos todo: Tipo de formato, partición 3, LVM, grabar.

t
3
8e
w

Creamos una partición de backup en el disco 2 que ocupe todo el espacio.

fdisk /dev/sdb

Usar estas opciones.

n
p
1
w

Por último, aplicamos la nueva tabla en caliente y comprobamos que todas las particiones están como las queremos. Si no, habrá que repetir los pasos anteriores.

partprobe && fdisk -l

Damos formato a la partición de backup, como recomiendan los desarrolladores de Proxmox, siempre ext3.

mkfs.ext3 /dev/sdb1

Pasamos a preparar el LVM para poder hacer snapshot
Info: Orden de creación de las diferentes partes del LVM es PV → VG → LV

info: Orden de eliminación de las diferentes partes del LVM es LV → VG → PV

Vamos a ver entonces que tenemos de cada tipo.

pvdisplay && vgdisplay && lvdisplay

Si existe alguno, los eliminamos en el orden inverso a como se crean usando este comando de ejemplo. En el comando debes indicar el nombre del grupo LVM (VG) que necesitas eliminar y el volumen físico (PV). Indicando el grupo junto a lvremove puedes eliminar todos sus volúmenes lógicos (LV) que contiene de golpe.

lvremove vg1 && vgremove vg1 && pvremove /dev/sda3

Ahora que está todo sin LVM vamos a crear los que necesitamos. Antes de empezar, tener claro que LVM prefiere usar GiB en sus visualizaciones por consola, así que para tener números redondos yo usaré múltiplos de 1024MB durante todo el proceso.

Creamos el volumen físico y el grupo de volúmenes. Puedes cambiar vg1 por tu nombre favorito.

pvcreate /dev/sda3 && vgcreate vg1 /dev/sda3

Vemos el espacio disponible para decidir cuanto dejamos libre. Podemos ser generosos, siempre se puede reducir en caliente después de monitorizar el uso real que hacen nuestras máquinas, incrementando el lv1.

vgdisplay

Info: ¿Como decidir cuanto necesito dejarle? Sabiendo que aquí guarda los cambios del CT que se producen desde el inicio del backup hasta que lo termina, deberás pensar en cuanto tiempo tardará en hacer el snapshot y cuantos GiB de cambios puede haber en ese tiempo. Si se llena el LVM temporal al 100%, no terminará el backup.

IMPORTANTE: sumar 1GiB al espacio que queramos para snapshot. Si quieres 50GiB, deja 51GiB libres.

Info: ¿Por que? Porque luego le modificaremos el valor predeterminado a vzdump y necesitamos un pequeño margen de error. Si asignamos X GiB y resulta que faltan 10MB libres para que entre, fallará.

Creamos el Volumen donde estarán nuestros CT y otras cosas (/vz) restando los 50GiB que he decidido dejar para las snapshots, más 1GiB de margen extra. En mi caso: 1,81TiB x 1024MB = 1853,44GB – ~51GiB= 1800GB

lvcreate --size 1800G --name lv1 vg1

Ahora verificamos el espacio que quedó realmente libre para ver si está todo como queremos.

vgdisplay

Si no quedó libre la cantidad que queríamos, ejecutar lvremove vg1 y vuelves a crear el grupo y el volumen.

Ahora vamos al .conf de vzdump para pedirle que use todo el espacio libre. Por defecto usa 1024MB.

Info: Proxmox, en backup manual o programado, sólo hace un snapshot a la vez, por lo que no utiliza varios LVM temporales a la vez. Va haciendo una cola de espera y los hace por turnos. El espacio que dejamos libre, sólo lo usará un snapshot, así que vamos a decirle que lo use entero. Si no, no servirá de nada dejarle tanto espacio libre. Imprescindible para snapshot grandes o con mucho movimiento de datos durante el backup.

nano /etc/vzdump.conf

Y añadiremos esta variable fija. En este caso para que use 50GiB del espacio libre.

#size: MB
size: 51200

Verificamos toda la estructura: nombres de volumen, tamaños, espacios libres...

pvdisplay && vgdisplay && lvdisplay

Como todo está bien, aprovechado al máximo con seguridad, seguimos dando formato al volumen lógico (LV).

mkfs.ext3 /dev/vg1/lv1

Montamos el nuevo LV, recuperamos la carpeta /vz a su sitio y rehacemos el enlace simbólico, con esta línea.

mount -t ext3 /dev/vg1/lv1 /var/lib/vz && cp -ar /tmp/vz /var/lib/ && ln -s /var/lib/vz /vz

Creamos el directorio de backups y lo montamos en el segundo disco.

mkdir /backups_nodo1 && mount -t ext3 /dev/sdb1 /backups_nodo1

Ahora editamos el fstab para optimizar el rendimiento del disco evitando escrituras innecesarias.

nano /etc/fstab

Añadimos la opción noatime a la partición 1 y quitamos la opción discard (si la hay),

/dev/sda1	/	ext3	errors=remount-ro,noatime	0	1

añadimos las dos nuevas particiones a continuación de /dev/sda2 para que se monten al arrancar.

/dev/vg1/lv1		/var/lib/vz	ext3	defaults,noatime	0	2
/dev/sdb1	/backups_nodo1	ext3	defaults,noatime	0	3

LISTO, podemos reiniciar el servidor y empezar a usarlo

reboot

Info: aunque ya hemos terminado lo mínimo recomendable para empezar a usar Proxmox, te aconsejo que leas el apartado de “Cosas Opcionales” de la siguiente hoja.

Cosas opcionales
1. Si eres perfeccionista, entra al Manager de Proxmox, pulsa el nodo y cambia el Tiempo a tu zona horaria.

2. Si vas a hacer una migración de todas las máquinas y quieres que sea lo más rápido posible, valora el aumentar el límite de ancho de banda de vzdump. Si lo haces con máquinas paradas, asigna el 100% de tu ancho de banda. Si vas a hacerlo en live, revisa tus estadísticas de uso y asigna lo que normalmente está libre para que tus clientes lo noten menos y tu hagas la migración lo más rápido posible.

nano /etc/vzdump.conf

Añade esta variable fija. Con este valor usará hasta 50Mbps de tu ancho de banda disponible.
Cálculo: 1Mbits = 128 KBps

#bwlimit: KBPS (KiloBytesps)
bwlimit: 6400

3. Generar y compartir claves pública/privada para conectarnos entre nuestros nodos sin contraseña
Imprescindible si quieres usar vzmigrate desde la consola. Si ya tienes una generada, haz sólo la línea 3.

destino	# mkdir ~/.ssh
origen	# ssh-keygen -t rsa
origen	# cat .ssh/id_rsa.pub | ssh -p 2222 root@nodo1.sudominio.com 'cat >> .ssh/authorized_keys'

Y comprobamos que al conectarnos con ssh desde el equipo origen no nos pide contraseña.

ssh -p 2222 root@nodo1.sudominio.com

Esto también es útil hacerlo con tu ordenador de trabajo para “consolear” más cómodo.

4. Con este comando puedes migrar máquinas en modo live usando el vzmigrate
Imprescindible hacer el punto 3 antes de seguir. Luego con este comando puedes migrar las máquinas e ir deteniéndolas en local si la migración fue correcta. Me evito las complicaciones del cluster sin multicast.

vzmigrate -r no --ssh="-p 2222" --rsync="-z --bwlimit=11520" --keep-dst --live -v -v IP_NODO_PROXMOX 101 && vzctl stop 101

Y esta es la explicación del comando:

vzmigrate				: la herramienta de migración 
-r no					: sin eliminar el CT en origen 
--ssh="-p 2222"			: indicando el puerto ssh del equipo destino 
--rsync="-z –bwlimit=11520"	: usando compresión en el protocolo de envío y límite de 90Mbps 					  de ancho de banda
--keep-dst				: si se interrumpe el proceso, mantiene lo ya ha copiado en 						  destino y sincronizar en el reintento
--live				: migrar sin parar el CT en origen
-v -v					: va mostrando por consola los archivos que va copiando
IP_NODO_PROXMOX			: IP del Proxmox destino. NO DEL CT
101					: es el CTID del contenedor que vamos a mover.
					  Para mover varios CT seguidos, poner los CTID separados con :
					  Ej: 101:102:103:12

5. Crear un directorio compartido entre dos servidores para traspasar datos de forma segura es una buena idea. Para mandar backups directamente a otro nodo o restaurar copias que tenemos en otro nodo. El otro equipo no tiene por que ser Proxmox. Simplemente con tener SSH ya sirve. Puede ser un equipo de backups o nuestro equipo de oficina. Usaremos sshfs para esta gran utilidad. Una vez más, adiós cluster.

Comprobamos que tenemos kernel 2.6.14 o superior.

uname -r

Instalamos sshfs.

aptitude install sshfs

Cargamos el módulo.

modprobe fuse

Hasta aquí sólo hace falta hacerlo una vez.

Ahora, cada vez que nos haga falta enlazar un directorio en destino, usamos un comando como este en el equipo origen. El directorio origen donde vamos a hacer el montaje deberá estar ya creado, como siempre. Si no existe, lo creamos con la primera línea (mkdir). Si no usa la segunda directamente.

mkdir /home/usuario/backups_nodo1
sshfs -p 2222 root@nodo1.sudominio.com:/backups_nodo1 /home/usuario/backups_nodo1

Para desconectar el directorio.

fusermount -u /home/usuario/backup_nodo1

6. Hacer un backup de los metadatos de la estructura de nuestro LVM, no del contenido:

vgcfgbackup

Esta copia es almacenada en un archivo dentro de /etc/lvm/archive

Debemos descargarnos al menos los dos últimos archivos *.vg y guardarlos en local. Nos servirán para una recuperación de la estructura del LVM usando este comando.

vgcfgrestore

Esto nos permita recuperar la estructura del LVM y por tanto, facilitar el trabajo a otras herramientas para recuperar los datos. Es como recuperar la tabla de particiones del LVM.

[skunki]

Muy agradecido por el tutorial, Muchas gracias prointernet.

[prointernet]

Hola a todos:
Esta es mi primera aportación importante. Partiendo el tutorial de Power, he hecho este otro con algunas mejoras y más completo.

Se trata de un tutorial para instalar la distribución Proxmox VE 3.0 de OVH en servidores con RAID soft, sin usar RAID, ya que Proxmox no lo aconseja en absoluto. También es aplicable a servidores con RAID Hardware. En fin, el que controle un poco podrá adaptarlo a su caso particular gracias a los comentarios que se incluyen.

El tiempo de instalación para mi mSP 2013 fue de 30 minutos y pudiendo ver la tele al mismo tiempo

Aquí os dejo una copia en PDF: Tutorial Instalar Proxmox VE 3.0 OVH sin RAID (rev. 28/08/2013)

Este método es el que uso en producción y me está funcionando perfecto.
He provado el tema del cluster, pero no me convence. La única ventaja que me da es migrar máquinas y ver el estado de todos los nodos en un panel.
En este tutorial me he recomendado a mi mismo olvidarme del cluster (tras ver el lío de tener que usar unicast) y cambiarlo por tener a mano el comando de vzmigrate y conectarme a mis servidores con claves ssh.

A medida que añada nuevas funcionalidades a mi red Proxmox, iré actualizando el tutorial editando esta entrada y actualizando el mismo PDF, para mantener el enlace de descarga.

También dejo en la tercera entrada una copia del contenido del PDF


Nota mental: para no cometer errores en la conversión de unidades, no está de más preguntarle a Google.
50 Megabits a Kilobytes