Wiki Ubuntu-it

Indice
Partecipa
FAQ
Wiki Blog
------------------
Ubuntu-it.org
Forum
Chiedi
Chat
Cerca
Planet
  • Pagina non alterabile
  • Informazioni
  • Allegati
  • Differenze per "Virtualizzazione/Kvm/Networking"
Differenze tra le versioni 13 e 53 (in 40 versioni)
Versione 13 del 23/03/2010 12.45.39
Dimensione: 15671
Autore: FabioMarconi
Commento: tolto le pulci
Versione 53 del 24/10/2025 09.46.09
Dimensione: 13575
Autore: jeremie2
Commento: importato da ivantu/Virtualizzazione/Kvm/Networking
Le cancellazioni sono segnalate in questo modo. Le aggiunte sono segnalate in questo modo.
Linea 1: Linea 1:
## page was renamed from FabioMarconi/prove6/Configurazione della rete e bridging
##title KVM Networking
[[BR]]
[[Indice(depth=2 align=right)]]
#format wiki
#LANGUAGE it
<<BR>>
<<Indice(depth=2)>>
<<Informazioni(forum="http://forum.ubuntu-it.org/viewtopic.php?t=371617"; rilasci="25.10 25.04 24.04 22.04 10.04")>>

= 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.
Linea 7: Linea 13:
Esistono pochi metodi per consentire ad una macchina virtuale l'accesso ad una rete esterna. La configurazione predefinita per la rete virtuale è "usermode networking", che utilizza il protocollo SLIRP ed il traffico viene NATtato alla rete esterna per mezzo dell'interfaccia del host. Nel caso non si desiderino accessi ai servizi di rete nella macchina virtuale, saltare il passo successivo. 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.
Linea 9: Linea 15:
Per consentire l'accesso diretto di host esterni ai servizi sulla macchina virtuale è necessario configurare un bridge. In questo modo si rende possibile la connessione di interfacce virtuali alla rete esterna attraverso l'interfaccia fisica, rendendola così simile agli host del resto della rete.

'''Importante:''' Il bridging di rete non funziona quando la scheda di rete (es. eth1, ath0) è di tipo wireless (es. ipw3945), [http://www.linuxfoundation.org/en/Net:Bridge#It_doesn.27t_work_with_my_Wireless_card.21 as most wireless device drivers do not support bridging]!

'''Importante 2:''' Una rete bridged non funziona con le impostazioni predefinie. Dal rilascio del kernel 2.6.18 nel settembre 2006, è richiesto il permesso CAP_NET_ADMIN per utilizzare TUN/TAP in rete ([https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/103010 bug #103010]).

 * '''QEMU non necessita di essere suid root.''' A partire dalla versione Intrepid è possibile assegnare ai binari qemu questo permesso usando lo strumento "setcap". Innanzitutto occorre installare gli strumenti per la gestione dei permessi di Linux (`sudo apt-get install libcap2-bin`) e scegliere:
  * Metodo più sicuro (possibile solo dalla versione Lucid in poi). Ciò assegna solamente a '''specifici utenti''' la possibilità di disturbare l'intera rete. Da usarsi con cautela.
   * Assegnare a qemu il permesso '''ereditabile''' CAP_NET_ADMIN:
   {{{
sudo setcap cap_net_admin=ei /usr/bin/qemu-system-*}}}
   * Installare il modulo PAM del permesso ereditabile:
   {{{
sudo apt-get install libcap2-bin}}}
   * Consentire ad utenti specifici di avere il permesso ereditabile CAP_NET_ADMIN editando il file `/etc/security/capability.conf`:
   {{{
cap_net_admin NOME-UTENT-QUI}}}
  * Metodo meno sicuro (per le versioni precedenti a Lucid). Questo assegna a '''tutti gli utenti''' la possibilità di disturbare tutta la rete sul sistema. Da usarsi con estrema cautela.
   * Assegnare a qemu '''forzatamente''' il permesso CAP_NET_ADMIN :
   {{{
sudo setcap cap_net_admin=ep /usr/bin/qemu-system-*}}}
 * Nota che i permessi di filesystem di cui sopra verranno persi ad ogni aggiornamento di qemu, dato che l'impostazione dei permessi di filesystem non è supportata dalla gestione pacchetti di Ubuntu (vedere [https://wiki.ubuntu.com/Security/FilesystemCapabilties FilesystemCapabilities] per dettagli sugli ostacoli). Per una miglior panoramica sui permessi Linux e QEmu vedere [http://www.friedhoff.org/posixfilecaps.html quanto scritto sopra].

'''Importante 3:''' Usando il bridge di rete, dopo un considerevole volume di dati scambiati (es. durante un rsync) alcune persone stanno avendo problemi di perdita di connessione con il client. Per un host/client su Hardy o Intrepid vedere [#virtio più avanti].

'''Importante 4:''' Un bridge di rete configurato seguendo queste istruzioni non risulterà in virt-manager durante una sessione di gestione remota, vedere [https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386 bug #520386].

== Condivisione semplice di file ==
In modo predefinito, abilitando l' "usermode networking" usando l'opzione da linea di comando '-net user', il SO ospite avrà un indirizzo IP compreso nella gamma che va da 10.0.2.0 a 10.0.2.24 memtre il SO host sarà raggiungibile all'indirizzo IP 10.0.2.2.

Perciò, si dovrebbe essere in grado di eseguire un ssh al SO host (al 10.0.2.2) dall'interno del SO ospite e quindi usare scp per condividere i file tra i due sistemi

== Creazione di un bridge di rete sul host ==

Installare il pacchetto bridge-utils:
{{{
sudo apt-get install bridge-utils
{{{#!wiki important
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.<<BR>><<BR>>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`.<<BR>><<BR>>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 '''[[Virtualizzazione/Kvm|KVM]]'''/'''[[Virtualizzazione/Qemu|QEMU]]''' e l'uso di driver virtio.<<BR>><<BR>>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.
Linea 48: Linea 19:
Verranno effettuate modifiche alla configurazione di rete[[FootNote(Ciò significa che non si può usare [http://wiki.ubuntu-it.org/Hardware/DispositiviSenzaFili/NetworkManager NetworkManager] per controllare le schede di rete (eth0 per esempio). Se si utilizza [http://wiki.ubuntu-it.org/Hardware/DispositiviSenzaFili/NetworkManager NetworkManager] disabilitarlo o prevenirne il controllo sulle schede di rete. Usare per la configurazione della scheda la medesima usata per la configurazione del bridge di rete (br0 nell'esempio).)]]. Per fare ciò correttamente, bisogna innanzitutto fermare i sistemi di connessione[[FootNote(Questo è necessario, per esempio, quando si passa da DHCP ad indirizzo statico: si fermerà il client DHCP che non potrà ripartire se si avrà gia provveduto al cambio della configurazione. se invece il cambiamento avviene remotamente, occorre preparare una nuova configurazione in un file separato, quindi usare uno script per fermare i sistemi di connessione, sostituire la vecchia configurazione con la nuova e riavviarli.)]]: == 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.
Linea 50: Linea 35:
sudo invoke-rc.d networking stop 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>
Linea 52: Linea 45:

Se si è su una connessione remota, e non si riesce a fermare i sistemi di connessione, proseguite con i seguenti comandi, ed usare sudo invoke-rc.d networking restart alla fine. Se viene commesso un errore non sarà possibile il ripristino.

Per configurare un interfaccia bridge, editare /etc/network/interfaces e commentare o sostituire la esistente configurazione con ('''impostare i i valori della ''vostra'' rete'''):

{{{
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address 192.168.0.10
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0


}}}

oppure per usare DHCP:

{{{
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0

}}}

Questo creerà un interfaccia virtuale br0.

Riavviare i sistemi di connessione:

{{{
sudo /etc/init.d/networking restart
}}}

== Configurare ubuntu-vm-builder per creare ospiti bridged predefiniti ==

||Questo è sviluppato per dare l'etichetta --bridge=br0 ad ubuntu-vm-builder in Karmic.||

Le macchine virtuali sono definite in file XML; ubuntu-vm-builder, lo strumento usato per costruire VMs, si basa sul file sagoma /etc/vmbuilder/libvirt/libvirtxml.tmpl (prima di Ubuntu 8.10 /usr/share/ubuntu-vm-builder/templates/libvirt.tmpl)

Aprire questo file , e cambiare:

{{{
    <interface type='network'>
      <source network='default'/>
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'/>
Linea 119: Linea 54:
In: {{{#!wiki note
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.
}}}
Linea 121: Linea 58:
{{{ == 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>";
}}}

{{{#!wiki note
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 '''P'''reboot E'''x'''ecution '''E'''nvironment (PXE), permette alle macchine virtuali di avviarsi da una rete invece che da un disco locale o ISO.

'''KVM''' e '''[[Virtualizzazione/Qemu|QEMU]]''' possono emulare varie schede di rete e supportano l'avvio PXE. Per abilitare l'avvio PXE per una VM:

 0. Assicurarsi che l'emulazione della scheda di rete sia compatibile con PXE. Molti modelli moderni (e1000, virtio, rtl8139) supportano PXE.
 0. 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.
 0. 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>
Linea 123: Linea 113:
      <source bridge='br0'/>       ...
<boot order='2'/>
Linea 127: Linea 118:
== Generazione di un KVM MAC ==

Se si stanno gestendo ospiti tramite linea di comando, il seguente script sarà di aiuto per la generazione di indirizzi MAC casuali. Se viene restituito un errore inerente 'rl', installare il pacchetto 'randomize-lines'.
{{{
#!/bin/sh
echo -n "54:52:00"
for i in 1 2 3; do
        echo -n ":"
        for j in 1 2; do
                for k in 0 1 2 3 4 5 6 7 8 9 A B C D E F; do
                        echo $k
                done|rl|sed -n 1p
        done|while read m; do
                echo -n $m
        done
done
echo
{{{#!wiki note
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.
Linea 146: Linea 122:
== Conversione di un ospite esistente == <<Anchor(virtio)>>
== Utilizzo di Virtio per prestazioni di rete ottimali ==
Linea 148: Linea 125:
Se è già stata pecedentemente creata una VMs,è possibile consentirgli l'utilizzo dei sistemi di connessione bridged cambiando la definizione XMLI (in /etc/libvirt/qemu/) per l'interfaccia di rete, variando l'indirizzo MAC come si preferisce da:
{{{
    <interface type='network'>
      <mac address='00:11:22:33:44:55'/>
      <source network='default'/>
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 -->
Linea 154: Linea 139:
}}}
a:
{{{
    <interface type='bridge'>
      <mac address='00:11:22:33:44:55'/>
      <source bridge='br0'/>
    </interface>
}}}
'''Nota: Verificare che il primo ottetto nell'indirizzo MAC sia EVEN (es. 00:)''' dato che indirizzi MAC con ODD first-bytes (es. 01:) sono riservati a comunicazioni multicast e possono creare problemi. Per istanza, l'ospite potrà ricevere pacchetti ARP e replicare, ma le repliche confonderannole altre macchine. Non è un difetto di KVM, ma è semplicemente dovuto al modo in cui funziona ethernet.

Non è necessario riavviare libvirtd per ricaricare i cambiamenti; il modo più semplice è autenticarsi in virsh (uno strumento a linea di comando per la gestione di VMs), fermare la VM, rileggerne il file di configurazione, e riavviare la VM:

{{{
yhamon@paris:/etc/libvirt/qemu$ ls
mirror.xml networks vm2.xml
yhamon@paris:/etc/libvirt/qemu$ virsh --connect qemu:///system
Connecting to uri: qemu:///system
Welcome to virsh, the virtualization interactive terminal.

Type: 'help' for help with commands
       'quit' to quit

virsh # list
 Id Name State
----------------------------------
 10 vm2 running
 15 mirror running

virsh # shutdown mirror
Domain mirror is being shutdown

virsh # define mirror.xml
Domain mirror defined from mirror.xml

virsh # start mirror
Domain mirror started
}}} Oppure, se si gestisce KVM da linea di comando senza libvirt, l'opzione QEMU sarebbe:{{{
-net nic,model=virtio ...
Linea 193: Linea 143:
Il "mirror" VM sta ora usando sistemi di connessione bridged. 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.
Linea 195: Linea 145:
== DNS e DHCP ospiti ==
libvirt usa dnsmasq per fornire indirizzi IP ad ospiti configurati per l'uso di DHCP. Se nella macchina host, viene aggiunto 192.168.122.1 (l'indirizzo IP prestabilito per l'host in libvirt) come primo nameserver in /etc/resolv.conf, quindi è possibile risolvere il nome degli ospiti. dnsmasq è abbastanza intelligente da usare altri 'nameserver' in /etc/resolv.conf per risolvere indirizzi non-libvirt. Per esempio, attualmente /etc/resolv.conf è:{{{
search example.com
nameserver 10.0.0.1
== 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
Linea 201: Linea 180:
Cambiandolo può diventare:{{{
search example.com
nameserver 192.168.122.1
nameserver 10.0.0.1
}}}
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.
Linea 207: Linea 182:
Se, per esempio, il nome della macchina virtuale è 'hardy-amd64', dopo l'avvio, è possibile fare: {{{
$ host hardy-amd64
hardy-amd64 has address <IP address given by dnsmasq>
}}}
Assicurarsi che il Sistema Operativo ospite carichi i giusti driver di rete (preferibilmente Virtio).
Linea 212: Linea 184:
Notare che usando ssh è necessario usare '.' dopo il nome dell'host:{{{
$ ssh hardy-amd64.
}}}
= Ulteriori risorse =
Linea 216: Linea 186:
infine, perchè tutto funzioni, l'ospite deve inviare il suo hostname come parte della richiesta dhcp. Su molti sistemi operativi ciò avviene automaticamente. Ove ciò non avviene oppure è in uso dhcp3 è possibile impostare il file dhclient.conf. per esempio, su Ubuntu 6.06 LTS (Dapper), impostare /etc/dhcp3/dhclient.conf per avere:{{{
send host-name "<hostname dell'ospite>";
}}}
 * [[https://help.ubuntu.com/community/KVM/Networking|Documento originale (Community Ubuntu)]]
 * [[https://libvirt.org/|Sito ufficiale di Libvirt]]
 * [[https://qemu.org/|Sito ufficiale di QEMU]]
 * [[https://netplan.io/|Sito ufficiale di Netplan]]
Linea 220: Linea 191:
'''IMPORTANTE:''' A seconda della configurazione di rete, il file /etc/resolv.conf del host potrebbe essere periodicamente sovrascritto. é necessario quindi o impostare il server dhcp della rete per fornire il nome server aggiuntivo a libvirt per gli host di libvirt, oppure regolare di conseguenza ogni macchina.Siccome sono possibili molteplici configurazioni per macchine host, è reccomandabile vedere {{{resolvconf}}} e/o {{{man interfaces}}}.

== Avvio da rete usando PXE ==

Il corrente rilascio di Ubuntu non contiene il binario PXE. Tuttavia esiste un modo per automatizzare la creazione di questi file come parte di un pacchetto. Per poter usare boot -n, è necessario scaricare o creare le appropriate immagini ROM da [http://etherboot.org etherboot.org]

KVM e QEMU possono emulare vearie schede di rete. Quì sono elencati gli attuali file ROM.

|| 'KVM Name' ''nic,model='' |||| 'Etherboot Identification' |||| 'Etherboot Filename' |||| 'KVM filename' ||
|| i82551 |||| |||| |||| pxe-i82551.bin||
|| i82557b |||| |||| |||| pxe-i82557b.bin ||
|| i82559er |||| |||| |||| pxe-i82559er.bin ||
|| ne2k_pci (default) |||| ns8390:rtl8029 -- [10ec,8029] |||| gpxe-0.9.3-rtl8029.rom |||| pxe-ne2k_pci.bin ||
|| ne2k_isa |||| |||| |||| pxe-ne2k_isa.bin ||
|| pcnet |||| |||| |||| pxe-pcnet.bin ||
|| rtl8139 |||| |||| |||| pxe-rtl8139.bin ||
|| e1000 |||| ((e1000:e1000-0x1026 -- [8086,1026])) |||| gpxe-0.9.3-e1000-0x1026.rom |||| pxe-e1000.bin ||
|| smc91c111 |||| |||| |||| pxe-smc91c111.bin ||
|| lance |||| |||| |||| pxe-lance.bin ||
|| mcf_fec |||| |||| |||| pxe-mcf_fec.bin ||

Copiare il rispettivo file in /usr/share/kvm e/oppure /usr/share/qemu.

[[Anchor(virtio)]]
== Utilizzo di virtio per ospiti Ubuntu Hardy/Intrepid o Windows ==

Per ospiti Windows seguire [http://www.linux-kvm.com/content/tip-how-setup-windows-guest-paravirtual-network-drivers queste] istruzioni.

È probabile che le prestazioni della rete siano relativamente inferiori (appros. 100/120mbits). Se si sta usando Ubuntu Hardy o Intrepid, è possibile abilitare virtio. Andare nel file della definizione della VM, ed aggiungere la linea di virtio alla definizione dell'interfaccia di rete:

{{{
    <interface type='bridge'>
      <mac address='52:54:00:a0:41:92'/>
      <source bridge='br0'/>
      <model type='virtio'/> <-- add this line, leave the rest
    </interface>
}}}

Oppure, se si sta usando KVM da linea di comando, aggiungere l'opzione:
{{{
-net nic,model=virtio -net user
}}}

Questo migliora le prestazioni della rete di molto (fattore 10, quasi). Ma per il momeento ciò è possibile solo con ospiti Ubuntu Hardy or Intrepid, ed è il motivo per cui non è pedefinito.

Notare che ciò corregge il problema di perdita di connessione precedentemente riferito.

== Utilizzo di nics multipli con sottoreti multiple cioè vlans ==

È possibile avere alcuni problemi di connettività dell'host su KVM quando si usano multipli nics, ognuno sulla propria sottorete/vlan (instadamenti multipli predefiniti?). Le autenticazioni SSH (all'host KVM) impiegherebbero molto tempo e la connettività potrebbe essere tagliata durante il riavvio dell'interfaccia di rete facendo sessioni ssh e virt-manager le connessioni cadono.

Ma nel caso si necessitino multipli nics, ognuno deve essere su una sottorete separata (vlan).Ogni nic viene quindi dedicato a una specifica VM sull'host KVM. La VM viene quindi connessa alla rete usando un dispositivo bridge.

Non vengono segnalati problemi di connettività con KVM ospite, solamente con KVM Host.

Il problema è stato risolto usando la seguente configurazione in /etc/network/interfaces sulla KVM host.

Nota: Assicurarsi che il SO ospite carichi i giusti drivers di rete. Rimuovere i moduli di rete 8139 e 8139cp, quindi modprobe 8139cp.

{{{
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
 metric 0
###################

auto eth1
iface eth1 inet manual

auto br1
iface br1 inet dhcp
        bridge_ports eth1
 bridge_stp off
 bridge_fd 0
 bridge_maxwait 0
 metric 1
###################

auto eth2
iface eth2 inet manual
 
auto br2
iface br2 inet dhcp
        bridge_ports eth2
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0
 metric 1
###################

# add more ethN and brN as needed
}}}
Linea 319: Linea 192:
== Risorse ==
[https://help.ubuntu.com/community/KVM/Networking Documento originale]
----
CategoryHomepage CategoryInTraduzione
CategoryVirtualizzazione


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


CategoryVirtualizzazione