13 KiB
13 KiB
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_runnerha 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 Linux | Comando vmrun identico; portabilità VMX dei template. |
Licenza commerciale (anche per Linux); supporto guest tools invariato. EOL annunciato da Broadcom — futuro incerto. | Possibile ma rischioso a medio termine. |
| 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.
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 <vmx> |
virsh start <domain> |
vmrun stop <vmx> hard |
virsh destroy <domain> |
vmrun deleteVM |
virsh undefine <domain> --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)
- Spegnere VM su Workstation, esportare
.vmx+.vmdk. - Convertire:
qemu-img convert -O qcow2 WinBuild2025.vmdk winbuild2025.qcow2. - Iniettare driver virtio (network, storage) nel guest Windows prima
della conversione (offline injection via
virt-v2voppure boot manuale con ISOvirtio-win.isoe installazione driver). - Importare con
virt-install --import --disk path=winbuild2025.qcow2,bus=virtio --os-variant=win2k25. - Validare WinRM accessibile da host Linux (
Test-WSManequivalente conpwshopypsrp). - Spegnere, creare snapshot di base:
virsh snapshot-create-as winbuild2025-template BaseClean.
Template Linux (LinuxBuild2404)
- Esportare e convertire VMDK → qcow2 (più semplice, driver virtio già presenti).
- Importare con
virt-install --import .... - Già usa SSH + chiave: nessun cambio lato transport.
- 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/<jobid>.qcow2- Crea overlay CoW (equivalente di linked clone Workstation).
- Performance migliore se il filesystem è XFS con
reflink=1o BTRFS.
2.4 Permessi e utenti
- Utente di servizio
ci-runner(uid dedicato), membro dilibvirtekvm. - act_runner gira come
ci-runnervia 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
br0se 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.mdtabella PS7+) — su Linux si usapwsh7 o Python. - Necessità di Credential Manager con bug noti sotto SYSTEM account.
autounattend.xmlsolo per refresh del template Windows (operazione rara).- Errori #9 (snapshot con
.vmem) e #10 (getGuestIPAddressbloccante) 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:
- Decidere hypervisor (A vs B).
- Convertire template Linux (più semplice, fa da PoC).
- Convertire un template Windows e validare WinRM da Linux.
- Riscrittura tooling (idealmente in Python — vedi Idea 1).
- Migrazione storage
F:\CI\→/var/lib/ci/. - 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+journalctlper 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.mdda 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(bindinglibvirt-python) e per riusareparamiko/pypsrpcross-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-buildjobs (KVM o Workstation Linux), labellinux-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.