|
Dimensione: 16823
Commento:
|
Dimensione: 13575
Commento: importato da ivantu/Virtualizzazione/Kvm/Networking
|
| Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
| Linea 2: | Linea 2: |
| #language it [[Indice(depth=2)]] [[Informazioni(forum="http://forum.ubuntu-it.org/index.php/topic,371617.0.html")]] |
#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")>> |
| Linea 6: | Linea 7: |
| KVM/Networking ##controllare se va bene l'introduzione.... |
|
| Linea 11: | 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 14: | Linea 12: |
| ##non mi piace molto dal punto di vista dello stile, ma non so come chiamare gli eventuali paragrafi? | |
| Linea 16: | 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 18: | 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 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 di '''Ubuntu 8.10''' è possibile assegnare ai binari qemu questo permesso usando lo strumento '''setcap'''. 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. * 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 |
{{{#!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 38: | Linea 19: |
| 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. | == Condivisione semplice di file (Usermode Networking - NAT) == |
| Linea 40: | Linea 21: |
| * 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-* }}} |
L''''usermode networking''' (NAT), abilitato di default o con l'opzione da linea di comando `-net user`, permette una facile condivisione di file. |
| Linea 44: | Linea 23: |
| 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 '''Ubuntu 8.10''' 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 60: | Linea 27: |
| == Creazione di un bridge di rete sul host == | == Configurazione di Libvirt per usare il bridge == |
| Linea 62: | Linea 29: |
| [:AmministrazioneSistema/InstallareProgrammi:Installare] il pacchetto [apt://bridge-utils bridge-utils]. Verranno effettuate modifiche alla configurazione di rete[[FootNote(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[[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.)]]: | 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 64: | 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 66: | Linea 45: |
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 }}} ||<tablestyle="text-align: justify; width:100%;" style="border:none;" 5%>[[Immagine(Icone/Piccole/warning.png,,center)]] ||<style="padding:0.5em; border:none;">'''Se viene commesso un errore non sarà possibile il ripristino.'''|| == Configurare ubuntu-vm-builder per creare ospiti bridged predefiniti == ||<tablestyle="text-align: justify; width:100%;" style="border:none;" 5%>[[Immagine(Icone/Piccole/note.png,,center)]] ||<style="padding:0.5em; border:none;">''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'> <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 134: | Linea 54: |
| in:{{{ <interface type='bridge'> <source bridge='br0'/> </interface> }}} * Salvare e chiudere il file appena modificato. == 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 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 160: | Linea 58: |
| == Conversione di un ospite esistente == | == Generazione di un KVM MAC casuale == |
| Linea 162: | Linea 60: |
| 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'/> </interface> }}} 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 }}} Il "mirror" VM sta ora usando sistemi di connessione bridged. |
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 210: | Linea 65: |
| 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 è:{{{ | '''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 è:{{{ |
| Linea 214: | Linea 73: |
Cambiandolo può diventare:{{{ |
* Modificandolo può diventare:{{{ |
| Linea 219: | 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 220: | Linea 82: |
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> }}} 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 (Dapper), 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 234: | Linea 86: |
| '''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}}}. | {{{#!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. }}} |
| Linea 238: | 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 240: | 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 242: | Linea 96: |
| || '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: {{{ |
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 266: | 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 272: | 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 277: | Linea 122: |
| 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. | <<Anchor(virtio)>> == Utilizzo di Virtio per prestazioni di rete ottimali == |
| Linea 279: | 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 281: | 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 283: | 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 285: | 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 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 |
* 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 333: | 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 336: | 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 338: | Linea 192: |
| 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:
- Assicurarsi che l'emulazione della scheda di rete sia compatibile con PXE. Molti modelli moderni (e1000, virtio, rtl8139) supportano PXE.
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.
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: 2In 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).
