Wiki Ubuntu-it

Indice
Partecipa
FAQ
Wiki Blog
------------------
Ubuntu-it.org
Forum
Chiedi
Chat
Cerca
Planet
  • Pagina non alterabile
  • Informazioni
  • Allegati


Attenzione! Questa è una Pagina di prova. Le informazioni riportate potrebbero essere incomplete, errate e potenzialmente pericolose. Per contribuire alla realizzazione di questa pagina consultare la discussione di riferimento.

Guida verificata con Ubuntu: 22.04 24.04 25.04 25.10

Problemi in questa pagina? Segnalali in questa discussione

Introduzione

Questa guida illustra i metodi per configurare l'accesso di una macchina virtuale KVM a una rete esterna. La configurazione predefinita per la rete virtuale è il networking in usermode (NAT), che utilizza il protocollo SLIRP e il traffico NAT viene instradato alla rete esterna attraverso l'interfaccia dell'host. Se non si necessita di accessi diretti ai servizi di rete sulla macchina virtuale dall'esterno, la configurazione predefinita è sufficiente.

Configurazione della rete

Per consentire l'accesso diretto di host esterni ai servizi sulla macchina virtuale (ad esempio, per un server web o un servizio SSH sulla VM), è necessario configurare un bridge di rete sull'host. In questo modo si rende possibile la connessione delle interfacce virtuali alla rete esterna attraverso l'interfaccia fisica, rendendo le VM simili agli host del resto della rete fisica.

Il bridging di rete non funziona quando la scheda di rete fisica (es. wlan0) è di tipo wireless. La maggior parte dei driver di dispositivi wireless non supporta il bridging diretto.

I permessi speciali per qemu-system-* tramite setcap menzionati in vecchie guide non sono più necessari né raccomandati con le moderne configurazioni di libvirt su Ubuntu 22.04. L'accesso a KVM è gestito tramite il demone libvirtd e l'appartenenza al gruppo libvirt.

I problemi di connessione con i client dopo considerevoli scambi di dati su bridge di rete, menzionati per versioni precedenti di Ubuntu (come 8.04), sono stati ampiamente risolti con le moderne implementazioni KVM/QEMU e l'uso di driver virtio.

Un bridge di rete configurato manualmente seguendo queste istruzioni potrebbe non essere sempre visibile automaticamente in virt-manager durante una sessione di gestione remota se non è correttamente integrato con le configurazioni di libvirt. Tuttavia, per la gestione locale, virt-manager rileverà i bridge configurati tramite Netplan.

Condivisione semplice di file (Usermode Networking - NAT)

L'usermode networking (NAT), abilitato di default o con l'opzione da linea di comando -net user, permette una facile condivisione di file.

Il Sistema Operativo ospite avrà un indirizzo IP compreso nella gamma che va da «10.0.2.0» a «10.0.2.24», mentre il Sistema Operativo host sarà raggiungibile all'indirizzo IP «10.0.2.2».

Perciò, si dovrebbe essere in grado di eseguire un SSH al Sistema Operativo host (al 10.0.2.2) dall'interno del Sistema Operativo ospite e quindi usare SCP per condividere i file tra i due sistemi.

Configurazione di Libvirt per usare il bridge

Una volta che il bridge br0 è attivo sull'host, è possibile configurare le macchine virtuali per utilizzarlo.

  • Creazione di nuove VM con virt-manager: Quando si crea una nuova macchina virtuale tramite virt-manager (l'interfaccia grafica), nella fase di configurazione della rete, sarà possibile selezionare l'opzione "Rete di tipo bridge" e scegliere br0 dall'elenco.
  • Modifica di VM esistenti tramite virt-manager: Selezionare la VM desiderata in virt-manager, cliccare su "Apri" per la console, poi cliccare sull'icona delle informazioni (i) per accedere ai dettagli hardware. Selezionare l'interfaccia di rete virtuale, cambiare il "Source mode" in "Bridge" e selezionare br0 come "Source device".
  • Modifica di VM esistenti tramite virsh edit: Per utenti avanzati, è possibile modificare la definizione XML della VM.

virsh edit [nome_della_vm]

Individuare la sezione <interface type='network'> e modificarla in <interface type='bridge'>, assicurandosi che la <source> punti al bridge br0:Prima:

<interface type='network'>
      <mac address='52:54:00:xx:yy:zz'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

Dopo:

<interface type='bridge'>
      <mac address='52:54:00:xx:yy:zz'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>

Assicurarsi che il primo ottetto nell'indirizzo MAC sia pari (es. 00:, 02:). Indirizzi MAC con il primo ottetto dispari (es. 01:) sono riservati a comunicazioni multicast e possono causare problemi di rete (ad esempio, le repliche ARP possono confondere altre macchine sulla rete). È una limitazione dello standard Ethernet, non un difetto di KVM. Se si modifica il MAC manualmente, è consigliabile generarlo in modo casuale assicurandosi che rispetti questo requisito.

Generazione di un KVM MAC casuale

Per generare un indirizzo MAC casuale da assegnare a una VM, assicurandosi che il primo ottetto sia pari:

printf '52:54:00:%02x:%02x:%02x\n' $[ RANDOM % 256 ] $[ RANDOM % 256 ] $[ RANDOM % 256 ]

Questo comando genererà un MAC address che inizia con 52:54:00, che è il prefisso standard per le schede di rete QEMU/KVM e assicura che il primo ottetto sia pari (52).

DNS e DHCP ospiti

Libvirt utilizza dnsmasq per fornire indirizzi IP agli ospiti configurati per l'uso di DHCP. Per consentire la risoluzione dei nomi degli ospiti dalla macchina host:

  • Se nella macchina host viene aggiunto «192.168.122.1» (l'indirizzo IP predefinito per l'host nella rete NAT di libvirt) come primo nameserver in /etc/resolv.conf, è possibile risolvere il nome degli ospiti. Dnsmasq è abbastanza intelligente da usare altri nameserver in /etc/resolv.conf per risolvere indirizzi non-libvirt.

  • Per esempio, se attualmente /etc/resolv.conf è:

    search example.com
    nameserver 10.0.0.1
  • Modificandolo può diventare:

    search example.com
    nameserver 192.168.122.1
    nameserver 10.0.0.1

    Se il nome della macchina virtuale è «hardy-amd64», dopo l'avvio è possibile fare:

    host hardy-amd64

    che dovrebbe restituire l'indirizzo IP assegnato da dnsmasq. Notare che usando ssh potrebbe essere necessario aggiungere un punto finale dopo il nome dell'host:

    ssh hardy-amd64
  • Perché tutto funzioni, l'ospite deve inviare il proprio hostname come parte della richiesta DHCP. Su molti sistemi operativi ciò avviene automaticamente. Ove ciò non avviene, è possibile configurare il client DHCP dell'ospite. Per esempio, su sistemi Linux con dhclient, si può impostare il file dhclient.conf (/etc/dhcp/dhclient.conf o /etc/dhcp3/dhclient.conf su sistemi più vecchi) per avere:

    send host-name "<hostname dell'ospite>";

A seconda della configurazione di rete dell'host (specialmente con NetworkManager o systemd-resolved), il file /etc/resolv.conf del host potrebbe essere periodicamente sovrascritto. È necessario impostare il server DHCP della rete per fornire il nome server aggiuntivo per gli host di libvirt, oppure configurare systemd-resolved (su sistemi moderni) o resolvconf per mantenere l'impostazione.

Avvio da rete usando PXE

L'avvio Preboot Execution Environment (PXE), permette alle macchine virtuali di avviarsi da una rete invece che da un disco locale o ISO.

KVM e QEMU possono emulare varie schede di rete e supportano l'avvio PXE. Per abilitare l'avvio PXE per una VM:

  1. Assicurarsi che l'emulazione della scheda di rete sia compatibile con PXE. Molti modelli moderni (e1000, virtio, rtl8139) supportano PXE.
  2. Configurare il server DHCP/PXE sulla rete. Un server DHCP sulla stessa rete del bridge br0 (o della rete NAT se configurata) deve essere configurato per fornire i file di boot PXE.

  3. Abilitare l'avvio PXE nella configurazione della VM. Tramite virt-manager, durante la creazione o la modifica di una VM, è possibile configurare l'ordine di boot e selezionare "Network boot (PXE)".

Se si modifica il file XML della VM tramite virsh edit, la sezione di boot dovrebbe includere order='network' per l'interfaccia desiderata:

<os>
      <type arch='x86_64' machine='pc-q35-6.2'>hvm</type>
      <boot dev='network'/>  <!-- Abilita l'avvio da rete -->
      <boot dev='hd'/>
    </os>

Oppure, per un controllo più granulare sull'interfaccia specifica:

<interface type='bridge'>
      <mac address='52:54:00:xx:yy:zz'/>
      <source bridge='br0'/>
      <model type='e1000'/>
      <boot order='1'/> <!-- imposta questa interfaccia come prima per il boot -->
    </interface>
    <interface type='bridge'>
      ...
      <boot order='2'/>
    </interface>

L'elenco dei file ROM di Etherboot per specifici modelli di schede di rete (pxe-i82551.bin, ecc.) è una pratica più vecchia, spesso associata a QEMU standalone. Con libvirt, l'avvio PXE è gestito più ad alto livello e non richiede la manipolazione manuale di questi file ROM nella maggior parte dei casi. libvirt si occupa dell'integrazione con il firmware virtuale (SeaBIOS o OVMF) che gestisce l'avvio di rete.

Utilizzo di Virtio per prestazioni di rete ottimali

Per ottenere le migliori prestazioni di rete all'interno delle macchine virtuali, è fortemente raccomandato l'utilizzo dei driver paravirtualizzati Virtio. Questi driver riducono il sovraccarico di emulazione hardware e aumentano significativamente la velocità.

  • Per ospiti Linux (Ubuntu 8.04 e successive): I kernel Linux moderni (inclusi quelli di Ubuntu 8.04 e successivi) hanno i driver Virtio già integrati. L'abilitazione di Virtio nella configurazione della VM è sufficiente.

  • Per ospiti Windows: È necessario installare i "Virtio-drivers" all'interno della macchina virtuale Windows. Questi driver sono solitamente forniti come un'immagine ISO scaricabile (spesso chiamata virtio-win.iso) da siti come Fedora Koji. Dopo aver avviato la VM Windows, si deve montare questa ISO e installare i driver appropriati.

Per abilitare Virtio in una VM:

  • Tramite virt-manager: Modificare i dettagli hardware della VM, selezionare l'interfaccia di rete e cambiare il "Model device" (o "Tipo di modello") in virtio.

  • Tramite virsh edit: Modificare il file XML della VM e aggiungere o modificare la linea <model type='virtio'/> all'interno della sezione dell'interfaccia di rete:

    <interface type='bridge'>
          <mac address='52:54:00:xx:yy:zz'/>
          <source bridge='br0'/>
          <model type='virtio'/> <!-- Aggiungere o modificare questa linea -->
        </interface>

    Oppure, se si gestisce KVM da linea di comando senza libvirt, l'opzione QEMU sarebbe:

    -net nic,model=virtio ...

L'utilizzo di Virtio migliora le prestazioni della rete di un fattore significativo (spesso 10x o più) e corregge i problemi di perdita di connessione o lentezza che potevano verificarsi con le emulazioni hardware complete.

Utilizzo di NIC multipli con sottoreti/VLAN multiple

È possibile configurare più interfacce di rete virtuali per una VM, connettendo ciascuna a sottoreti o VLAN separate sull'host. Questo è utile per scenari complessi come router virtuali, firewall o host con servizi su reti isolate.

Se si necessitano più NICs, ciascuno deve essere su una sottorete separata (o VLAN). Ogni NIC viene quindi dedicato a una specifica VM o configurazione di rete sull'host KVM. La VM viene connessa alla rete usando un dispositivo bridge.

I problemi di connettività dell'host KVM menzionati in passato (come lentezza nelle autenticazioni SSH o cadute di connessione) erano spesso legati a configurazioni errate di routing multiplo o di bridge. Con Netplan e una configurazione corretta, questi problemi sono meno comuni.

Esempio di configurazione Netplan per NIC multipli con bridge:

Assumendo di avere due interfacce fisiche (enp0s31f6 e enp0s31f7) che si desidera dedicare a bridge separati (br0 e br1):

network:
  ethernets:
    enp0s31f6:
      dhcp4: no
      dhcp6: no
    enp0s31f7:
      dhcp4: no
      dhcp6: no
  bridges:
    br0:
      interfaces: [enp0s31f6]
      dhcp4: yes # Questo bridge otterrà un IP per l'host e le VM su questa rete
      parameters:
        stp: true
        forward-delay: 0
    br1:
      interfaces: [enp0s31f7]
      dhcp4: no # Questo bridge potrebbe non necessitare di un IP sull'host, solo per le VM
      parameters:
        stp: true
        forward-delay: 0
  version: 2

In questo esempio, br0 potrebbe essere usato per la rete principale dell'host e alcune VM, mentre br1 potrebbe essere dedicato esclusivamente a VM specifiche o a una sottorete isolata. Le metriche di routing predefinite di Netplan dovrebbero gestire correttamente l'instradamento se l'host necessita di accedere a entrambe le reti.

Assicurarsi che il Sistema Operativo ospite carichi i giusti driver di rete (preferibilmente Virtio).

Ulteriori risorse


CategoryHomepage CategoryNuoviDocumenti