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 52 e 53
Versione 52 del 23/11/2023 17.39.37
Dimensione: 16733
Autore: jeremie2
Commento: Tabelle: rimozione vecchi colori standard
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 Emulatori/Kvm/Networking
## page was renamed from FabioMarconi/Prove8
## page updated 24-05-2010 rev36
Linea 5: Linea 2:
#language it #LANGUAGE it
Linea 8: Linea 5:
<<Informazioni(forum="http://forum.ubuntu-it.org/viewtopic.php?t=371617"; rilasci="10.04")>>
<<Informazioni(forum="http://forum.ubuntu-it.org/viewtopic.php?t=371617"; rilasci="25.10 25.04 24.04 22.04 10.04")>>
Linea 13: Linea 9:
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 NAT viene dato 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. 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 17: Linea 13:
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. 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 19: Linea 15:
 * 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]]!

 * Una rete bridged non funziona con le impostazioni predefinite. 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]]).
Prima di utilizzare i comandi QEMU è necessario aver installato il pachetto qemu:
{{{
sudo apt-get install qemu
{{{#!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 27: Linea 19:
 '''QEMU''' non necessita di essere '''suid root'''. A partire dalla versione di '''Ubuntu 8.10''' è possibile assegnare ai binari qemu questo permesso usando lo strumento '''setcap'''. == Condivisione semplice di file (Usermode Networking - NAT) ==
Linea 29: Linea 21:
 Installare il pacchetto [[apt://libcap2-bin | libcap2-bin]] per la gestione dei permessi e seguire uno dei seguenti metodi:
 
  0. '''Ubuntu 10.04''' e sucessive. Ciò assegna solamente a specifici utenti la possibilità di disturbare l'intera rete. Da usarsi con cautela.
L''''usermode networking''' (NAT), abilitato di default o con l'opzione da linea di comando `-net user`, permette una facile condivisione di file.
Linea 33: Linea 23:
    * Assegnare a '''qemu''' il permesso ereditabile CAP_NET_ADMIN digitando il seguente comando in un terminale:{{{
sudo setcap cap_net_admin=ei /usr/bin/qemu-system-*
}}}
    * Installare il modulo PAM del permesso ereditabile digitando il seguente comando in un terminale:{{{
sudo apt-get install libcap2-bin
}}}
    * Modificare con un [[Ufficio/EditorDiTesto|editor di testo]] il file `/etc/security/capability.conf` per consentire ad utenti specifici di avere il permesso ereditabile CAP_NET_ADMIN: {{{
cap_net_admin NOME-UTENT-QUI
}}}

  0. Precedenti a '''Ubuntu 10.04'''. Questo assegna a tutti gli utenti la possibilità di disturbare tutta la rete sul sistema. Da usarsi con estrema cautela.

     * Assegnare a qemu il permesso CAP_NET_ADMIN digitando il seguente comando in un terminale: {{{
sudo setcap cap_net_admin=ep /usr/bin/qemu-system-*
}}}

 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]].

 * Usando il bridge di rete, dopo un considerevole volume di dati scambiati (es. durante un rsync) è possibile avere dei problemi di connessione con il client. Per un host/client su '''Ubuntu 8.04''' o '''successive''' vedere [[#virtio|questo paragrafo]].

 * 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 ==

È possibile in modo predefinito, abilitando l' '''usermode networking''', con l'opzione da linea di comando:{{{
 '-net user'
}}}

il '''Sistema Operativo ospite''' avrà un indirizzo IP compreso nella gamma che va da «10.0.2.0» a «10.0.2.24» memtre il '''Sistema Operativo host''' sarà raggiungibile all'indirizzo IP «10.0.2.2.».
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».
Linea 65: Linea 27:
<<Anchor(bridge-sull-host)>>
== Creazione di un bridge di rete sull'host ==
== Configurazione di Libvirt per usare il bridge ==
Linea 68: Linea 29:
[[AmministrazioneSistema/InstallareProgrammi|Installare]] il pacchetto [[apt://bridge-utils | bridge-utils]]. Verranno effettuate modifiche alla configurazione di rete. Una volta che il bridge `br0` è attivo sull'host, è possibile configurare le macchine virtuali per utilizzarlo.
Linea 70: Linea 31:
{{{#!wiki note
Ciò significa che non si può usare [[http://wiki.ubuntu-it.org/InternetRete/ConfigurazioneRete/NetworkManager|NetworkManager]] per controllare le schede di rete (eth0 per esempio). Se si utilizza [[http://wiki.ubuntu-it.org/InternetRete/ConfigurazioneRete/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 digitando il seguente comando in un terminale:{{{
sudo invoke-rc.d networking stop
}}}

{{{#!wiki note
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.}}}

Se si è su una connessione remota, e non si riesce a fermare i sistemi di connessione, procedere come segue:

 0. Modificare con un [[Ufficio/EditorDiTesto|editor di testo]] il file `/etc/network/interfaces` e commentare o sostituire l'esistente configurazione impostando i valori della propria rete.
 
  * Per configurare un' '''interfaccia bridge''': {{{
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


}}}

  * 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'''.

 0. Digitate all'interno di una finestra di terminale questo comando alla fine delle operazioni:{{{
sudo invoke-rc.d networking restart
}}}

 0. Riavviare i sistemi di connessione digitando in una finestra di terminale il seguente comando:{{{
sudo /etc/init.d/networking restart
}}}

{{{#!wiki important
Se viene commesso un errore non sarà possibile il ripristino.}}}


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

{{{#!wiki note
Questo è sviluppato per dare l'etichetta '''--bridge=br0''' ad '''ubuntu-vm-builder''' in '''Ubuntu 9.10'''.}}}

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`. In '''Ubuntu 8.10''' questo file è `/usr/share/ubuntu-vm-builder/templates/libvirt.tmpl`.

 * Aprire con un [[Ufficio/EditorDiTesto|editor di testo]] il suddetto file e modificare le seguenti righe:{{{
    <interface type='network'>
 * 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'/>
Linea 146: Linea 41:
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
Linea 148: Linea 45:

 in
:{{{
    <interface type='bridge'>
Dopo:{{{
<interface type='bridge'>
      <mac address='52:54:00:xx:yy:zz'/>
Linea 152: Linea 49:
    </interface>
}}}
 * Salvare e chiudere il file appena modificato.

== Generazione di un KVM MAC ==

Se si sta gestendo l'ospite da linea di comando, questo script risulterà utile alla generazione di un MAC casuale:

{{{
MACADDR="52:54:$(dd if=/dev/urandom count=1 2>/dev/null | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\).*$/\1:\2:\3:\4/')"; echo $MACADDR
}}}

== Conversione di un ospite esistente ==

Se è già stata pecedentemente creata una macchina virtuale è possibile consentirgli l'utilizzo dei sistemi di connessione '''bridged''' cambiando la definizione '''XMLI''' nel file `/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'/>
    </interface>
}}}
a:
{{{
    <interface type='bridge'>
      <mac address='00:11:22:33:44:55'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
Linea 181: Linea 55:
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 confonderanno le altre macchine. Non è un difetto di '''KVM''', ma è semplicemente dovuto al modo in cui funziona ethernet.}}}

Per ricaricare i cambiamenti non è necessario riavviare '''libvirtd'''; il modo più semplice è autenticarsi in virsh (uno strumento a linea di comando per la gestione di MV):

 0. Fermare la macchina virtuale;
 0. rileggere il file di configurazione;
 0. riavviare la macchina virtuale.{{{
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
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 214: Linea 58:
 Il '''mirror MV''' ora sta usando sistemi di connessione '''bridged'''. == 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).
Linea 218: Linea 66:
'''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` è possibile risolvere il nome degli ospiti; '''dnsmasq''' è abbastanza intelligente da usare altri nameserver in `/etc/resolv.conf` per risolvere indirizzi '''non-libvirt'''. '''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:
Linea 220: Linea 68:
 * Per esempio, attualmente `/etc/resolv.conf` è:{{{  * 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 è:{{{
Linea 224: Linea 73:

* Cambiandolo può diventare:{{{
 * Modificandolo può diventare:{{{
Linea 229: Linea 77:
}}} 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
Linea 230: Linea 82:

 * Se il nome della macchina virtuale è «hardy-amd64», dopo l'avvio è possibile fare:{{{
$ host hardy-amd64
hardy-amd64 has address <IP address given by dnsmasq>
}}}

 notare che usando ssh è necessario usare «'''.'''» dopo il nome dell'host:{{{
$ ssh hardy-amd64.
}}}

 * 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''', impostare `/etc/dhcp3/dhclient.conf` per avere:{{{
 * 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:{{{
Linea 245: Linea 87:
A seconda della configurazione di rete, il file `/etc/resolv.conf` del host potrebbe essere periodicamente sovrascritto. È necessario, 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}}}.}}} 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.
}}}
Linea 249: Linea 92:
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]] 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.
Linea 251: Linea 94:
'''KVM''' e '''QEMU''' possono emulare vearie schede di rete. Quì sono elencati gli attuali file `ROM`. '''KVM''' e '''[[Virtualizzazione/Qemu|QEMU]]''' possono emulare varie schede di rete e supportano l'avvio PXE. Per abilitare l'avvio PXE per una VM:
Linea 253: Linea 96:
||<tablestyle="width:70%" :20%>'''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` o in `/usr/share/qemu`.

<<Anchor(virtio)>>
== Utilizzo di virtio per ospiti Ubuntu Hardy e successive 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 8.04''' o '''successive''', è possibile abilitare virtio.

Andare nel file della definizione della macchina virtuale e aggiungere la linea di virtio alla definizione dell'interfaccia di rete:{{{
 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 277: Linea 113:
      <mac address='52:54:00:a0:41:92'/>
      <source bridge='br0'/>
      <model type='virtio'/> <-- add this line, leave the rest
      ...
      <boot order='2'/>
Linea 283: Linea 118:
Oppure, se si sta usando '''KVM''' da linea di comando, aggiungere l'opzione:{{{
-net nic,model=virtio -net user
{{{#!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 287: Linea 122:
Questo migliora le prestazioni della rete di molto (fattore 10, quasi). Ma per il momento ciò è possibile solo con ospiti '''Ubuntu 8.04''' o '''successive''', ed è il motivo per cui non è pedefinito. <<Anchor(virtio)>>
== Utilizzo di Virtio per prestazioni di rete ottimali ==
Linea 289: Linea 125:
Notare che ciò corregge il problema di perdita di connessione precedentemente riferito. 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à.
Linea 291: Linea 127:
== Utilizzo di nics multipli con sottoreti multiple cioè vlans ==  * '''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.
Linea 293: Linea 130:
È 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. Per abilitare Virtio in una VM:
Linea 295: Linea 132:
Ma nel caso si necessitino multipli nics, ognuno deve essere su una sottorete separata (vlan). Ogni nic viene quindi dedicato a una specifica MV 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.

Assicurarsi che il Sistema Operativo 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
 * 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 ...
Linea 343: Linea 143:
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).
Linea 346: Linea 186:
 * [[https://help.ubuntu.com/community/KVM/Networking|Documento originale]]  * [[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 349: Linea 192:
CategoryVirtualizzazione CategoryDaRevisionare 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