... | ... | @@ -3,19 +3,22 @@ |
|
|
- [Creando una nueva VM](#creando-una-nueva-vm)
|
|
|
- [1. Crear KVM vacía](#1-crear-kvm-vacía)
|
|
|
- [2. Crear VM clonando otra VM o *template*](#2-crear-vm-clonando-otra-vm-o-template)
|
|
|
- [2++. Complemento](#2-complemento)
|
|
|
- [2++. Aprovisionamiento inicial de VM clonada](#2-aprovisionamiento-inicial-de-vm-clonada)
|
|
|
- [Estrategia N° 1](#estrategia-n-1)
|
|
|
- [Estrategia N° 2](#estrategia-n-2)
|
|
|
- [Ejecutar](#ejecutar)
|
|
|
- [Reducir tamaño de disco](Procedimiento-para-reducir-un-disco)
|
|
|
- [Contenido relacionado](#contenido-relacionado)
|
|
|
|
|
|
> Pese a que su release [se encuentra pendiente](https://github.com/UdelaRInterior/ansible-role-proxmox-create-kvm/pull/12), la presente documentación se encuentra actualizada a los cambios introducidos por la `v5.0.0` del role `proxmox_create_kvm`
|
|
|
|
|
|
# Introducción
|
|
|
|
|
|
Actualmente tenemos dos vías para automatizar las creación de máquinas virtuales en Proxmox VE:
|
|
|
Actualmente tenemos dos vías de automatizar las creación de máquinas virtuales en Proxmox VE:
|
|
|
|
|
|
1) inicializar una VM "vacía", asignando recursos de *hardware* sin sistema operativo
|
|
|
2) clonar una VM o *template* preexistente con sistema operativo [compatible con nuestro flujo](Plantillas-de-máquinas-virtuales-Proxmox)
|
|
|
|
|
|
Ambos escenarios se encuentran contemplados y automatizados en el role Ansible [crear_kvm](https://github.com/UdelaRInterior/ansible-role-proxmox-create-kvm). Aún así, como apreciará un lector atento, no se trata de una automatización completa sino de la mayor aproximación posible (de momento).
|
|
|
|
|
|
El segundo caso resulta más interesante ya que permite que la ejecución continua de un *playbook* concluya en un servicio pronto para produción hospedado en una VM, pero ello dependerá de que previamente se haya tomado el trabajo de [crear el *template*](Plantillas-de-máquinas-virtuales-Proxmox#crear-un-proxmox-vm-template-compatible-con-nuestro-flujo-automatizado) necesario.
|
|
|
Ambos escenarios se encuentran contemplados y automatizados en el role Ansible [proxmox_create_kvm](https://github.com/UdelaRInterior/ansible-role-proxmox-create-kvm). Naturalemente el segundo caso es el que resulta más útil, ya que permite que la ejecución continua de un *playbook* concluya en un servicio pronto para producción hospedado en una VM. El único requisito para lograrlo, es que previamente sea haya [confeccionado una VM o *template* a ser clonada](Plantillas-de-máquinas-virtuales-Proxmox).
|
|
|
|
|
|
Aún así exploraremos ambos casos. Tener en cuenta que el primero puede resultar útil y práctico, por ejemplo, para VMs de un solo uso o para comenzar la creación de *templates*.
|
|
|
|
... | ... | @@ -26,7 +29,7 @@ Elegimos primero un nombre de dominio ya configurado en la zona correspondiente, |
|
|
|
|
|
Escogido el nombre, deberemos agregar el *FQDN* (`<kvm_nuevo>.<zona_dns>.uy`) al archivo de inventario (`hosts_stage` para *staging*, `hosts_prod` para *producción*) en el subgrupo que corresponda dentro del grupo global `virtuales_proxmox`.
|
|
|
|
|
|
La forma mas simple de confeccionar la estructura de variables de la nueva VM es inspirarse de la configuración (duplicando y modificando) de una de similares características que ya exista en el proyecto. (Si no conoces ninguna, no dudes en consultar en el chat grupal)
|
|
|
La forma más simple de confeccionar la estructura de variables de la nueva VM es inspirarse de la configuración (duplicando y modificando) de una de similares características que ya exista en el proyecto. (Si no conoces ninguna, no dudes en consultar en el chat grupal).
|
|
|
|
|
|
Elegimos entonces la VM de configuración más cercana a la que deseamos crear y duplicamos su directorio de variables desde `config/host_vars/<kvm_modelo>.<zona_dns>.uy` a `config/host_vars/<kvm_nuevo>.<zona_dns>.uy`.
|
|
|
|
... | ... | @@ -36,12 +39,12 @@ A partir de aquí, las variables a utilizar/modificar dependerá del escenario e |
|
|
|
|
|
## 1. Crear KVM vacía
|
|
|
|
|
|
- `start_after_create`: indicar que se encienda la VM luego de crearla
|
|
|
- `description`: descripción de la VM que se visualiza en el panel web Proxmox como "Nota"
|
|
|
- `ostype`: tipo de sistema operativo que se virtualizará en la VM. Opciones: l24 (Linux *kernel* <=2.4), l26 (Linux *kernel* >=2.6), wxp, w2k, w2k3, w2k8, wvista, win7, win8, solaris, other.
|
|
|
- `cores`: cantidad de núcleos de CPU
|
|
|
- `memory`: cantidad (en MB) de memoria RAM
|
|
|
- `hard_disks`: lista *yaml* que representa la colección de unidades de almacenamiento. Por cada item de la lista se deberá indicar:
|
|
|
- `pve_kvm_started_after_provision`: indicar que se encienda la VM luego de crearla
|
|
|
- `pve_kvm_description`: descripción de la VM que se visualiza en el panel web Proxmox como "Nota"
|
|
|
- `pve_kvm_ostype`: tipo de sistema operativo que se virtualizará en la VM. Opciones: l24 (Linux *kernel* <=2.4), l26 (Linux *kernel* >=2.6), wxp, w2k, w2k3, w2k8, wvista, win7, win8, solaris, other.
|
|
|
- `pve_kvm_cores`: cantidad de núcleos de CPU
|
|
|
- `pve_kvm_memory`: cantidad (en MB) de memoria RAM
|
|
|
- `pve_kvm_hard_disks`: lista *yaml* que representa la colección de unidades de almacenamiento. Por cada item de la lista se deberá indicar:
|
|
|
|
|
|
**Requeridos:**
|
|
|
- `id`: identificador de la unidad. Número entero (0 ≤ n ≤ 15)
|
... | ... | @@ -58,7 +61,7 @@ A partir de aquí, las variables a utilizar/modificar dependerá del escenario e |
|
|
- `io_thread`: hilos I/O independientes para cada unidad. (Consultar el manual Proxmox para comprender lo que implica). Solo compatible con `bus` de tipo `virtio` y `scsi`
|
|
|
- `ssd_emulation`: presentar al invitado esta unidad como un SSD.
|
|
|
|
|
|
- `net_interfaces`: lista *yaml* que representa la colección de interfaces de red. Por cada item de la lista se deberá indicar:
|
|
|
- `pve_kvm_net_interfaces`: lista *yaml* que representa la colección de interfaces de red. Por cada item de la lista se deberá indicar:
|
|
|
|
|
|
**Requeridos:**
|
|
|
- `id`: identificador de la interface en Proxmox. Por ej. `net0`, `net1`, etc.
|
... | ... | @@ -71,29 +74,37 @@ A partir de aquí, las variables a utilizar/modificar dependerá del escenario e |
|
|
- `disconnect`: simular que el "cable" de la interfece se encuentra desconectado
|
|
|
- `multiqueue`: número de CPUs virtuales que el SO invitado podrá utilizar para procesar paquetes de la interface
|
|
|
- `rate_limit`: limitar el ancho de banda de la inteface al número indicado (En MB/s)
|
|
|
- `vlan_tag`: asignar un tag VLAN a la interface
|
|
|
- `vlan_tag`: VLANID (tag) de la VLAN a utilizar en la interface
|
|
|
|
|
|
|
|
|
## 2. Crear VM clonando otra VM o *template*
|
|
|
|
|
|
En el caso que se esté clonado otra VM o *template*, las variables descritas en el apartado anterior no tendrán incidencia (a excepción de `start_after_create`). Los valores serán heredados de la VM modelo.
|
|
|
En el caso que se esté clonado otra VM o *template*, las variables relacionadas a recursos de hardware solo serán tenidas en cuenta si se establece `pve_kvm_clone_post_configure` en `true` (A excepción de `net`, `virtio`, `ide`, `sata`, `scsi` debido a limitaciones del módulo `community.general.proxmox_kvm`). Esto debido a que inicialmente una VM clonada hereda tal cual los valores de su VM modelo, pero dichos valores pueden ser actualizados por una *tasks* sucesiva si se le fue indicado con el *flag* `pve_kvm_clone_post_configure`.
|
|
|
|
|
|
|
|
|
Una vez aclarado esto, al momento de clonar las variables importantes/necesarias serán:
|
|
|
|
|
|
- `pve_kvm_started_after_provision`: indica que se encienda la VM luego de crearla. (Será necesario que se encuentre en `true` para que los *playbooks* se ejecuten en un flujo continuo)
|
|
|
- `pve_kvm_clone_from_existing`: con ella indicaremos que esta VM se creará clonando otra prexistente. Deberá indicarse en `true`
|
|
|
- `pve_kvm_clone_full`: indica el tipo de clonado a utilizar: completo (`full`) o enlazado (`linked`). De momento el módulo Ansible `community.general.proxmox_kvm` solo soporta clonado completo, por lo que este valor deberá establecerse en `true`
|
|
|
- `pve_kvm_clone_vm`: nombre de la VM a clonar. Por ej. *DebianBusterTemplate*
|
|
|
- `pve_kvm_clone_vmid`: ID de la VM a clonar. Si bien parece ser reduntante a `pve_kvm_clone_vm`, muchas veces el API Proxmox necesita de ambos valores para realizar el clonado. Como buena práctica general, indicamos siempre los dos (`pve_kvm_clone_vm` y `pve_kvm_clone_vmid`)
|
|
|
- `pve_kvm_clone_newid`: (opcional) ID a asignar a la nueva VM. Si no se especifica uno, Proxmox asignará el siguiente disponible
|
|
|
- `pve_kvm_clone_storage`: almacenamiento Proxmox donde efectivamente se alojará el disco duro de la nueva virtual. Normalmente utilizamos el predeterminado: `local-lvm`
|
|
|
- `pve_kvm_clone_format`: formato de datos interno del almacenamiento de la nueva virtual. Opciones: qcow2, raw, subvol. Normalmente utilizamos `raw`
|
|
|
- `pve_kvm_clone_target`: nodo Proxmox donde se encuentra la VM o *template* a clonar. Se permite clonar desde un nodo distinto si la `pve_kvm_clone_vm` está almacenada en un *storage* compartido del clúster
|
|
|
|
|
|
|
|
|
### 2++. Aprovisionamiento inicial de VM clonada
|
|
|
|
|
|
Así pues, para clonar las variables útiles y necesarias son:
|
|
|
En el caso de que se esté clonando un *VM template* [compatible con nuestro flujo](Plantillas-de-máquinas-virtuales-Proxmox), se deberán establecer correctamente variables adicionales.
|
|
|
|
|
|
- `start_after_create`: indicar que se encienda la VM luego de crearla. (Será necesario que se encuentre en `true` para que los *playbooks* se ejecuten en un flujo continuo)
|
|
|
- `clone_from_existing`: con ella indicaremos que esta VM se creará clonando otra prexistente. Deberá indicarse en `true`
|
|
|
- `full_clone`: indica el tipo de clonado a utilizar: completo (`full`) o enlazado (`linked`). De momento el módulo Ansible `proxmox_kvm` solo soporta clonado completo, por lo que este valor deberá establecerse en `true`
|
|
|
- `clone_vm`: nombre de la VM a clonar. Por ej. *DebianBusterTemplate*
|
|
|
- `clone_vmid`: ID de la VM a clonar. Si bien parece ser reduntante a `clone_vm`, muchas veces el API Proxmox necesita de ambos valores para realizar el clonado. Como buena práctica general, indicamos siempre los dos (`clone_vm` y `clone_vmid`)
|
|
|
- `clone_newid`: (opcional) ID a asignar a la nueva VM. Si no se especifica uno, Proxmox asignará el siguiente disponible
|
|
|
- `clone_storage`: almacenamiento Proxmox donde efectivamente se alojará el disco duro de la nueva virtual. Normalmente utilizamos el predeterminado: `local-lvm`
|
|
|
- `clone_format`: formato de datos interno del almacenamiento de la nueva virtual. Opciones: qcow2, raw, subvol. Normalmente utilizamos `raw`
|
|
|
- `clone_target`: nodo Proxmox donde se encuentra la VM o *template* a clonar. Se permite clonar desde un nodo distinto si la `clone_vm` está almacenada en un *storage* compartido del clúster
|
|
|
Cuáles son estas variables adicionales, dependerá de si se emplea la antigua estrategia (que se asiste del *role* [make_vm_template_unique](https://github.com/UdelaRInterior/ansible-role-make-vm-template-unique/blob/master/defaults/main.yml)) o la nueva (y recomendada) que emplea funcionalidades de *cloud-init* nativas de Proxmox VE e implementadas en el mismo *role* [proxmox_create_kvm](https://github.com/UdelaRInterior/ansible-role-proxmox-create-kvm).
|
|
|
|
|
|
|
|
|
### 2++. Complemento
|
|
|
#### Estrategia N° 1:
|
|
|
|
|
|
En el caso de que se esté clonando un *VM template* [compatible con nuestro flujo](Plantillas-de-máquinas-virtuales-Proxmox#crear-un-proxmox-vm-template-compatible-con-nuestro-flujo-automatizado), se deberán también establecer correctamente las variables utilizadas por el role [make_vm_template_unique](https://github.com/UdelaRInterior/ansible-role-make-vm-template-unique/blob/master/defaults/main.yml) para que se lleven a cabo las configuraciones elementales al iniciar la nueva VM. Las variables fundamentales son:
|
|
|
Para que se lleven a cabo las configuraciones elementales al iniciar la nueva VM. Las variables fundamentales son:
|
|
|
|
|
|
- Para acceso provisiorio al *template* (con ellos se realizará un `ssh-copy-id`):
|
|
|
- `vm_template_host`: nombre de dominio o IP donde el *template* recién clonado y encendido se encuentre accesible
|
... | ... | @@ -114,9 +125,35 @@ En el caso de que se esté clonando un *VM template* [compatible con nuestro flu |
|
|
|
|
|
> Notar que la estructura empleada en la variable `vm_unique_net_interfaces` es absolutamente idéntica a la variable `net_interfaces` empleada por el role `crear_lxc`. Correcto, no es casualidad :wink:
|
|
|
|
|
|
#### Estrategia N° 2:
|
|
|
|
|
|
Utilizando *templates* compatibles con *cloud-init*, el mismo sistema operativo será capaz de realizar su auto-aprovisionamiento en el primer *booteo*. Podremos controlar este auto-aprovisionamiento mediante las variables relacionadas a los parámetros implementados nativamente por Proxmox VE. Además, en caso de que necesitemos recurrir a parámetros mas avanzados de *cloud-init*, podremos directamente utilizar un *snippet* personalizado mediante la variable `pve_kvm_custom_ci_snippet`.
|
|
|
|
|
|
En un caso de uso típico del proyecto `config`, serán más que suficientes los parámetros nativos. Notar lo simple que resulta con ellos, prescindir del role `make_vm_template_unique` sin resignar ninguna funcionalidad:
|
|
|
|
|
|
- `pve_kvm_clone_post_configure`: establecida en `true`, indica que una vez clonada la VM, se reconfigurarán en ellas valores asociados a recursos de hardware y configuraciones de *cloud-init*
|
|
|
- `pve_kvm_clone_grow_disks`: lista de unidades de almacenamiento ("discos") de la VM que serán redimensionadas. Por cada unidad se tienen los atributos:
|
|
|
- `disk`: identificador de la unidad (por ej. `scsi0`)
|
|
|
- `increment`: almacenamiento que se adicionará a la unidad indicada (por ej. `30G`)
|
|
|
> *cloud-init* extenderá la partición y *filesystem* automáticamente para utilizar completamente el incremento
|
|
|
- `pve_kvm_ciuser`: nombre del usuario (*nickname*) de sistema aprovisionado por *cloud-init*, habilitado a utilizar `sudo` sin contraseña.
|
|
|
- `pve_kvm_cipassword`: contraseña del usuario indicado en `pve_kvm_ciuser`
|
|
|
- `pve_kvm_sshkeys`: llave SSH a autorizada a loguearse como el usuario indicado en `pve_kvm_ciuser`. Típicamente será la llave pública del equipo donde nos encontramos ejecutando los *playbooks* (Controlador Ansible)
|
|
|
- `pve_kvm_searchdomains`: dominio de búsqueda de sistema
|
|
|
- `pve_kvm_ipconfig`: diccionario que establece las interfaces de red del sistema y su configuración (IP´s, gateway, etc.)
|
|
|
- `pve_kvm_nameservers`: lista de resolvedores DNS que el sistema empleará
|
|
|
- `pve_kvm_started_after_provision`: establecida en `true`, indica que se encienda el sistema una vez completado el aprovisionamiento. (Requerido para tener un flujo continuo de creación en nuestros *playbooks*)
|
|
|
- `pve_kvm_wait_for_ssh_connection`: establecida en `true`, indica que se pause la ejecución del *playbook* hasta que sea posible establecer conexión SSH con la VM clonada. Es decir, hasta que la VM completó su primer *booteo* y aprovisionamiento.
|
|
|
- `pve_kvm_wait_for_ssh_connection_remote_user`: nombre de usuario con el que se iniciará sesión en la nueva VM para continuar su aprovisionamiento. Generalmente se indicará el mismo usuario que en `pve_kvm_ciuser`
|
|
|
|
|
|
# Ejecutar
|
|
|
|
|
|
Con todo listo, finalmente creamos la nueva VM ejecutando el *playbook* `site.yml` de la siguiente manera:
|
|
|
Con todo listo, finalmente crearemos la nueva VM ejecutando el *playbook* `site.yml` de la siguiente manera:
|
|
|
```shell
|
|
|
ansible-playbook -i <archivo_de_inventario> --limit <kmv_nuevo>.<zona_dns>.uy site.yml
|
|
|
``` |
|
|
\ No newline at end of file |
|
|
```
|
|
|
|
|
|
## Contenido relacionado
|
|
|
|
|
|
- [Reducir tamaño de disco](Procedimiento-para-reducir-un-disco)
|
|
|
|