Chi controlla la piattaforma su cui gira la tua infrastruttura, e che cosa succede il giorno in cui decidi di andartene? TVirt© garantisce sovranità del dato e diritto a cambiare vendor.
Perché Trantor® TVirt©
Acquisizioni, repricing e piattaforme a fine vita hanno ridisegnato il mercato, e la convergenza fra VM e container ha preso due direzioni: un Kubernetes che ingloba le VM, o un hypervisor che ingloba i container. Trantor® TVirt© è la seconda forma: VM e container nello stesso modello operativo, attorno a tre valori guida: sicurezza, semplicità, affidabilità.
Cluster-nativo
Il cluster è nativo: non esistono nodi standalone, anche un singolo nodo è di fatti un cluster con un solo membro. La logica di clustering è innata dentro i server TVirt©.
Piano di management integrato nei nodi di virtualizzazione: ogni nodo è autosufficiente e la configurazione vive su uno store distribuito, con una replica locale in sola lettura su ciascun nodo.
Cluster non raggiungibile? Le VM continuano a girare, i login funzionano sulla replica e una corsia d’emergenza garantisce le operazioni essenziali sul nodo.
Engine diversi, stessa piattaforma: QEMU/KVM per le macchine virtuali, Podman per i container OCI (le App), LXC per i container di sistema (i CT).
Base operativa standard: AlmaLinux 10 su server x86 o ARM.
Engine spento: fleet ingestibile. Niente start, migrazioni o snapshot.
Ogni nodo è un peer, per VM e container: nessun centro da difendere.
Sicuro per design e di default
SELinux e confinamento per singola VM: utente non privilegiato, sandbox seccomp, etichette MCS dedicate.
UEFI, Secure Boot e TPM 2.0 dedicato garantiscono protezione da vari tipi di manomissione, grazie ai bootloader firmati digitalmente.
Cifratura dei dischi virtuali con chiavi nel keystore di nodo o su un KMS esterno; dischi di boot dei server fisici crittografati con LUKS2 con chiave sul TPM.
RBAC deny-by-default, permessi granulari e sistema anti-enumerazione: ciò che non puoi vedere è indistinguibile da ciò che non esiste.
"SUDO mode" per le operazioni distruttive e audit unico dell’intera piattaforma, append-only e tamper-evident.
Segreti write-only: mai restituiti dall’API, rotazione in un punto solo.
Installazione da ISO TVirt© e aggiornamenti come file da caricare in GUI, CLI o API, anche in siti air-gapped.
Single sign-on aziendale via OIDC/SAML/LDAP e autenticazione a più fattori (MFA).
«Alcune piattaforme concedono ogni libertà, anche quella di compromettere il sistema. Altre non ne concedono alcuna. TVirt© concede piena libertà di manovra, impedendo di compromettere la propria infrastruttura.»
Il cuore della piattaforma: le VM
Macchine virtuali
Profili hardware espliciti (Windows / Linux / legacy), firmware BIOS o UEFI, Secure Boot, cloud-init e guest agent. Console VNC con ticket monouso, snapshot (anche della RAM) e clonazione anche in pochi secondi.
Live migration
Pre-copy con auto-converge e limiti temporali espliciti; switchover con fencing sullo store: mai due esecutori dello stesso guest. Ogni fallimento fa rollback pulito, con la VM ancora attiva sul nodo d’origine.
Storage
Directory locali, NFS, CIFS/SMB e iSCSI/NVMe (sia su TCP sia su FibreChannel e RDMA), più multi-cluster Ceph gestito. Namespace portabile, scansione e adozione dei contenuti, protezione dagli overcommit. I volumi container usano gli stessi backend, via driver CSI.
Rete
Bond, VLAN e bridge manuali, con checkpoint, rollback e verifica di raggiungibilità. Inventario fabric aziendale per la derivazione automatica della configurazione di rete. Overlay VXLAN multi-nodo e trunk vNIC per i tenant. La stessa rete serve i container, IP-per-container.
Osservabilità
Metriche pensate per la contention: cpu.ready (l’analogo di %RDY), pressione PSI, latenze disco. Export Prometheus nativo, streaming live a due secondi, alert integrati. Le stesse metriche e gli stessi eventi coprono VM e container.
API-first
Contratto OpenAPI 3.1: interfaccia web e CLI sono client puri della stessa API. Dry-run ovunque, idempotenza garantita; «tvirt apply» accetta formato nativo, YAML Kubernetes e Compose, con auto-detection.
Alta disponibilità con fencing hardware: le VM ripartono automaticamente su nodi sani e i workload container vengono rischedulati dopo il fencing. Attestazioni esplicite dell’operatore per storage e nodi persi (attestLost / attestDown), ripristino d’emergenza del cluster con epoch fencing, export e import dichiarativo dell’intera configurazione in NDJSON. Nessuna distruzione automatica: i byte si cancellano solo per decisione esplicita e tracciata.
Backup integrato
Deduplica, cifratura e immutabilità per VM e container, più un checkpoint automatico della configurazione prima di ogni modifica rischiosa.
Migrazione facilitata
Importer per ESXi/vCenter e Proxmox, Docker Compose e manifest Kubernetes / OpenShift: tutto viene importato con un warning su ciò che non è supportato.
Federazione multi-cluster
Più cluster e più siti, una sola vista d’insieme per governare l’infrastruttura distribuita.
Container integrati nativamente
Una piattaforma sola per macchine virtuali, container OCI e system container LXC, nello stesso modello operativo. Compatibile con il tooling che già usi (Docker, Docker Compose, kubectl) senza essere l’ennesimo Kubernetes impacchettato. Le VM restano cittadini di prima classe: i container arrivano nello stesso posto, non in un cluster a parte.
Container OCI orchestrati
Runtime Podman: pod nativi, rootless di default. Un solo tipo di workload replicato (niente matrioska Pod / ReplicaSet / Deployment) con probe, rolling update, affinity e reschedule su guasto di nodo con fencing. I tag sono risolti a digest dal control plane: ogni rollback resta referenziabile.
System container LXC
Un tipo di risorsa distinto, con lifecycle da macchina virtuale: template, snapshot e cloni ereditati dal mondo hypervisor. Condivide scheduler, rete e storage con i workload OCI, senza forzare un’astrazione unica.
Il tuo tooling funziona già
Socket Docker Engine API con la docker CLI ufficiale riusata intonsa, Compose v2, Portainer, CI e Testcontainers; kubectl ufficiale su un profilo API documentato e versionato. La matrice di compatibilità è pubblica e testata a corpus in CI.
Un solo modello operativo
Un backup, un RBAC, una rete e un audit per VM e container. Lo "scope" è il confine multi-tenant: quote, DNS e viste API isolate. Secret cifrati a riposo e credenziali di registry distribuite dal control plane, mai per nodo in chiaro.
Immagini e registry
Immagini come risorse: digest pinnati, multi-arch, policy pinned o tracking per il rolling automatico al cambio di digest. Pull-through cache di cluster come mirror interno, sync da e verso qualunque registry con skopeo, garbage collection intelligente.
Rete e servizi
IP-per-container sulla stessa overlay delle VM (VXLAN / EVPN). Servizi di rete con VIP, load balancing L4 e DNS interno: la discovery by-name di Compose coincide col DNS. NetworkPolicy per la segregazione dei tenant.
Chi ha bisogno del 100% dell’API Kubernetes lo ottiene: cluster Kubernetes completi girano come VM su TVirt©. Il profilo API nativo è dichiarato per ciò che è: un sottoinsieme documentato dell’API Kubernetes, e ciò che non è supportato viene rifiutato con un messaggio mirato, mai perso in silenzio. Nessun lock-in, nemmeno su Kubernetes.
Panoramica tecnica: parte 1
Il cluster senza centro visto da vicino: come si governano i nodi fisici, che cosa succede quando qualcosa si rompe, e su quali fondamenta poggia tutto.
Alta affidabilità integrata nei nodi
L’HA vive sui nodi TVirt©, senza engine su VM né componenti esterni: regole standard di quorum e fencing avanzato via BMC Redfish. Al guasto di un nodo le VM ripartono sui nodi sani e i container vengono rischedulati; storage e nodi persi si dichiarano con attestazioni esplicite dell’operatore (attestLost / attestDown) e il ripristino d’emergenza usa l’epoch fencing.
I nodi fisici, gestiti dalla dashboard
Configurazione di rete, sincronizzazione dell’ora, accensione, spegnimento e riavvio dei server: tutto dalla dashboard TVirt©. I nodi si installano da ISO e si distribuiscono in massa via BMC Redfish; il collegamento agli UPS via rete esegue lo shutdown graceful di nodi e VM quando manca la corrente.
Diagnostica e punti singoli di guasto
Un sistema di diagnostica avanzato individua i problemi, e il rilevamento dei single point of failure ragiona per domini: la VM X ha un SPOF a livello di armadio rack? La configurazione vive su uno store distribuito con replica locale in sola lettura su ogni nodo: se lo store non risponde, le VM continuano a girare e la corsia d’emergenza garantisce le operazioni essenziali.
Massimali supportati (nodi per cluster, VM e vCPU per nodo) e obiettivi di ripartenza dell’HA si dichiarano per iscritto nel perimetro di fornitura, come per tutta la gamma Trantor®.
Panoramica tecnica: parte 2
Centinaia di VM, container e nodi restano governabili solo se l’organizzazione è nel prodotto: datacenter virtuali, ruoli, tag e un motore di placement che ragiona sui guasti.
Datacenter virtuali, ruoli e tag
I vDC hanno quote e risorse limitate e si nidificano con ordine gerarchico. I permessi seguono un sistema di ruoli granulare, deny-by-default, un permesso per ogni azione, unico per VM e container. I tag etichettano qualunque risorsa: è ciò che rende scalabile la gestione di centinaia di VM, container e nodi.
Placement per requisiti e preferenze
Le VM dichiarano requisiti e preferenze sui tag dei server: la VM X gira solo su nodi con ram_type=ddr5. Anche le GPU si assegnano per classe via tag, non per dispositivo specifico («almeno due GPU enterprise-medium»), così una VM o un container può ripartire su un server diverso ma compatibile; le tecnologie di condivisione come NVIDIA GRID sono supportate.
Due modelli di licenza
Si sceglie il modello che descrive meglio l’uso: numero di core fisici nel cluster, oppure numero di VM accese contemporaneamente. In entrambi i casi tutto è incluso, senza moduli a parte.
Il motore di placement tiene conto delle risorse disponibili sui nodi, delle regole di placement e di affinity/anti-affinity, e degli scenari failure-resistant: non fa partire una VM se il carico totale non sarebbe sostenibile in caso di guasto dei nodi. Le VM «sacrificabili» possono essere spente o non riavviate dopo un failure, per dare priorità a quelle che non lo sono.
Federazione
Più cluster comunicano fra loro e condividono risorse, con una sola vista d’insieme sull’infrastruttura distribuita.
Disaster recovery
Replica asincrona dei dischi verso un altro cluster: il sito secondario è pronto a ripartire senza engine esterni.
Panoramica tecnica: parte 3
Ciclo di vita, hardware virtuale, snapshot e migrazione: tutto ciò che una VM può fare, e come lo fa senza sorprese.
Ciclo di vita, snapshot e cloni
Accensione, spegnimento, pausa/ripresa e riavvio, con i tipi di spegnimento riconosciuti e distinti (crash, shutdown da dentro la VM, server down). Snapshot a freddo e a caldo di RAM, di tutti i dischi, dello stato TPM e del varstore EFI, con quiesce delle scritture e, se fallisce, fallback a una pausa di pochi millisecondi. Cloni full o linked clone immediati.
Live migration fra vendor diversi, e da Intel ad AMD
Pre-copy con auto-converge e limiti temporali espliciti; la gestione intelligente delle baseline CPU garantisce la massima granularità e performance anche fra server di vendor diversi o fra Intel e AMD. Lo switchover passa dal fencing sullo store — mai due esecutori dello stesso guest — e ogni fallimento fa rollback pulito. I dischi migrano a caldo verso un altro storage.
Template e TVirt© QuickDeploy
I template creano VM in pochi secondi; QuickDeploy usa cloud-init su Linux e sysprep/cloudbase-init su Windows per la configurazione automatica e il deploy massivo.
Panoramica tecnica: parte 4
La rete come servizio del cluster, e i due layer di compatibilità che fanno funzionare da subito gli strumenti che già usi.
Dai bridge fisici al fabric
Le VM si collegano con bridge fisici verso la rete esterna o con reti overlay isolate dentro TVirt©, con supporto alle schede SR-IOV. La configurazione dei nodi si deriva dal fabric aziendale: descrivi come sono configurati gli switch e come i nodi vi sono collegati fisicamente, e TVirt© genera la configurazione di rete tenendo conto di VLAN, LACP e MLAG. L’IPAM integrato assegna gli indirizzi a VM e container; il firewalling avanzato protegge VM, container e nodi.
Container: App, CT e build
Le App girano su Podman, i CT su LXC, e la piattaforma sa creare immagini OCI e template rootfs e fare build di container OCI. «tvirt apply» accetta formato nativo, YAML Kubernetes e Compose con auto-detection.
Servizi di rete erogati dal cluster
DHCP per VM e container
DNS autoritativo
Load balancer e reverse proxy
Gateway con NAT e rotte statiche
NTP, in relay verso altri server o sul clock locale
VPN WireGuard e OpenVPN
TVirt© VMWCompat
Layer di compatibilità con le API VMware vSphere: script esistenti, playbook Ansible e Terraform, govc e PowerCLI continuano a funzionare, puntati su TVirt©.
TVirt© KubeCompat
Layer di compatibilità con le API Kubernetes: kubectl, script, Ansible e Terraform parlano con il cluster come se fosse Kubernetes.
Panoramica tecnica: parte 5
La protezione dei dati, la memoria che resta cifrata anche in esecuzione, e i prodotti della gamma che si agganciano a TVirt©.
Backup nativo, e quello che già usi
Backup full e incrementali con scheduling dei job, nativi per VM e container, con deduplica, cifratura e immutabilità; i software di backup esterni restano supportati. L’intera configurazione si esporta e reimporta in modo dichiarativo in NDJSON.
Checkpoint di configurazione
Ogni modifica rischiosa è preceduta da un checkpoint automatico della configurazione, e i checkpoint si creano anche a mano: il rollback a uno stato precedente è un’operazione ordinaria, non un’emergenza.
Automazione e integrazione
Contratto OpenAPI 3.1: interfaccia web e CLI sono client puri della stessa API, con dry-run ovunque e idempotenza garantita. Chi automatizza già con gli strumenti di vSphere o Kubernetes passa dai layer VMWCompat e KubeCompat.
La memoria delle VM può restare cifrata anche in esecuzione, con AMD SEV-SNP e Intel TDX: il dato è protetto perfino da chi amministra l’host.
Trantor® TVStor
Lo storage della gamma: Ceph gestito o SAN MultiSCSI su protocolli standard (iSCSI/NVMe, NFS, SMB) che TVirt© consuma nativamente.
Trantor® Imago
L’SSO e l’MFA della console (OIDC, SAML, LDAP) possono poggiare su Imago: policy e audit degli accessi centralizzati anche per la piattaforma.
Trantor® per l’HPC
Il bundle di supercalcolo della gamma eroga le macchine di calcolo e AI proprio con TVirt©: stessa piattaforma, stesso modello operativo.
Migrazione verso TVirt© e viceversa
Il piano di migrazione della propria infrastruttura verso una nuova piattaforma si giudica dalle promesse mantenute e dall’uscita di emergenza. TVirt© documenta entrambe: ogni importazione dichiara cosa è supportato e cosa no, e anche migrare via da TVirt© è documentato e possibile grazie ai formati e agli standard open adottati.
Le tue «VM docker», assorbite
Ogni parco macchine ha VM con sopra Docker Compose, fuori da ogni policy: senza backup a livello applicativo, non monitorate, invisibili all’audit. TVirt© le porta dentro senza toccare i tuoi file: socket Docker-compatibile, importer Compose fedele alla specifica e report di conversione che dichiara cosa passa e cosa no. Gli stack Swarm entrano dalla stessa porta.
Lift & drain da OpenShift e Kubernetes
Prima il lift: il cluster si sposta su VM TVirt©, senza toccare i workload. Poi il drain, ai tuoi tempi: importer per i manifest con validazione strict e defaulting fedele, mai drop silenziosi, conversione di DeploymentConfig e ImageStream, e «tvirt assess-migration», che legge i namespace in sola lettura e produce il report di convertibilità: percentuale auto-convertibile, blocker, risorse legate agli operator.
Da VMware e Proxmox, senza correre rischi
TVirt© espone un’API vSphere-compatibile (SOAP e REST) verificata con govc reale: gli strumenti che già usi (govc, PowerCLI, Terraform, Ansible) creano, clonano e migrano VM su TVirt© durante la transizione. Le VM arrivano con la conversione V2V, i registry con skopeo sync a digest preservati. Un pezzo alla volta, mai tutto insieme, per diminuire i rischi.
| ASSET | FORMATO / PROTOCOLLO | PROCEDURA DI USCITA |
|---|---|---|
| Dischi e macchine virtuali | QCOW2 · dominio QEMU/KVM, virtio, guest agent | Attacco diretto a qualunque KVM |
| Immagini container | Registry OCI, digest pinnati | Sync verso qualunque registry: i digest restano validi |
| Workload container | Risorse dichiarative native | Esportazione verso Docker Compose e Kubernetes, con perdita dichiarata nel report |
| Volumi | Ceph, driver CSI standard | Stessi formati e procedure per VM e container |
| Rete | VXLAN / EVPN / BGP | Interoperabile con apparati di terze parti |
| Stato e configurazione | JSON5 dichiarativo | Versionabile nel Git del cliente, non solo nello store TVirt© |
«E se TVirt© diventasse il prossimo lock-in?» La risposta non è una promessa: è strutturale. Formati aperti ovunque vivano i tuoi dati, export che non richiede il consenso del vendor e, dove il progetto lo richiede, impegni contrattuali su continuità e licenze perpetue (tramite escrow).
TVirt© e le alternative
TVirt© e le alternative: parte 1
Ventidue alternative in quattro parti: nessuna paura del confronto. In questa prima parte trovi gli hypervisor storici e i loro eredi diretti. Ogni riga con i vantaggi dell’alternativa e ciò che ogni cliente dovrebbe chiedersi.
| PIATTAFORMA | CONTROL PLANE | MODELLO DI LICENZA | DA CONSIDERARE |
|---|---|---|---|
Trantor® TVirt© Trantor® · Italia | Cluster simmetrico, VM e container: ogni nodo autosufficiente, store distribuito, nessun SPOF | Licenza unica per core fisico: tutto incluso, uso e assistenza, multipli di 12 mesi | Sicurezza, sovranità e costi prevedibili; gira su x86 e su ARM; supporto diretto del team di sviluppo; VDI nativa con VDesk |
VMware vSphere / VCF Broadcom · extra-UE | vCenter come punto di gestione centrale | Solo subscription, per core, a bundle (VCF / VVF), con minimi per CPU | Il riferimento storico del mercato, con listino e canale rivisti in profondità dopo Broadcom; TVirt© ne espone un’API compatibile: la transizione parte dai tool che già usi |
Hyper-V · Azure Local Microsoft · extra-UE | Hyper-V in Windows Server; evoluzione Azure Local, gestita via Azure Arc | Incluso in Windows Server (Datacenter per VM illimitate); Azure Local a canone mensile per core, via Azure | L’alternativa ovvia negli shop Microsoft, ma la direzione è il cloud del vendor: gestione, licenza e fatturazione passano da Azure |
XenServer Cloud SW Group · extra-UE | Hypervisor Xen, gestione XenCenter | Premium per socket o in bundle Citrix; attivazione solo via Citrix Cloud | Rilanciato da CSG ma ritirato nel perimetro Citrix/VDI; la licenza ancorata al cloud del vendor pesa negli ambienti isolati, e chi lo ha ancora ha davanti la stessa scelta dei profughi VMware |
XCP-ng Vates · Francia (UE) | Hypervisor Xen; gestione via appliance Xen Orchestra | Open source, supporto per host (Vates) | L’altra via europea, con Veeam in arrivo e un modello commerciale pulito; ma niente container nel modello, storage su DRBD e competenze Xen sempre più rare |
Proxmox VE Proxmox · Austria (UE) | Senza engine: quorum Corosync e file system pmxcfs | Open source (AGPL); supporto in abbonamento a livelli | Massima libertà, ma hardening e binari operativi restano a carico tuo e il supporto container OCI è sperimentale; TVirt© porta di serie baseline verificata e orchestrazione container |
oVirt · RHV · OLVM Comunità · Oracle (extra-UE) | Engine centrale (Java + PostgreSQL) sopra gli host | oVirt gratuito; RHV a fine supporto (08/2026); OLVM in subscription Oracle | Linea a manutenzione ridotta; l’erede Red Hat è OpenShift. I fork russi (zVirt, Brest) ne ereditano i limiti, con giurisdizioni in più |
Il confronto utile non è la lista delle funzioni: è il modello. Chi controlla il codice e in quale giurisdizione, come si paga l’anno tre, quanto costa uscire. Vale per ogni riga di questa parte, e per le sedici delle tre seguenti.
TVirt© e le alternative: parte 2
Sei strade che condividono una premessa: prima si adotta Kubernetes o OpenStack, e poi si virtualizza.
| PIATTAFORMA | CONTROL PLANE | MODELLO DI LICENZA | DA CONSIDERARE |
|---|---|---|---|
OpenShift Virtualization Red Hat / KubeVirt · extra-UE | VM come risorse Kubernetes, control plane dedicato; da gennaio 2025 anche la SKU solo-VM (Virtualization Engine), per coppia di socket | Subscription Red Hat, per core | Naturale se OpenShift è già in casa; per la sola virtualizzazione è un salto di complessità, e il lift & drain di TVirt© copre la transizione |
OpenStack OpenInfra Foundation | Suite di servizi coordinati (Nova, Neutron, Cinder, ...) | Open source; distribuzioni e supporto commerciali a parte | Pensato per cloud privati su larga scala e team dedicati, impacchettato anche da Mirantis; TVirt© è un prodotto unico, con una sola API |
Apache CloudStack Apache · ShapeBlue (UK) | Orchestratore IaaS open multi-hypervisor, con management server | Open source (Apache); supporto commerciale di terze parti | Maturo e amato dai provider: multi-tenancy e metering nativi, più semplice di OpenStack; per l’enterprise resta un cloud da comporre e operare |
Virtuozzo VHI Svizzera · extra-UE | OpenStack impacchettato chiavi in mano, con nodi controller | Perpetua o subscription; pensato per i service provider | Il turnkey OpenStack per hoster e CSP: billing e white-label nativi; per l’enterprise resta OpenStack, e lo storage è proprietario |
OpenNebula Spagna · UE | Orchestratore cloud open su KVM, control plane leggero | Open source + supporto enterprise (OpenNebula Systems) | Vent’anni di storia e bandiera del cloud sovrano europeo (IPCEI, AI factory); più orchestratore che piattaforma: storage e container restano da comporre |
SUSE Virtualization SUSE · UE | HCI su Kubernetes: KVM via KubeVirt, storage Longhorn (Harvester) | Subscription SUSE, integrata con Rancher | Europea, open e in crescita; ma sotto c’è Kubernetes (RKE2, Longhorn) anche quando la console lo maschera: un mondo in più da operare |
Sono tutte scelte legittime quando il mondo che portano con sé è già in casa: ognuna chiede di imparare il suo modo di operare, per arrivare alle VM. TVirt© fa il percorso inverso: hai le VM, e i container arrivano dove sono già loro, senza un secondo cluster multi-tenant da governare.
TVirt© e le alternative: parte 3
Qui trovi le alternative a TVirt© che come noi fanno convergere calcolo, storage e rete in un solo software. La differenza sta in chi controlla il sistema.
| PIATTAFORMA | CONTROL PLANE | MODELLO DI LICENZA | DA CONSIDERARE |
|---|---|---|---|
Nutanix AHV Nutanix · extra-UE | Distribuito sui nodi (CVM); Prism Central per la gestione avanzata | Subscription per core, a edizioni (Starter · Pro · Ultimate) | HCI solida ma ecosistema proprietario (storage AOS, hardware qualificato); TVirt© usa server e storage standard |
Arcfra AECP Singapore · SmartX · extra-UE | Stack KVM completo, console centrale AOC | Subscription annuale per core, in quattro edizioni con add-on | Il più simile per forma, con prestazioni e DR dichiarati di livello; IP e ingegneria di derivazione SmartX (Cina), uscita non documentata |
HPE VM Essentials HPE · extra-UE | KVM (HVM) gestito dalla piattaforma Morpheus | Per socket (~600 $ l’anno a listino), anche in bundle coi server HPE | La risposta dell’OEM, aggressiva sul prezzo e comoda per chi compra ProLiant; piattaforma giovane, e il baricentro resta il vendor dell’hardware |
Scale Computing extra-UE | HCI KVM integrata (HyperCore); gestione nei nodi, Fleet Manager in cloud | Subscription a livelli, per core e nodo, via partner | La semplicità come filosofia, perfetta per edge e PMI, ora anche con Veeam; profondità enterprise e presenza UE limitate |
VergeIO extra-UE | VergeOS: hypervisor, storage e rete in un solo codice («ultraconvergenza») | Per nodo, tutto incluso | Idea radicale e prezzi netti, con datacenter virtuali e snapshot immutabili; realtà giovane, forte su PMI ed education USA, ecosistema UE sottile |
Platform9 extra-UE | KVM con piano di gestione SaaS (self-hosted e air-gapped possibili) | Subscription per core | Nata da veterani VMware, esperienza curata e migrazione vJailbreak; ma il default è il control plane nel cloud del vendor, da pesare per la sovranità |
Convergere calcolo, storage e rete in un solo software è la direzione giusta: l’hardware sì, ma il controllo del cluster deve restare a chi lo possiede, non al vendor, col suo listino e il suo hardware qualificato.
TVirt© e le alternative: parte 4
Qui trovi le alternative meno conosciute e più di nicchia.
| PIATTAFORMA | CONTROL PLANE | MODELLO DI LICENZA | DA CONSIDERARE |
|---|---|---|---|
Canonical MicroCloud Canonical · UK | Cluster LXD: VM KVM e system container, con MicroCeph e OVN | Open source + supporto Ubuntu Pro | Il cugino filosofico più vicino, con VM e system container su Ceph; forte negli shop Ubuntu, ma niente orchestrazione OCI e comunità divisa dal fork Incus |
Sangfor HCI Cina · extra-UE | HCI full-stack con sicurezza di rete integrata | Commerciale; spinta aggressiva sul TCO anti-VMware | Colosso di Shenzhen con oltre 60 filiali anche in EMEA e citazioni Gartner; per PA e regolamentati UE, la giurisdizione è la domanda che precede la demo |
ZStack · H3C · Inspur Cina · extra-UE | Piattaforme cloud KVM del mercato cinese | Commerciali | Il resto del campo cinese, diffuso in Asia e nei cataloghi dell’ecosistema; per l’UE vale lo stesso metro: giurisdizione, referenze e supporto locale da verificare |
Huawei FusionCompute Huawei · Cina, extra-UE | Virtualizzazione della suite Fusion; FusionCube per l’HCI | Commerciale, legata all’ecosistema Huawei | Il peso di Huawei e una filiera completa; in UE porta con sé il contesto regolatorio e geopolitico che già conosci |
Posizionamento sintetico aggiornato a luglio 2026, su fonti pubbliche. Ogni piattaforma citata è un prodotto valido nel proprio contesto d’uso; i marchi appartengono ai rispettivi proprietari.
- 1.
«Chi controlla il codice e la roadmap, e in quale giurisdizione?»
TVirt© risponde per iscritto.
- 2.
«Oltre lo sconto di oggi: quanto mi costerà l’anno tre, tra edizioni e rinnovi?»
- 3.
«Se decidessi di lasciarvi, quanto sarà complesso migrare VM e container?»
Infrastrutture critiche
Difesa, PA e ambienti classificati: air-gapped, FIPS su RHEL 10, audit tamper-evident.
Sovranità reale
Piattaforma, roadmap e supporto in Italia: nessuna dipendenza da scelte prese oltreoceano.
Costi prevedibili
Una licenza per core con tutto incluso: il TCO si calcola e si difende in 10 minuti.
Licenza unica. Zero lock-in.
Una licenza. Tutto incluso.
Niente edizioni Standard, Advanced o Enterprise. Niente add-on da comprare a parte, niente funzioni «sbloccabili»: ogni cliente riceve lo stesso prodotto, completo. Il preventivo si legge e si difende in un audit in 10 minuti.
Libertà di uscita e di scelta
Formati e protocolli aperti: qcow2, NFS / CIFS / iSCSI, registry OCI a digest, guest agent standard
Export dichiarativo di configurazione (NDJSON) e workload (k8s / Compose), API pubblica documentata: dati e automazioni restano tuoi
Made in Italy, davvero
Progettata e sviluppata interamente in Italia. Filiera corta: chi ti supporta è chi ha scritto il codice, con un interlocutore unico per prodotto, roadmap e assistenza.
Una risposta concreta ai requisiti di sovranità tecnologica e riservatezza di difesa, pubblica amministrazione e grandi gruppi: nessuna dipendenza da decisioni di licensing prese oltreoceano, supporto e documentazione in italiano.
VDI nativa con Trantor® VDesk
Per i progetti di postazioni di lavoro virtuali, TVirt© si integra nativamente con VDesk, la piattaforma VDI della famiglia Trantor®: desktop virtuali direttamente sull’hypervisor, stessa filiera italiana e un unico interlocutore per infrastruttura e postazioni di lavoro.
Funziona con il resto dell’ecosistema
Desktop virtuali direttamente sull’hypervisor: stessa filiera italiana e un unico interlocutore per infrastruttura e postazioni di lavoro.
Lo storage della gamma, su protocolli standard che TVirt© consuma nativamente.
SSO e MFA della console su Imago: policy e audit degli accessi centralizzati.
Il bundle di supercalcolo della gamma eroga le macchine di calcolo e AI proprio con TVirt©.
Ultimo aggiornamento: 10 agosto 2026. I contenuti di questa pagina sono allineati alla brochure di quella revisione.
Vedila in azione.
Richiedi una demo guidata o un proof of concept nel tuo ambiente: on-premise, air-gapped o in laboratorio.