# Idea 2 — Adattare il sistema a girare su host Linux (Mint) > Stato: **proposta / valutazione**. > Target host: Linux Mint (kernel ≥ 6.x, su hardware compatibile con > virtualizzazione hardware; KVM/Intel VT-x presenti su i9-10900X). --- ## 1. Obiettivo Spostare l'host CI/CD da Windows 11 + VMware Workstation Pro a Linux Mint, mantenendo: - act_runner / Gitea (identici, già cross-platform — `act_runner` ha build Linux) - workflow YAML invariati - template VM Windows e Linux operative come build target - artifact layout su filesystem locale Cambia: hypervisor, transport layer di management, percorsi, eseguibili amministrativi, gestione credenziali. --- ## 2. Fattibilità ### 2.1 Bivio strategico: quale hypervisor su Linux? | Opzione | Pro | Contro | Verdetto | | ----------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------- | | **A. VMware Workstation Pro Linux** | Comando `vmrun` identico (binario `/usr/bin/vmrun`, **senza estensione `.exe`**); VMX dei template riutilizzabili 1:1 (zero conversione); guest tools invariati; dal 2024 free per uso personale e commerciale (Broadcom). | Roadmap di lungo periodo incerta dopo acquisizione Broadcom; dipendenza da binari proprietari su un OS open source. Richiede aggiornare i default hardcoded del wrapper `Resolve-VmrunPath` (`C:\Program Files (x86)\...\vmrun.exe` → `/usr/bin/vmrun`). | **Path a basso attrito** se si vuole minimizzare il rischio di porting (zero conversione template, zero rewrite di `_Common.psm1` oltre al path). | | **B. KVM + libvirt + QEMU** | Open source, supportato nativamente da Linux Mint; tooling solido (`virsh`, `virt-install`, `virt-clone`); cloud-init friendly. | Conversione VMDK→qcow2 obbligatoria (`qemu-img convert`); riconfigurare guest Windows (driver virtio); riscrivere completamente lo strato vmrun. | **Raccomandata** per il lungo periodo. | | C. VirtualBox | Cross-platform, simile a Workstation. | Performance inferiore a KVM; snapshot meno robusti; meno usato in CI. | Sconsigliata. | | D. Proxmox VE | UI di management, API REST. | È un OS dedicato, non gira "sopra" Linux Mint. | Vedi Idea 3 (è simile a ESXi). | **Le sezioni seguenti assumono Opzione B (KVM)** salvo dove indicato — è lo scenario di porting più impegnativo e quindi quello da pianificare in dettaglio. Se si sceglie A (Workstation Pro su Linux), la maggior parte del tooling resta invariato: cambiano solo path (`F:\CI\` → `/var/lib/ci/`), service manager (Windows Service → systemd), credential store e shell (PS 5.1 → `pwsh` 7 o Python — vedi Idea 1). ### 2.2 Mappa di adattamento (assumendo Idea 1 già completata o in corso) | Componente attuale | Equivalente Linux + KVM | | ------------------------------------------------------ | ------------------------------------------------------------------ | | `vmrun clone -snapshot=BaseClean ... linked` | `virsh snapshot-create` + `virt-clone --reflink` (qcow2 CoW) | | `vmrun start ` | `virsh start ` | | `vmrun stop hard` | `virsh destroy ` | | `vmrun deleteVM` | `virsh undefine --remove-all-storage` | | File `.vmx` | Domain XML libvirt (definizione VM) | | `WinBuild2025.vmdk` | `winbuild2025.qcow2` (base) + overlay qcow2 per ogni clone | | `F:\CI\BuildVMs\` | `/var/lib/ci/build-vms/` (o pool storage libvirt dedicato) | | `F:\CI\Artifacts\` | `/var/lib/ci/artifacts/` | | `F:\CI\Templates\` | `/var/lib/ci/templates/` | | `F:\CI\keys\ci_linux` | `/etc/ci/keys/ci_linux` (perms `600`, owner `ci-runner`) | | Credential Manager `BuildVMGuest` | `secret-tool` (libsecret/GNOME Keyring) o file `.env` cifrato (`age`/`sops`) | | WinRM HTTPS verso guest Windows | Identico (lato guest non cambia nulla) | | SSH verso guest Linux | Identico | | act_runner come Windows Service | `systemd unit` `act-runner.service` | | Task Scheduler (`Register-CIScheduledTasks.ps1`) | `systemd timers` (`*.timer` + `*.service`) | | PowerShell 5.1 | PowerShell 7 (`pwsh`) o **Python** (vedi Idea 1) | | `vmnet8` (NAT 192.168.79.0/24) | `default` libvirt network (NAT 192.168.122.0/24) o bridge dedicato | ### 2.3 Conversione dei template VM (lavoro una-tantum) #### Template Windows (WinBuild2025/2022) 1. Spegnere VM su Workstation, esportare `.vmx` + `.vmdk`. 2. Convertire: `qemu-img convert -O qcow2 WinBuild2025.vmdk winbuild2025.qcow2`. 3. Iniettare driver **virtio** (network, storage) nel guest Windows **prima** della conversione (offline injection via `virt-v2v` oppure boot manuale con ISO `virtio-win.iso` e installazione driver). 4. Importare con `virt-install --import --disk path=winbuild2025.qcow2,bus=virtio --os-variant=win2k25`. 5. Validare WinRM accessibile da host Linux (`Test-WSMan` equivalente con `pwsh` o `pypsrp`). 6. Spegnere, creare snapshot di base: `virsh snapshot-create-as winbuild2025-template BaseClean`. #### Template Linux (LinuxBuild2404) 1. Esportare e convertire VMDK → qcow2 (più semplice, driver virtio già presenti). 2. Importare con `virt-install --import ...`. 3. Già usa SSH + chiave: nessun cambio lato transport. 4. Snapshot `BaseClean-Linux`. #### Linked clone su KVM - `qemu-img create -f qcow2 -b /var/lib/ci/templates/winbuild2025.qcow2 -F qcow2 /var/lib/ci/build-vms/.qcow2` - Crea overlay CoW (equivalente di linked clone Workstation). - Performance migliore se il filesystem è XFS con `reflink=1` o BTRFS. ### 2.4 Permessi e utenti - Utente di servizio `ci-runner` (uid dedicato), membro di `libvirt` e `kvm`. - act_runner gira come `ci-runner` via systemd (`User=ci-runner`). - Sudoers limitati per operazioni privilegiate (es. `virsh net-start`). - Storage pool libvirt con ownership corretta (`/var/lib/ci`). ### 2.5 Networking - Bridge `br0` se serve raggiungibilità diretta dei guest dal host Gitea remoto, oppure NAT (default libvirt) + DHCP statico via libvirt dnsmasq se Gitea sta sulla stessa LAN. - Replicare la convenzione "1 IP per job concorrente" già in uso. ### 2.6 Rischi specifici | Rischio | Severità | Mitigazione | | --------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------- | | Guest Windows non parte dopo conversione (driver virtio mancanti) | Alta | Iniezione driver prima della conversione, oppure boot in safe mode + install. | | Performance I/O dei clone qcow2 inferiore a VMware linked clone in alcuni scenari | Media | Filesystem CoW (BTRFS / XFS reflink) + cache=none + aio=native su disco. | | `vmrun` workflow / convenzioni codificate in `AGENTS.md` errori #9 #10 non più applicabili | Bassa | Documentare nuovo set di "errori frequenti KVM" (es. virtio drivers, SELinux). | | Linux Mint kernel non sempre allineato al supporto VMware Workstation se si sceglie A | Media | Solo se si va opzione A: vincolarsi a kernel LTS testato. | | Burn-in concorrente saturazione I/O diversa su qcow2 vs VMDK | Media | Ripetere `Test-CapacityBurnIn` su nuovo host prima del go-live. | | WinRM HTTPS da host Linux verso guest Windows ha cipher mismatch occasionali | Bassa | Usare `pypsrp` con `auth='credssp'` o `auth='negotiate'`; testato in lab. | | Conversione VMDK + sysprep del Windows template può rompere attivazione / licenza | Media | Validare licenza Windows e tooling unattended con la nuova HW signature. | ### 2.7 Vincoli che spariscono / che restano **Spariscono**: - Limitazioni PS 5.1 (`AGENTS.md` tabella PS7+) — su Linux si usa `pwsh` 7 o Python. - Necessità di Credential Manager con bug noti sotto SYSTEM account. - `autounattend.xml` solo per refresh del template Windows (operazione rara). - Errori #9 (snapshot con `.vmem`) e #10 (`getGuestIPAddress` bloccante) sono specifici di vmrun — non più applicabili. **Restano / si trasformano**: - Necessità di gestire snapshot in stato "powered off". - IP collision per machine-id identico nei clone Linux (#11): identico comportamento sotto KVM con dnsmasq DHCP. - Errore #12 (stderr nativa + `$ErrorActionPreference='Stop'`) sparisce se si esce da PowerShell, altrimenti resta. --- ## 3. Stima volumi / sforzo (relativa) | Area | Indicatori dimensione | Complessità | | ------------------------------------------------------------------- | ------------------------------- | ----------- | | Conversione template Windows → qcow2 + virtio | 2 VM (2025, 2022) | Alta | | Conversione template Linux → qcow2 | 1 VM | Bassa | | Riscrittura `_Common.psm1` → wrapper `virsh`/`libvirt` | ~300 righe | Media | | Riscrittura `_Transport.psm1` (WinRM) | ~240 righe | Bassa | | Adattamento `New-BuildVM` / `Remove-BuildVM` / `Invoke-CIJob` | ~2.000 righe | Media | | Riscrittura `Setup-Host.ps1` → script bash + systemd | ~400 righe | Media | | `Register-CIScheduledTasks.ps1` → systemd `.timer` units | 6 task → 6 timer | Bassa | | Adattamento workflow YAML (path Windows → POSIX) | 5 file | Bassa | | Documentazione (HOST-SETUP.md, AGENTS.md, BEST-PRACTICES.md) | ~5 file md | Media | | Validazione e2e: smoke + section 3.3 + capacity burn-in | piano test esistente | Alta | Sequenza obbligata: 1. Decidere hypervisor (A vs B). 2. Convertire template Linux (più semplice, fa da PoC). 3. Convertire un template Windows e validare WinRM da Linux. 4. Riscrittura tooling (idealmente in Python — vedi Idea 1). 5. Migrazione storage `F:\CI\` → `/var/lib/ci/`. 6. Switch act_runner. --- ## 4. Pro / Contro ### Pro - Elimina i vincoli PS 5.1 (tabella in `AGENTS.md`). - Stack open source completo (no licenze VMware Workstation se si va KVM). - `systemd` + `journalctl` per service management e log centralizzati. - Filesystem CoW (BTRFS/XFS reflink) → clone disco ~istantanei, equivalente o migliore di linked clone Workstation. - Linux Mint ha buon supporto desktop per debug interattivo del runner. - Disaccoppia dal futuro incerto di VMware Workstation (Broadcom). ### Contro - Migrazione "tutta o niente" del host: non si può avere CI/CD attivo su Win e su Linux in parallelo se il template/storage layout è condiviso. - Conversione template Windows è il passaggio più rischioso (virtio, attivazione, eventuale re-provisioning toolchain). - Curva di apprendimento libvirt / virsh / domain XML. - Tutta la documentazione e `AGENTS.md` da riscrivere. - Test plan completo da rieseguire (smoke, e2e, burn-in). --- ## 5. Sinergia con altre idee - **Idea 1 (Python)**: forte prerequisito. PS 7 su Linux è possibile, ma Python è più idiomatico per `libvirt` (binding `libvirt-python`) e per riusare `paramiko` / `pypsrp` cross-platform. - **Idea 3 (ESXi)**: parzialmente alternativa. Se si va su ESXi, l'host CI resta comunque una macchina di management (può essere Linux Mint con Python + `pyVmomi`, oppure restare Windows). Il "dove gira l'host" e "dove girano le VM" si disaccoppiano. --- ## 6. Decision checklist Procedere **solo se** almeno 2 dei seguenti sono veri: - [ ] Il vincolo Windows host è un problema concreto (licenze, policy aziendale, preferenza team). - [ ] Si è disposti a investire una settimana piena di test di conversione VMDK→qcow2. - [ ] Si è già completata (o si è disposti a fare in parallelo) l'Idea 1. - [ ] Si vuole rimuovere la dipendenza commerciale da VMware Workstation. --- ## 7. Path alternativo "minimo": dual-host Se non si vuole migrare ma solo "supportare anche Linux Mint", una via meno invasiva: - Mantenere host Windows come primario. - Aggiungere un **secondo runner** Linux Mint che usa solo `linux-build` jobs (KVM o Workstation Linux), label `linux-build:host-mint`. - Workflow esistenti restano invariati; nuovi workflow possono selezionare il runner secondario per test sperimentali. - Stima: ~1/3 dello sforzo della migrazione completa, ma codebase divisa in due (PS Win + qualche script Linux ad hoc) — debito tecnico crescente. Questa via ha senso solo come **PoC temporaneo** prima di una migrazione completa.