Proxmox es un sistema de virtualización open source super útil, fiable y cómodo, pero… no tan cómodo como para abandonar 100% la línea de comandos, así que vamos a hacer un repaso de los más útiles después del artículo de la semana pasada donde instalábamos WebMin en PROXMOX. Los comandos mas usado son:
Midnight Commander
Midnight Commander o también llamado MC para abreviar es un gestor de archivos desarrollado bajo la licencia GNU, el cual tiene la función de servirnos como administrador de archivos, aunque en este caso su interfaz es de modo texto en vez de grafica.
$ sudo add-apt-repository ppa:eugenesan/ppa
$ sudo apt-get update
$ sudo apt-get install mc
Después desde consola podemos llamarlo con mc
He decido añadir también a este artículo ciertas configuraciones importantes que aunque no son vía comando son interesantes de conocer:
Añadir discos a proxmox
Si hemos conectado mas de un HDD a nuestro host de proxmox veremos esos discos en el menú:
Aquí vemos 2 discos que aún no forman parte real del host, debemos asignarlos para poder empezar a usarlos. Lo primeros es hacer una limpieza de los discos con el botón WIPE para cada uno de ellos:
Y inicializar GTP:
Una vez realizado este paso ya iremos a crear los almacenamientos según deseemos de las 4 opciones que nos brinda proxmox:
Tenemos 4 opciones:
LVM -> Permite tener MV almacenadas. Las MV son sin provisión de espacio a maquina (usa realmente el disco físico que se asigne a las MV) y sin deduplicación. Sin provisión. Sin Deduplicación. Consumo mínimo de recursos de máquina. Se monta en el proxmox como volumen.
LVM-Thin -> Permite tener MV almacenadas. Las MV son con provisión de espacio a maquina sin usar realmente el disco y sin deduplicación. Con provisión. Sin Deduplicación. Consumo mínimo de recursos de máquina. Se monta en el proxmox como volumen.
ZFS- >Permite tener MV almacenadas. Las MV son con deduplicación y con provision de espacio a la máquina sin usarlo realmente en disco fisico. Con provisión. Con Deduplicación. Consume muchos recursos de máquina proxmox.
Directory -> Permite tener ISOS y Backups además de MV (con provisión de espacio a maquina sin usar realmente el disco pero sin deduplicación, como LVM-Thin). Se crea para poder almacenar backups e isos principalmente dando la posibilidad de poder mover MV a él si la situación lo requiere. Consumo mínimo de recursos de máquina. Se monta en el proxmox como directorio.
Mover ISOs entre almacenes
Las ISO se puede almacenar en los Directory como hemos dicho o bien en el directo local. Si tenemos una ISO en una ubicación y queremos moverla a otra desde la web no se puede pero como tenemos instalado el Midnight Commander o también llamado MC lo haremos de forma sencilla con el. Desde la shell del servidor lo abrimos con el comando mc y solo tenemos que buscar la ubicación de la iso en la izda de la pantalla y en la derecha su destino y darle a copiar.
Las isos locales estarian ubicadas en:
<br>
/var/lib/vz/template/iso/<br>
Las isos de las carpetas Directory en:
<br>
/mnt/pve/***********/template/iso/<br>
Y si no encontramos nuestras isos siempre las podemos buscar en todo el host con:
<br>
find / -iname "*.iso"<br>
Activar sistema de almacenamiento thin en zfs
El aprovisionamiento thin es un tipo de asignación previa de almacenamiento. Un disco virtual de aprovisionamiento thin consume solo el espacio que necesita inicialmente y crece con el tiempo según la demanda. Por ejemplo, si crea un nuevo disco virtual de 30 GB con aprovisionamiento thin y le copia 10 GB de archivos, el tamaño del archivo de volumen resultante será de 10 GB, mientras que tendría un archivo de volumen de 30GB si hubiera elegido usar un Disco de aprovisionamiento thick.
Para activar este sistema solo hay que ir a mi servidor proxmox -> storage -> nvme500 -> Activar thin provision y OK
Conocer los tamaños reales que ocupan las máquinas virtuales provisionadas con thin en ZFS:
Podemos utilizar el comando
<br>
zpool list<br>
que nos muestra para las pools de datos que tenemos el espacio libre, ocupado, etc… así como el nivel de deduplicación de esa pool.
Con el comando
<br>
zfs list<br>
nos muestra los pesos reales de cada uno de los discos duros de las máquina virtuales que tenemos.
Conocer los tamaños reales que ocupan las máquinas virtuales provisionadas con thin en Directory:
Estas maquinas guardan su disco duro como *.raw *.qcow2 o *.vmdk así que solo hay que buscar el peso real de este fichero:
<br>
du -h --all / | grep disk | grep .raw<br>
<br>
du -h --all / | grep disk | grep .qcow2<br>
<br>
du -h --all / | grep disk | grep .vmdk<br>
Conocer los tamaños reales que ocupan las máquinas virtuales provisionadas con thin en LVM:
Estas maquinas guardan su disco duro volumen sobre el propio disco así que para ver el peso real de la máquina virtual sería calcular sobre el peso del volumen la ocupación en % del mismo, el comando es
lvs<br>
que os ofrece esta información
Vemos en el primer caso un disco de 456GB que contiene la maquina 105 a la cual se le ha asignado un disco duro de 640GB. La ocupación o peso real de la máquina es de 640 * 0.0182 = 11,648GB
En el segundo caso vemos un disco de 912GB que contiene varias máquinas (100, 102, 103 y 104). Por ejemplo la 104 tiene 3 discos y el mas grande es de 1TB con una ocupación de 1,1% sería un peso real de 0,011TB -> 11,26GB
Conocer los espacios provisionados a cada maquina
Son espacios definidos hasta los que podría llegar a crecer la maquina y que suelen ser mucho mas grandes que el fisico del servidor si los sumasemos todos, pero como suelen estar muy sobredimensionados realmente ocupan mucho menos como hemos visto en el comando anterior.
Deduplicación en ZFS en proxmox
Para conocer si tenemos activada la deduplicación basta con escribir el comando «zfs get dedup» y veremos en el listado si la deduplicación está ON o OFF
Activar la deduplicación
Como se ve la deduplicación no viene activa por defecto en la pool, para activarla utilizaremos el nombre de nuestra pool, en el ejemplo nvme500 y este comando «zfs set dedup=on nvme500» es comando no da ningún resultado pero si inmediatamente después ejecutamos «zfs get dedup» ya veremos que se ha activado en todos los discos de las maquinas de esa pool.
Hay que apuntar que la deduplicación se inicia a partir de este momento, es decir las maquinas que teníamos ya en memoria no pesarán menos ya que solo se verifica la posibilidad de deduplicar los datos en los nuevos que se escriban a partir de ahora. Esta deduplicación ya se aplicará a las nuevas maquina creadas en dicha pool por defecto.
Ahora sería el momento de empezar a crear las máquinas virtuales y necesitaremos mas conocimientos:
Configurar los procesadores y por qué hacerlo…
Es importante configurar el procesador exacto que tenemos en el servidor físico para que las maquinas virtuales conozcan bajo que tipo de hardware van a trabajar y con que juegos de instrucciones. Para ello debemos conocer de que tipo de generación es nuestro microprocesador y configurarlo en la propia máquina virtual
Como asignar la ram y por qué hacerlo…
A la hora de asignar la ram tenemos la opción de asignar RAM fija o dinámica. Es decir desde el menú de configuración del hardware de proxmox nos da la posibilidad de establecer la ram fija que siempre va a estar disponible para la maquina vitual. Será la que verá la maquina virtual como su ram instalada y la que proxmox consuma de la física instalada. Para ello debemos desactivar la opción de «Ballooning Device» y en la casilla superior fijar la RAM que queremos fija para esa maquina.
Pero existe la opción de marcar la opción «Ballooning Device» y trabajar con RAM dinámica. Imaginemos que activamos ballooning device y ponemos a nuestras maquinas 8GB de RAM y mínima ram 4GB. La RAM dinámica solo funciona si se consume el 80% o mas de la RAM total del nodo. Es decir mientras que la suma de la RAM asignada a todas las maquina no supere el 80% del total todas las maquinas trabajarán de forma fija, donde fijaremos en la casilla superior la ram de la máquina.
Pero en el momento que se supera ese 80% las maquinas que tengan la opción de reducir su RAM la irán liberando utilizar solo la mínima definida. Dejando RAM libre para otras máquinas. Así puedes tener el 100% de la ram asignada a tus maquinas, arrancar una nueva maquina que robe ram de las que estaban encendidas y al volver a apagarla todas volverán a recuperar su ram. Si no tenéis esta necesidad es mejor dejarla fija ya que después veremos como empeoran los rendimientos de las VM. Para linux esta reasignación en caliente se hace sola para los windows se precisa instalar el
Como instalar el Guest Agent
Si habéis trabajado con VMware, estaréis acostumbrados a las VMware Tools, con Proxmox disponemos de lo que se llama Qemu Agent. https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/
El qemu-guest-agent es una aplicación que se instala en la MV y se utiliza para intercambiar información entre el host y la mv. En Proxmox VE, el qemu-guest-agent se utiliza principalmente para tres cosas:
- Para apagar correctamente la mv, en lugar de confiar en los comandos ACPI o políticas de Windows
- Para congelar el sistema de archivos de la mv al hacer una copia de seguridad/imagen instantánea (en Windows, utilice el servicio de copia de volumen en la sombra VSS). Si el agente huésped está habilitado y en ejecución, llama a guest-fsfreeze-freeze y guest-fsfreeze-thaw para mejorar la consistencia.
- En la fase en la VM se reanuda después de una pausa (por ejemplo después de shapshot) sincroniza inmediatamente su tiempo con el hipervisor usando qemu-guest-agent (como primer paso)
En el resumen de la maquina podemos ver si tenemos este agente instalado:
Hay 2 opciones, bajar la ISO en la VM de Windows y abrirla con 7zip o bajar una ISO que montaremos desde PROXMOX para que el windows la vea e instalarlo desde ella. La mas fácil es la primera, aunque explicaré ambas:
OPCION A
Dentro de la maquina virtual con windows a ultima versión de la ISO en mi caso hoy en día es la virtio-win-0.1.229.iso y descomprimirla con 7zip. Instalaremos el qemu-ga-x86_64.msi de la carpeta guest-agent
OPCION B
Debemos descargar la ultima versión de la ISO en mi caso hoy en día es la virtio-win-0.1.229.iso
Una vez que tenemos la ISO, la deberemos montar en el sistema. Para ello la cargamos en uno de nuestros storage. Almacenamiento -> Cargar. Luego iremos a la máquina virtual que contiene el windows y editaremos el DVD para cargar la ISO desde la sección Hardware. Una vez iniciada la MV instalaremos el qemu-ga-x86_64.msi de la carpeta guest-agent
Una vez realizado el paso A o el B, adicionalmente, marcamos desde Opciones -> QEMU Guest Agent -> EDITAR
Una vez realizado todo este proceso veremos que en el resumen de la máquina virtual ya no se informa de que carecemos del Guest Agent
Como organizar y programar los backups
Los backups se almacenan en los discos llamados «directory», los mismos que dejan almacenar las ISOs. Se puede crear un backup de forma manual así como recuperarlo cuando desees. Tanto al crearlo como al recuperar si tenemos varias unidades para ello nos dará la opción de elegirlas.
Podemos crear un plan automático de copias de seguridad llendo a DATACENTER -> Backup donde definiremos la política de copia de seguridad, la retención etc…
El nodo del que vamos a realizar la copia.
El lugar donde la haremos: En nuestro caso, será el disco que hemos añadido para esta función.
El día de la semana y la hora.
El tipo de copia: Podemos elegir solo ciertas máquinas virtuales o todo el sistema.
El tipo de compresión: Elegiremos entre LZO y GZIP. El primero es más rápido pero ofrece un ratio menor de compresión. También consume menos recursos del sistema.
El modo de hacer la copia: Nos permite elegir entre Stop (detiene la máquina antes de hacer la copia), Suspend (se ofrece por motivos de compatibilidad y es equivalente a Snapshot) o Snapshot (es la opción más rápida aunque comporta cierto riesgo de inconsistencia ya que copia las máquinas virtuales aunque se encuentren en ejecución).
La herramienta integrada de copias de seguridad de Proxmox VE genera siempre copias completas.
Ver la cantidad de datos escritos en los NVME o en los SSD
Todos sabemos que los discos duros SSD o los nvme tienen una vida de escrituras limitada, lo que se conoce como TBW. Para poder ver cuantos datos se han escrito en nuestros discos duros, podemos ir a nuestro nodo y abrir su consola y escribir:
<br>
apt update<br>
apt-get install smartctl<br>
Y una vez instalada la herramienta ejecutamos los comandos para ver los datos escritos en un NVME:
<br>
/usr/sbin/smartctl -A /dev/nvme0 | awk '$0~/Written/{ print strftime("%Y-%m-%d %H:%M:%S"), $3,$4,$5$6}'<br>
Que es un resumen del comando:
/usr/sbin/smartctl -A /dev/nvme0<br>
o en un SSD:
<br>
/usr/sbin/smartctl -A /dev/sda | awk '$0~/LBAs/{ printf "TBW %.1f\n", $10 * 512 / 1024^4 }'<br>
Que es un resumen del comando:
<br>
/usr/sbin/smartctl -A /dev/sda<br>
Configurar en BONDING 2 o más tarjetas de red
Supongamos que nuestro server físico tiene 2 o más tarjetas de red las cuales queremos conectar a un switch de tal modo que si una cae el server continua trabajando por la otra. Para eso partimos de una configuración básica donde tendríamos una tarjeta funcionando y otra libre como vemos en pantalla.
Lo primero es crear con la tarjeta sobrante un BOND pero sin tocar la principal para no perder el acceso a la consola si configuramos algo mal. Haremos lo siguiente: Crearemos un linux bond con la tarjeta libre, aplicaremos la configuración y probaremos si tenemos acceso a la consola por la nueva IP del bond. Por ejemplo mi servidor tiene la IP acabada en 36 y la del bond le pondré la 136.
Llegado a este punto deberíamos ya poder conectar con la consola de proxmox vía la nueva IP la 136 y veríamos esta configuración:
Ahora solo queda borrar el bridge que teníamos inicialmente, añadir la tarjeta libre al bond y elegir el algoritmo de trabajo. Una vez llegado aquí recomiendo apagar todas las VM por que no es la primera vez que aplicado esto la consola no recupera conexión por si misma y solo recupera conexión al rebootear el servidor con el botón físico.
Los algoritmos implementados son:
– Balance-rr (Round-Robin)
– Active Backup
– Balance XOR
– Broadcast
– IEEE 802.3ad
– Balance-tlb (Adaptive Transmit Load Balancing)
– Balance-alb (Adaptive Load Balancing)
Balance-rr (modo 0): se emplea un algoritmo round robin entre la cola virtual y las de los esclavos. Es algo así como: un paquete para un esclavo, otro para otro esclavo, un paquete para un esclavo, otro para el otro… etc.
Active-backup (modo 1): realmente no balancea la carga, usa sólo un esclavo y en caso de fallar, usa el siguiente disponible.
Balance-xor (modo 2): emplea una fórmula para decidir por qué interfaz esclavo (slave) sale la información: (source-MAC xor dest-MAC) mod n-slaves. Este método ofrece balanceo de carga y tolerancia a errores en caso de pérdida de una de las conexiones.
Broadcast (modo 3): se transmite todo por todas las interfaces/tarjetas. Este método no balancea la carga, pero provee tolerancia en caso de fallo en cualquiera de las interfaces.
802.3ad (modo 4): Configura una política de agregación de enlace dinámico IEEE 802.3ad. Crea grupos de agregación que comparten las mismas especificaciones de velocidad y duplex. Transmite y recibe en todos los esclavos en el agregador activo.
Balance-tlb (modo 5): balancea la carga de transmisión entre los esclavos dependiendo de la velocidad de estos y de la carga total. El tráfico es recibido por un esclavo, en caso de fallar otro esclavo toma su MAC y continúa recibiendo tráfico. No requiere de ninguna configuración en el switch.
Balance-alb (mode=balance o mode=6): realiza el balanceo anterior además de un balanceo también en la recepción. Este método debe modificar las MAC de los esclavos estando las tarjetas activas.
Los tipos más frecuentes son los primeros 4, aunque nuestra sugerencia es la siguiente. Si el switch del que usted dispone no es gestionable, entonces use el modo 0 (Balance-rr), y en caso de que si que lo sea, aprovéchese de la suma de velocidades con el modo 4 (IEEE 802.3ad)
Tenga en cuenta que el balanceo de carga NO le proporciona suma de velocidad, asi que si lo que quiere es suma velocidades, use el modo 4 y gestione su Switch
Así que una vez configurado todo y ya regresado el control web de la consola ya tenemos el bond funcionando. Pero el bond solo nos sirve para acceder al panel web de proxmox si queremos que las maquinas virtuales utilicen el bond tenemos que eliminar la IP del bond y crear un bridge contra ese bond y es donde pondríamos la IP original, la 36.
Con esta configuración tendríamos el bond disponible tanto para la consola proxmox como para las VMs.
