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.

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.

Condivisione file semplice

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

• Sistema Operativo ospite: avrà un indirizzo IP compreso fra 10.0.2.0 a 10.0.2.24.

• Sistema Operativo host: raggiungibile all'indirizzo IP 10.0.2.2.

Dovrebbe essere possibile 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 Libvirt per il bridge

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

Creazione nuove VM con virt-manager

1. Creando una nuova macchina virtuale tramite virt-manager (interfaccia grafica), selezionare Rete di tipo bridge nella fase di configurazione della rete.

2. Scegliere br0 dall'elenco.

Modifica VM esistenti con virt-manager

1. Selezionare la VM desiderata in virt-manager.

2. Fare clic prima su Apri per la console e quindi sull'icona delle informazioni (i) per accedere ai dettagli hardware.

3. Selezionare l'interfaccia di rete virtuale. Cambiare il Source mode in Bridge e selezionare br0 come Source device.

Modifica VM esistenti con virsh edit

1. Per utenti avanzati è possibile modificare i parametri XML della VM con il comando da terminale:

   virsh edit [nome_della_vm]

2. Individuare la sezione interface type='network' e modificarla in interface type='bridge' assicurandosi che 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 (vedi paragrafo) assicurandosi che rispetti questo requisito.

Generazione KVM MAC casuale

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

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'utilizzo di DHCP. Seguono alcuni esempi 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 è in grado di utilizzare altri nameserver in /etc/resolv.conf per risolvere indirizzi non-libvirt.
Ad 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. Ad esempio con dhclient è possibile impostare il file dhclient.conf (/etc/dhcp/dhclient.conf oppure /etc/dhcp3/dhclient.conf su sistemi più vecchi) per avere:

send host-name "<hostname_dell_ospite>";

Avvio da rete con 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.

Virtio per prestazioni rete ottimali

Per ottenere le migliori prestazioni di rete all'interno delle macchine virtuali è fortemente raccomandato l'utilizzo dei driver para-virtualizzati Virtio. Questi driver riducono il sovraccarico di emulazione hardware e aumentano significativamente la velocità migliorando le prestazioni della rete di un fattore significativo (spesso 10x o più) e correggendo i problemi di perdita di connessione o lentezza che potevano verificarsi con le emulazioni hardware complete.

• Per ospiti Linux: i kernel Linux moderni (da Ubuntu 8.04 in poi) 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 occorre montare la ISO e installare i driver appropriati.

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 è:

  -net nic,model=virtio ...

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ù NIC, 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 utilizzando 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.
Segue quindi un esempio di configurazione tramite 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 utilizzato 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.

Ulteriori risorse

• Documento originale su wiki Ubuntu internazionate

• Sito ufficiale di Libvirt

• Sito ufficiale di QEMU

• Sito ufficiale di Netplan

CategoryVirtualizzazione