pbs

pve/000-hardware.md

@@ -0,0 +1,25 @@
+# Hardware ottimale
+
+## CPU
+
+Nella maggior parte degli scenari, per ambienti Proxmox si consiglia l’utilizzo di CPU con un numero inferiore di core, ma con frequenze di clock più elevate. Questo approccio risponde alle esigenze tipiche delle PMI, dove i carichi di lavoro sono spesso non paralleli e le applicazioni gestionali traggono maggior beneficio da una frequenza di clock più alta.
+
+La metrica determinante per la scelta della CPU è l’`IPC` (*Instructions Per Clock*), ovvero il numero di istruzioni che la CPU può elaborare per ogni ciclo di clock. Una CPU con un IPC elevato è in grado di completare un maggior numero di operazioni in minor tempo, risultando particolarmente efficace per applicazioni single-thread. In un cluster PVE, un IPC elevato contribuisce inoltre a mantenere basse le latenze di scrittura, migliorando le prestazioni complessive del sistema.
+
+![pve-cpu](asset/img/pve-cpu.png)
+
+## RAM
+
+In un singolo nodo che utilizza PVE con ZFS come file system, è consigliabile mantenere libero il 50% della memoria RAM dedicata a ZFS, il quale sfrutta ampiamente la cache in RAM. In un cluster composto da tre nodi con Ceph, il file system distribuito che replica le scritture tra tutti i nodi, si raccomanda la disponibilità di 1 GB di RAM per ogni TB di storage Ceph. È essenziale anche garantire una quantità adeguata di memoria RAM in modo da poter allocare le VM di un nodo guasto, assicurando la continuità operativa del cluster.
+
+## Storage
+
+Per ambienti Proxmox VE, in particolare in configurazioni iperconvergenti o con carichi di I/O intensivi, si consiglia l’utilizzo di unità SSD o NVMe. I dischi meccanici possono essere impiegati esclusivamente per operazioni non critiche dal punto di vista delle prestazioni, come i backup.
+
+La metrica fondamentale per la valutazione della durata e dell’affidabilità delle unità SSD è il `TBW` (*Terabytes Written*), che indica la quantità totale di dati che possono essere scritti su un’unità nel corso della sua vita utile.
+
+## Networking
+
+Per un singolo nodo Proxmox VE non sono previsti requisiti di rete particolari. In un cluster, invece, è consigliabile dotare ciascun nodo di almeno due interfacce di rete da 2,5 Gbps, delle quali una dedicata esclusivamente alla comunicazione interna tra i nodi.
+
+In contesti `enterprise`, si raccomanda l’adozione di schede di rete ridondate, con un minimo di quattro interfacce aggregate a coppie, preferibilmente da 10 Gbps.

pve/003-pve-initial-setup.md

@@ -190,4 +190,4 @@ systemctl disable megaclisas-statusd.service
 
 ## SMTP
 
-- Configurare l'invio della mail da interfaccia Web
+- Configurare l'invio della mail da interfaccia Web in `Datacenter > Notifications`

pve/006-performance-tweaks.md

@@ -0,0 +1,23 @@
+# Performance Tweaks
+
+> [Performance Tweaks](https://pve.proxmox.com/wiki/Performance_Tweaks)
+
+Alcuni consigli per massimizzare la performance delle VM:
+
+- Usare i driver `virtIO` per i dischi e le schede di rete
+
+Su Windows:
+
+- Disabilitare `USB tablet device`
+- Usare immagine disco RAW e non qcow2
+- Non utilizzare il driver Virtio Balloon
+
+## Disk Cache
+
+In Proxmox l’opzione `cache` definisce la politica di caching del disco virtuale, cioè come vengono gestite le operazioni di I/O tra il guest (VM), l’host Proxmox e lo storage fisico.
+
+- `cache=none`: sembra offrire le migliori prestazioni ed è l'impostazione predefinita da Proxmox 2.X.
+- `cache write back`: è una strategia di gestione della cache per le operazioni di scrittura sullo storage. Quando si utilizza questa configurazione, i dati scritti nelle VM vengono prima memorizzati nella cache e successivamente scritti in modo asincrono sul disco fisico. Questa configurazione permette una maggiore velocità nelle operazioni di scrittura, poiché le applicazioni non devono attendere che i dati siano scritti effettivamente sul disco. Nel caso di un'interruzione di corrente o un crash del sistema, ci può essere il rischio di perdita di dati non ancora scritti sul disco
+- `writethrough`: ogni operazione di scrittura viene eseguita sia sulla cache che sul disco fisico contemporaneamente. L’applicazione *riceve conferma solo dopo che i dati sono stati scritti su entrambi i livelli*. È la modalità di cache più sicura: non si possono perdere dati, ma è anche più lenta.
+- `directsync`: i dati vengono scritti sia nella cache che sul disco fisico, ma l’applicazione *riceve conferma non appena i dati sono scritti sul disco*, indipendentemente dallo stato della cache. Questo implica che la cache non è sempre aggiornata, quindi in caso di letture successive, i dati potrebbero non essere coerenti con quelli in cache
+- `unsafe`: scrive i dati solo nella cache e posticipa la scrittura sul disco, senza alcuna garanzia di sincronizzazione in caso di interruzioni. Prestazioni massime, poiché le scritture sono estremamente veloci, ma con un rischio elevatissimo di perdita dati in caso di interruzioni o crash del sistema

pve/007-vm.md

@@ -0,0 +1,10 @@
+# Creazione di una VM
+
+## Riferimenti
+
+- [Virtual Machines Settings](https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines)
+- [VM Templates and Clones](https://pve.proxmox.com/wiki/VM_Templates_and_Clones)
+- [Dynamic Memory Management](https://pve.proxmox.com/wiki/Dynamic_Memory_Management)
+- [Qemu guest agent](https://pve.proxmox.com/wiki/Qemu-guest-agent)
+- [Cloud-Init](https://pve.proxmox.com/wiki/Cloud-Init_FAQ)
+- [Cloud-Init Support](https://pve.proxmox.com/wiki/Cloud-Init_Support)

pve/008-container-lxc.md

@@ -0,0 +1,12 @@
+# Container LXC
+
+![container-lxc](asset/img/container-lxc.png)
+
+Durante la creazione di un container LXC, é buona prassi lasciare abilitate le seguenti opzioni:
+
+- `Unprivileged container`: quando l'opzione è disattivata, si perde l'isolamento tra il container e l'host, consentendo al container di operare con privilegi di root
+- `Nesting`: consente di eseguire container Docker all'interno di un container LXC
+
+## Riferimenti
+
+- [Linux Container](https://pve.proxmox.com/wiki/Linux_Container)

pve/009-user-management.md

@@ -0,0 +1,17 @@
+# Utenti e ruoli
+
+In `Datacenter > Permissions` è possibile gestire la creazione di utenti e l’assegnazione di ruoli specifici all’interno del cluster.
+
+Per aggiungere un nuovo utente con accesso in sola lettura, è necessario recarsi in `Datacenter > Permissions > Users > Add`. Nella sezione `Permissions`, è possibile configurare i permessi dell’utente in modo che abbia accesso all’intero cluster (`/`) con il ruolo `PVEAuditor`. Tale ruolo consente all’utente di visualizzare esclusivamente le risorse del cluster, senza possibilità di modifica.
+
+![pve-auditor](asset/img/pve-auditor.png)
+
+## API Token
+
+Gli `API Token` permettono di gestire l’accesso al cluster o a specifiche risorse da parte di applicazioni esterne. Durante la creazione di un API Token, è fondamentale attivare l’opzione `Privilege Separation`. Questa impostazione garantisce che i permessi associati al token non corrispondano automaticamente a quelli dell’utente proprietario (ad esempio, l’utente root), ma possano essere definiti in modo granulare.
+
+![privilege-separation](asset/img/privilege-separation.png)
+
+## Riferimenti
+
+- [User Management](https://pve.proxmox.com/wiki/User_Management)

pve/010-storage.md

@@ -0,0 +1,6 @@
+# Storage
+
+## Riferimenti
+
+- [Storage](https://pve.proxmox.com/wiki/Storage)
+- [ZFS on Linux](https://pve.proxmox.com/wiki/ZFS_on_Linux)

pve/011-backup-restore.md

@@ -0,0 +1,5 @@
+# Backup e restore
+
+## Riferimenti
+
+- [Backup and Restore](https://pve.proxmox.com/wiki/Backup_and_Restore)

pve/012-pbs.md

@@ -0,0 +1,5 @@
+# Proxmox Backup Server
+
+## Riferimenti
+
+- [Proxmox Backup documentation](https://pbs.proxmox.com/docs/)

winserver/024-migration.md

@@ -0,0 +1,136 @@
+# Migrazione AD
+
+## Da WS2016 a WS2025
+
+### Struttura esistente
+
+- DC2016 WS 2016 Standard, detentore dei ruoli FSMO con indirizzo IP 10.0.2.10
+
+```cmd
+C:\Users\Administrator>netdom query fsmo
+Schema master               DC2016.domain.lab
+Domain naming master        DC2016.domain.lab
+PDC                         DC2016.domain.lab
+RID pool manager            DC2016.domain.lab
+Infrastructure master       DC2016.domain.lab
+The command completed successfully.
+```
+
+- DC02 WS 2016 Standard, con indirizzo IP 10.0.2.11
+- Client W11 a dominio
+
+```cmd
+C:\Users\dale>echo %logonserver%
+\\DC2016
+```
+
+- Utente `dale`
+- Dominio: `domain.lab`
+
+- Il DC2016 sará sostituito da un nuovo server DC03 con WS 2025, perché ormai obsoleto
+
+### Configurazione WS2025
+
+- Impostare indirizzo IP statico 10.0.2.12
+- Impostare come server DNS il DC2016
+- Eseguire il join nel dominio esitente
+- Aggiungere su DC03, che per ora risulta essere una semplice macchina membro del dominio, il ruolo `Active Directory Domain Services`
+- Promuovere DC03 a domain controller del dominio esistente `domain.lab`. La procedura é la medesima di quella per aggiungere un secondo DC a un dominio giá esistente
+
+> Nel caso si riscontrasse l'errore `Unable to verify whether schema master has completed a replication cycle after last reboot. Exception: Unavailable Critical Extension` durante la promozione del nuovo DC, basta eseguire il seguente comando sul domain controller principale `repadmin /syncall /AdeP` e riavviare il wizard
+
+- Modificare i server DNS sui DC nel seguente modo
+
+```txt
+
+## DC2016
+DNS primario: server stesso
+DNS secondario: DC02
+Altri DNS: DC03
+
+## DC02
+DNS primario: server stesso
+DNS secondario: DC2016
+Altri DNS: DC03
+
+## DC03
+DNS primario: server stesso
+DNS secondario: DC2016
+Altri DNS: DC02
+```
+
+### Migrazione dei ruoli FSMO
+
+- Dal DC2016, aprire `dsa.msc`, cliccare col tasto DX sul dominio `domain.lab`, quindi `Change Domain Controller`
+
+![change-dc](asset/img/change-dc.png)
+
+- Selezionare DC03 e cliccare OK
+- Ora é come se fossimo sul DC03. Cliccare col tasto DX sul dominio `domain.lab`, quindi `Operations Masters`
+- Cliccare su `Change` per trasferire i ruoli `RID`, `PDC` e `Infrastructure` da DC2016 a DC03
+
+![change-roles-schema](asset/img/change-roles-schema.png)
+
+- Ora mancano solo i ruoli `Schema Master` e `Domain naming Master` da spostare sul DC03
+
+```cmd
+C:\Users\Administrator>netdom query fsmo
+Schema master               DC2016.domain.lab
+Domain naming master        DC2016.domain.lab
+PDC                         DC03.domain.lab
+RID pool manager            DC03.domain.lab
+Infrastructure master       DC03.domain.lab
+The command completed successfully.
+```
+
+- Da `Active Directory Domain and Trusts`, cliccare col tasto DX su `Active Directory Domain and Trusts` e selezionare `Operations Masters`
+- Cliccare su `Change` per migrare il ruolo di `Domain naming Master` dal DC2016 al DC03
+- Per migrare lo `Schema Master`, aprire il cmd e digitare
+
+```cmd
+regsvr32 schmmgmt.dll
+```
+
+- Questo comando permette di aggiungere lo snap-in `Active Directory Schema` alla Console Root (`mmc`)
+- Aprire quindi `mmc`
+- Da `File > Add/Remove Snap-in`, aggiungere lo snap-in `Active Directory Schema`
+
+![active-directory-schema-snap-in](asset/img/active-directory-schema-snap-in.png)
+
+- Cliccare col tasto DX su `Active Directory Schema`, quindi `Change Domain Controller` ee selezionare DC03
+- Cliccare col tasto DX su `Active Directory Schema > Operations Masters` e `Change` per trasferire il ruolo di Schema Master a DC03
+- Dal DC03 possiamo verificare che tutti i ruoli siano stati migrati
+
+```cmd
+C:\Users\administrator.DOMAIN>netdom query fsmo
+Schema master               DC03.domain.lab
+Domain naming master        DC03.domain.lab
+PDC                         DC03.domain.lab
+RID pool manager            DC03.domain.lab
+Infrastructure master       DC03.domain.lab
+The command completed successfully.
+```
+
+> Nel caso di problemi nel corso della migrazione, per forzare la migrazione dei ruoli, basta eseguire sul DC2016 il seguente comando, dopo aver controllato che il server stesso sia anche il server DNS principale
+
+![force-roles-migration](asset/img/force-roles-migration.png)
+
+- Riavviare DC03
+- Sul client, impostare come DNS principale DC03
+- Riavvviare il client e verificare che il login avvenga correttamente
+- Verificare il logon server col comando:
+
+```cmd
+C:\Users\dale>echo %logonserver%
+\\DC03
+```
+
+> Ora é consigliato spegnere il vecchio DC per qualche tempo, non piú di 180 giorni e verificare che sia tutto a posto. Successivamente, procedere col demote
+
+### Demote WS2016
+
+- Dopo esserci assicurati che la migrazione sia avvenuta con successo, procedere col demote DC obsoleto
+- Da DC03, rimuovere i DNS secondari
+- Da DC2016, eseguire la procedure di [demote](./011-dc-demote.md). Pulire anche i record DNS
+- Togliere la macchina dal dominio e procedere con l'archiviazione
+- La medesima procedura, in questo laboratorio, puó essere fatta con DC02