procedimiento-de-actualizacion-del-cluster-de-produccion-de-proxmox-6-a-8.md

 ## Procedimiento de Upgrade de Proxmox 6 a 8
 
-### Pasos previos
+### Consideraciones generales y pasos previos
 
 * **Primero que nada, es estrictamente necesario contar con alguien en Mdeo con disponibilidad de trasladarse hacia SeCIU en caso de que ocurra algún problema durante el upgrade** (ej.: no arranquen los nodos luego de actualizciones)
 
 * **Dar un aviso general a los usuarios de nuestros servicios acerca de tareas de mantenimiento que estaremos realizando sobre nuestros servidores durante toda la semana (upgrades de nodos)**
 
-* **Snapshots de la totlidad de los servicios**
-  - En cada uno de los nodos y para cada LXC y VM que lo permita realizar un Snapshot, de modo de poder recuperar rapidamente un estado previo de cada servicio en caso de catastrofe.
-
 * **Respaldos nocturnos de servicios críticos y que no admiten Snapshots**
   - Programar respaldos Proxmox de servicios (con detención) de acuerdo a la siguiente lista de host a respaldar:
 	- Servicios con discos NFS que **NO admiten Snapshots**
@@ -29,26 +26,13 @@
 		- Cafetin
   - **A no olvidarse de activar `backup` para los discos NFS montados en los LXC a respaldar.**
 
-* En la IAC ubicar a Botija, Guri, Redota y Guyunusa dentro del grupo del invetario `seciu_fierrosToUpgrade`.
-
-* Por precausión armar un listado de máquinas prendidas y apagadas previo a proceder con la actualización.
-
-* En cada nodo además ejecutamos playbook `previo_upgrade_paquetes_proxmox_6.4.yml`:
-
-  `ANSIBLE_STDOUT_CALLBACK=yaml ansible-playbook -i hosts_prod tools/previo_upgrade_paquetes_proxmox_6.4.yml -vv`
-
-  El cual se encargará de:
-  - Configurar repositorios de Debian externos
-  - Verificar directivas en `/etc/default/grub`
-  - Chequear que el paquete `ifupdown2` esté instalado
-  - Tomar nota de las direcciones MAC de los bridges de los nodos
-
 ### Agenda
 
-La idea es continuar con el resto del procedimiento de acuerdo a la siguiente Agenda:
+Para la realización del presente procedimiento se plantea la siguiente agenda tentativa:
 
 - Lunes
   - Extender LVM-thin de Botija y Guri
+  - Primeros pasos
   - Actualización de paquetes dentro de Proxmox 6.4 (4 nodos)
   - Downtime de servicios aproximado: 2 horas
 - Martes
@@ -58,21 +42,41 @@ La idea es continuar con el resto del procedimiento de acuerdo a la siguiente Ag
   - Upgrade Proxmox 7 a 8 (4 nodos)
   - Downtime de servicios máximo: 4 horas
 
+### Primeros pasos
+
+* **Snapshots de la totlidad de los servicios**
+  - En cada uno de los nodos y para cada LXC y VM que lo permita realizar un Snapshot, de modo de poder recuperar rapidamente un estado previo de cada servicio en caso de catastrofe.
+
+* En la IAC ubicar a Botija, Guri, Redota y Guyunusa dentro del grupo del inventario `seciu_fierrosToUpgrade`.
+
+* Por precausión armar un listado de máquinas prendidas y apagadas previo a proceder con la actualización.
+
+* En cada nodo además ejecutamos playbook `previo_upgrade_paquetes_proxmox_6.4.yml`:
+
+  `ANSIBLE_STDOUT_CALLBACK=yaml ansible-playbook -i hosts_prod tools/previo_upgrade_paquetes_proxmox_6.4.yml -vv`
+
+  El cual se encargará de:
+  - Configurar repositorios de Debian externos
+  - Verificar directivas en `/etc/default/grub`
+  - Chequear que el paquete `ifupdown2` esté instalado
+  - Tomar nota de las direcciones MAC de los bridges de los nodos
+
 ### Actualización de paquetes dentro de Proxmox 6.4
 
 - Actualizar los paquetes del sistema opertivo a la última versión disponible dentro de Buster y Proxmox 6.4
   * de a un nodo a la vez:
     - Gurí
     - Guyuusa
-    - Redota **(previamente hay que detener todo servidor que tenga discos en redota)**
+    - Redota
     - Botija
   * procediendo así:
     - **`screen`**
     - `pveversion` (determinar en este punto si habrá cambio de Kernel)
-    - si el nodo tiene cambio de Kernel (como Botija y Redota) apagamos cada una de sus virtuales (LXCs y Vms)
     - `apt update`
+    - **Sí el nodo tiene cambio de Kernel (como Botija y Redota) detener la totalidad de sus LXCs y VMs*
+    - **Si es Redota, además hay que detener todo servidor (de otros nodos) que use discos NFS**
     - `apt dist-upgrade`
-    - `reboot` (si cambió el kernel)
+    - `reboot` (en caso de cambió el kernel)
 
 - Si da problemas con el grub ir a mirar [esto](https://git.interior.edu.uy/adminsys/config/-/issues/406#note_7515)
 
@@ -111,7 +115,7 @@ La idea es continuar con el resto del procedimiento de acuerdo a la siguiente Ag
   * de a un nodo a la vez:
     - Gurí
     - Guyuusa
-    - Redota **(previamente hay que detener todo servidor que tenga discos en redota)**
+    - Redota
     - Botija
   * procediendo así:
     - **`screen`**