KoaVM
Pagine della guida

Guida · Per gli amministratori

Migrazione da altri pannelli

KoaVM sposta le VM dagli altri pannelli sui nodi KoaVM con lo stesso IP e lo stesso MAC, a freddo o quasi live (circa 10 secondi di fermo).

Le VPS di un fornitore dove non hai accesso all'hypervisor (Vultr, Hetzner, DigitalOcean, OVH, Contabo…) si importano invece da dentro, via SSH: vedi «Da un altro fornitore (via SSH)» più sotto.

Sorgenti

In Migrazione › Collega una sorgente: SolusVM 1, SolusVM 2, Virtualizor, Proxmox VE, OpenStack o qualsiasi nodo KVM/libvirt.

  • Nodi (obbligatori): gli indirizzi dei server dove girano le VM, con utente root o un utente con sudo senza password. Il pannello li legge via SSH con la sua chiave.
  • API del pannello (facoltativa): aggiunge nome host, IP e cliente di ogni VM e, dopo lo spostamento, sospende la VM nel vecchio pannello.

Aggiungi la chiave del pannello (è nella pagina Migrazione) ad authorized_keys sui nodi di origine e sui nodi KoaVM. Sui nodi KoaVM serve qemu-utils.

OpenStack

Per OpenStack serve l'API (Keystone v3) con un'application credential: creala in Horizon (Identità › Credenziali applicazione) o con openstack application credential create koavm. Con il ruolo admin il pannello vede le VM di tutti i progetti (e il progetto diventa il nome del cliente proposto); senza, solo quelle del progetto della credenziale. Se il catalogo ha più regioni, scrivi quella delle VM.

I nodi compute (SSH) sono facoltativi:

  • le VM dei nodi compute collegati si spostano come da libvirt: a freddo o quasi live, con lo stesso MAC e lo stesso IP se è in un blocco del pannello collegato al nodo di destinazione. Anche i dischi su Ceph si copiano quasi live (a freddo serve il portachiavi dell'utente Ceph sul nodo);
  • le altre VM si copiano dall'API: Nova fa un'istantanea del disco di avvio (o Cinder copia i volumi, anche quello di avvio), il pannello la scarica da Glance controllandone l'impronta e la scrive sul nodo KoaVM. «A freddo» spegne prima la VM in OpenStack (copia coerente); «quasi live» la copia accesa (coerente come dopo un'interruzione di corrente) e la lascia accesa. Le immagini, le istantanee e i volumi temporanei creati in OpenStack si tolgono alla fine.

In entrambi i casi la VM arriva su KoaVM sistemata come le VPS importate: al primo avvio cloud-init (che c'è nelle immagini per OpenStack) configura la rete con l'IP di KoaVM, che è nuovo se quello di OpenStack non è in un blocco del pannello; utenti, password, chiavi SSH e chiavi del server restano quelli di prima. Il firmware (UEFI o BIOS) si legge dall'immagine o, se manca, dal disco copiato. Con sospendi nel pannello di origine la VM viene spenta e bloccata in OpenStack (nessuno la riaccende per sbaglio). Il disco effimero dei flavor non si copia (lo dice il controllo).

Come si sposta una VM

  1. Scansiona: il pannello trova le VM, i dischi e gli IP.
  2. Per ogni VM scegli il cliente (esistente o nuovo), il nodo di destinazione e la modalità.
  3. Controlli: prima di partire il pannello verifica spazio, rete, IP e accessi; se qualcosa non va lo dice e non parte.
  4. Avvia subito o a un'ora precisa, al massimo N migrazioni insieme (in Impostazioni).

Le modalità:

  • A freddo: la VM si spegne, il disco viene copiato, la VM riparte su KoaVM. Fermo pari al tempo della copia.
  • Quasi live: il disco si copia a specchio con la VM accesa, poi un riavvio sul nodo nuovo (circa 10 secondi di fermo).

Si spostano tutti i dischi della VM; sui nodi KoaVM vanno bene storage ZFS, LVM, dir e btrfs. Una VM spenta all'origine resta spenta.

Annullare una migrazione

Nella colonna Stato, accanto all'avanzamento, c'è Annulla:

  • in coda (anche pianificata): la migrazione esce dalla coda, la VPS preparata su KoaVM sparisce e l'IP torna libero;
  • in copia: la copia si ferma e tutto torna com'era, come quando qualcosa va storto (vedi sotto).

Dal passaggio in poi (a freddo: copia finita; quasi live: il momento in cui la VM passa sul nodo nuovo) non si annulla più: il pulsante sparisce e la migrazione arriva in fondo. Una VM annullata si può migrare di nuovo. Se il cliente aveva ricevuto l'avviso, riceve anche un'email che lo spostamento è annullato.

Se qualcosa va storto

La VM di origine torna com'era e riparte; con gli IP dei fornitori l'IP torna al server di prima. Nel dettaglio della VM trovi l'errore e il registro dei passaggi.

Email ai clienti

Con le email attive (Impostazioni) il cliente riceve un avviso prima e dopo lo spostamento, con l'orario e il fermo previsto.

Da un altro fornitore (via SSH)

Per una VPS Linux di qualsiasi fornitore: il pannello entra nella VPS via SSH, copia il disco da dentro mentre la VPS resta accesa e la riaccende su un nodo KoaVM con un IP nuovo. Non serve niente dal fornitore, solo l'accesso SSH.

Cosa serve sulla VPS

  • Linux x86_64 con il sistema su una partizione ext4, xfs o btrfs (non ancora LVM, RAID software o dischi cifrati);
  • cloud-init installato (apt install cloud-init o dnf install cloud-init): al primo avvio su KoaVM configura la rete nuova;
  • i tunnel SSH permessi (AllowTcpForwarding yes, che è il valore di partenza);
  • utente root, oppure un utente con sudo senza password.

Sui nodi KoaVM serve qemu-utils (come per la migrazione) e un blocco di IP: la VPS importata prende un IP del nodo, quindi per raggiungerla da fuori il blocco deve essere di IP pubblici.

Come si fa

  1. Migrazione › Importa da un altro fornitore: indirizzo, porta e utente della VPS, poi la password (serve una volta sola per mettere la chiave del pannello in authorized_keys e non viene salvata) oppure la chiave del pannello, che aggiungi tu.
  2. Controlla: il pannello legge sistema, disco, filesystem, cloud-init e database accesi senza cambiare niente. I punti in rosso vanno sistemati sulla VPS prima di partire; il controllo dice anche quanto durerà la copia.
  3. Scegli cliente (esistente o nuovo), piano, nodo (o automatico) e nome host. Il disco della VPS nuova è grande almeno quanto quello di origine, anche se il piano ne prevede meno.
  4. Avvia l'importazione. La copia si fa in più giri: il primo copia tutto il disco con la VPS accesa, i successivi solo quello che è cambiato, l'ultimo congela i filesystem e copia le ultime modifiche, così la copia è coerente come uno snapshot. Dalla 1.10 il pannello traccia le scritture del disco mentre copia (eventi del kernel): i giri dopo il primo rileggono solo i pezzi scritti, così il congelamento dura pochi secondi anche su dischi grandi o lenti; se il tracciamento non è disponibile si rilegge tutto il disco e il congelamento dura quanto una lettura completa. Mentre il disco è congelato i programmi che scrivono aspettano; i database accesi si possono fermare durante l'ultimo giro (opzione proposta quando ce ne sono) e ripartono subito dopo.
  5. Sul nodo il pannello sistema il disco copiato (rete di prima messa da parte, cloud-init che legge la configurazione di KoaVM, righe di fstab dei dischi non copiati commentate, caricatore UEFI di riserva) e accende la VPS. Utenti, password, chiavi SSH, chiavi del server e programmi restano quelli di prima.

A importazione finita la cartella di lavoro e la chiave del pannello spariscono dalla VPS di origine, che resta accesa (o si spegne, se l'hai scelto). Le scritture fatte sulla VPS di origine dopo l'ultimo giro non arrivano su KoaVM: ferma i servizi o spegnila, poi aggiorna DNS e firewall con l'IP nuovo.

Fino all'ultimo giro l'importazione si annulla dall'elenco; se qualcosa va storto la VPS su KoaVM sparisce, l'IP torna libero e la VPS di origine resta com'era (database riaccesi compresi). Un'importazione non riuscita si riprova dallo stesso elenco.