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 1 e 47 (in 46 versioni)
Versione 1 del 21/03/2010 17.39.33
Dimensione: 14752
Autore: FabioMarconi
Commento:
Versione 47 del 14/03/2011 12.51.23
Dimensione: 17516
Autore: localhost
Commento: converted to 1.6 markup
Le cancellazioni sono segnalate in questo modo. Le aggiunte sono segnalate in questo modo.
Linea 1: Linea 1:
#title KVM Networking
<<Include(KVM/Header)>>
||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents(3)>>||

= Configuring the network =

There are a few different ways to allow a virtual machine access to the external network. The default virtual network configuration is usermode networking, which uses the SLIRP protocol and traffic is NATed through the host interface to the outside network. If you do not want to access network services on your virtual machine then you can skip this next step.

However to enable external hosts to directly access services on virtual machines a bridge needs to be configured. This allows the virtual interfaces to connect to the outside network through the physical interface, making them appear as normal hosts to the rest of the network.

'''Warning:''' Network bridging will not work when the physical network device (eg eth1, ath0) used for bridging is a wireless device (eg 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]]!

'''Warning 2:''' Bridged networking does not work by default. Since the release of kernel 2.6.18 in Sep 2006, the CAP_NET_ADMIN capability is required to use TUN/TAP networking ([[https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/103010|bug #103010]]).

 * '''QEMU does not need to be suid root.''' Since Intrepid it has been possible to give the qemu binaries this capability using the "setcap" tool. First install the Linux capabilities tools (`sudo apt-get install libcap2-bin`) and choose:
  * Safer method (can be done in Lucid and later). This allows '''specific users''' the ability to disrupt all networking on the system. Use cautiously.
   * Give qemu the '''inheritable''' CAP_NET_ADMIN capability:
   {{{
sudo setcap cap_net_admin=ei /usr/bin/qemu-system-*}}}
   * Install the inheritable PAM capability module:
   {{{
sudo apt-get install libcap2-bin}}}
   * Allow specific users to gain the inheritable CAP_NET_ADMIN capability by editing `/etc/security/capability.conf`:
   {{{
cap_net_admin USER-NAME-HERE}}}
  * Less safe method (must be used prior to Lucid). This allows '''all users''' the ability to potentially disrupt all networking on the system. Use with extreme caution.
   * Give qemu the '''forced''' CAP_NET_ADMIN capability:
   {{{
sudo setcap cap_net_admin=ep /usr/bin/qemu-system-*}}}
 * Note that the filesystem capabilities above will be lost on every qemu upgrade, since setting of the file system capability is not supported by Ubuntu packaging (see [[https://wiki.ubuntu.com/Security/FilesystemCapabilties|FilesystemCapabilities]] for details on the blockers). For a good overview of Linux capabilities and QEMU see [[http://www.friedhoff.org/posixfilecaps.html|this writeup]].

'''Warning 3:''' A number of people are having problems with the network bridge losing connection with the client after large amounts of data transfer (eg. during rsync) For a Hardy or Intrepid host/client see [[#virtio|below]].

'''Warning 4:''' A network bridge configured as described here will not appear in virt-manager when using a remote management session, see [[https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/520386|bug #520386]].

== Simple file sharing ==
By default, if you enable the usermode networking using the '-net user' command-line option, the guest OS will get an IP address in the 10.0.2.0/24 address space and the host OS will be reachable at 10.0.2.2.

Thus, you should be able to ssh into the host OS (at 10.0.2.2) from inside the guest OS and thus use scp to copy files back and forth.

== Creating a network bridge on the host ==

Install the bridge-utils package:
{{{
sudo apt-get install bridge-utils
}}}

We are going to change the network configuration<<FootNote(This assumes you are not using NetworkManager to control your network cards (eth0 in the example's case). If you are using NetworkManager disable it or prevent it from controlling this card. Use the configuration for your card as the network configuration of the bridge (br0 in the example).)>>. To do it properly, we should first stop networking<<FootNote(This is needed for example when you move from DHCP to static address: it will stop the DHCP client, which a restart won't do if you changed the configuration already. If you are changing this remotely, then you should prepare your new configuration into a separate file and the use a script to stop networking, put the new configuration in place and start it back.)>>:
{{{
## page was renamed from Emulatori/Kvm/Networking
## page was renamed from FabioMarconi/Prove8
## page updated 24-05-2010
#format wiki
#language it
<<Indice(depth=2)>>
<<Informazioni(forum="http://forum.ubuntu-it.org/index.php/topic,371617.0.html")>>


= Introduzione =

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.

= Configurazione della rete =

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.

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

 '''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
}}}

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

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.

<<Anchor(bridge-sull-host)>>
== Creazione di un bridge di rete sull'host ==

[[AmministrazioneSistema/InstallareProgrammi|Installare]] il pacchetto [[apt://bridge-utils | bridge-utils]]. Verranno effettuate modifiche alla configurazione di rete.

||<tablestyle="text-align: justify; width:100%;" style="border:none;" 5%><<Immagine(Icone/Piccole/note.png,,center)>> ||<style="padding:0.5em; border:none;">''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:{{{
Linea 53: Linea 71:
If you are on a remote connection, and so cannot stop networking, go ahead with the following commands, and use sudo invoke-rc.d networking restart at the end. If you made a mistake, it won't come back up, though.

To setup a bridge interface, edit /etc/network/interfaces and either comment or replace the existing config with ('''replace with the values for ''your'' network'''):

{{{
||<tablestyle="text-align: justify; width:100%;" style="border:none;" 5%><<Immagine(Icone/Piccole/note.png,,center)>> ||<style="padding:0.5em; border:none;">''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''': {{{
Linea 79: Linea 99:
or to use DHCP

{{{
  * Per usare '''DHCP''':{{{
Linea 97: Linea 115:
This will create a virtual interface br0.

Now restart networking:

{{{
  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:{{{
Linea 105: Linea 125:
== Configuring ubuntu-vm-builder to create bridged guests by default ==

||This is handled by giving ubuntu-vm-builder the --bridge=br0 flag in karmic.||

Virtual machines are defined in XML files; ubuntu-vm-builder, the tool we will use to create VMs, bases them on the template file /etc/vmbuilder/libvirt/libvirtxml.tmpl (before Ubuntu 8.10 /usr/share/ubuntu-vm-builder/templates/libvirt.tmpl)

Open that file, and change:

{{{
||<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:{{{
Linea 119: Linea 140:
To:

{{{
 in:{{{
Linea 126: Linea 145:

== Generating a KVM MAC ==

If you are managing your guests via command line, the following script might be helpful to generate a randomized MAC. If you are getting an error for 'rl', install the package 'randomize-lines'.
 * 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:
Linea 131: Linea 152:
#!/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
}}}

== Converting an existing guest ==

If you have already created VMs before, you can make them use bridged networking if you change the XML definition (in /etc/libvirt/qemu/) for the network interface, adjusting the mac address as desired from:
{{{
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:{{{
Linea 155: Linea 163:
to: a:
Linea 162: Linea 170:
'''Note: Make sure the first octet in your MAC address is EVEN (eg. 00:)''' as MAC addresses with ODD first-bytes (eg. 01:) are reserved for multicast communication and can cause confusing problems for you. For instance, the guest will be able to receive ARP packets and reply to them, but the reply will confuse other machines. This is not a KVM issue, but just the way Ethernet works.

You do not need to restart libvirtd to reload the changes; the easiest way is to log into virsh (a command line tool to manage VMs), stop the VM, reread its configuration file, and restart the VM:

{{{

||<tablestyle="text-align: justify; width:100%;" style="border:none;" 5%><<Immagine(Icone/Piccole/note.png,,center)>> ||<style="padding:0.5em; border:none;">''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.{{{
Linea 193: Linea 204:
The VM "mirror" is now using bridged networking.

== DNS and DHCP Guests ==
libvirt uses dnsmasq to hand out IP addresses to guests which are configured to use dhcp. If on your host machine, you add 192.168.122.1 (the default IP of your host in libvirt) as your first nameserver in /etc/resolv.conf, then you can do name resolution for your guests. dnsmasq is smart enough to use the other 'nameserver' entries in your /etc/resolv.conf for resolving non-libvirt addresses. For example, if your current /etc/resolv.conf is:{{{
 Il '''mirror MV''' ora sta usando sistemi di connessione '''bridged'''.

== 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` è 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` è:{{{
Linea 201: Linea 215:
Change this to be:{{{  * Cambiandolo può diventare:{{{
Linea 207: Linea 221:
Now, if you have a virtual machine named 'hardy-amd64', after starting it, you can do: {{{  * Se il nome della macchina virtuale è «hardy-amd64», dopo l'avvio è possibile fare:{{{
Linea 212: Linea 226:
Note that when using ssh you may need to use a trailing '.' after the hostname:{{{  notare che usando ssh è necessario usare «'''.'''» dopo il nome dell'host:{{{
Linea 216: Linea 230:
Finally, for this to work, your guest must send its hostname as part of the dhcp request. This is done automatically on many operating systems. For systems that do not send this automatically and use dhcp3, you can adjust the dhclient.conf file. For example, on Ubuntu 6.06 LTS (Dapper), adjust /etc/dhcp3/dhclient.conf to have:{{{
send host-name "<your guest hostname here>";
}}}

'''IMPORTANT:''' Depending on your network configuration, your host's /etc/resolv.conf file might be periodically overwritten. You will have to either adjust the dhcp server on your network to hand out the additional libvirt name server for your libvirt hosts, or adjust each host machine accordingly. As there are many possible configurations for host machines, user's are encouraged to look at {{{resolvconf}}} and/or {{{man interfaces}}}.

== Booting Over the Network Using PXE ==

The current Ubuntu release does not ship pxe binary ROM images because the source code is not included to recreate the images in the upstream tarball. There may be a way to automate the creation of these files as part of the package. In order to use boot -n, you will need to download or create the appropriate ROM images from [[http://etherboot.org]]

KVM and QEMU can emulate a number of network cards. Here is the current ROM files

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

Copy the respective file to /usr/share/kvm and/or /usr/share/qemu.
 * 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:{{{
send host-name "<hostname dell'ospite>";
}}}

||<tablestyle="text-align: justify; width:100%;" style="border:none;" 5%><<Immagine(Icone/Piccole/note.png,,center)>> ||<style="padding:0.5em; border:none;">''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}}}.''||

== 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`.

||<tablestyle="width:70%" : 20% style="background-color:#FB8B00;">'''KVM Name nic,model='''||<style="background-color:#FB8B00;":>'''Etherboot Identification'''||<style="background-color:#FB8B00;":>'''Etherboot Filename'''||<style="background-color:#FB8B00;":>'''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`.
Linea 244: Linea 258:
== Use virtio for Ubuntu Hardy/Intrepid or Windows guests ==

For Windows guests follow [[http://www.linux-kvm.com/content/tip-how-setup-windows-guest-paravirtual-network-drivers|this]] instruction.

You may find the performances of the network relatively poor (approx. 100/120mbits on my servers, which are quite fast). If you are running Ubuntu Hardy or Intrepid, you can enable virtio. Go to the definition file of your VM, and add the virtio line to the definition of your network interface:

{{{
== 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:{{{
Linea 258: Linea 272:
Or, if you're using KVM on the command line, add the options:
{{{
Oppure, se si sta usando '''KVM''' da linea di comando, aggiungere l'opzione:{{{
Linea 263: Linea 276:
This improves the network performances by a lot (factor 10, nearly). But this works only with Ubuntu Hardy or Intrepid guests for the moment, which is why it is not by default.

Note that this also corrects the issue some are reporting with their network connections going away after a period of time or data transfer.

== Using multiple nics with multiple subnets i.e. vlans ==

You may experience some KVM host connectivity issues when using multiple nics, each on their own subnet/vlan (multiple default routes?). In my case SSH logins (to the KVM host) would take a long time and connectivity would be cut when I restarted the network interfaces making ssh sessions and virt-manager connections crash.

I needed multiple nics, each to be on a separate subnet (vlan). Each nic is then dedicated to a specific VM on the KVM host. The VM's then connect directly to the network using a bridge device.

I never experienced problems with KVM guest connectivity. Only the KVM Host.

I fixed the problem using the following configuration in /etc/network/interfaces on the KVM host. Please note the use of "manual" and "metric". YMMV. :D

Note: first make sure that the guestOS loads the right network drivers, this worked for me: remove network modules 8139cp and 8139too , then modprobe 8139cp
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.

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 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.
Linea 319: Linea 332:
<<Include(KVM/Header)>>
= Ulteriori risorse =

 * [[https://help.ubuntu.com/community/KVM/Networking|Documento originale]]
Linea 321: Linea 337:
CategoryVirtualization CategoryVirtualizzazione

Problemi in questa pagina? Segnalali in questa discussione

Introduzione

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.

Configurazione della rete

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.

  • Il bridging di rete non funziona quando la scheda di rete (es. eth1, ath0) è di tipo wireless (es. ipw3945), 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 (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 libcap2-bin per la gestione dei permessi e seguire uno dei seguenti metodi:

    1. 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 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
    2. 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 FilesystemCapabilities per dettagli sugli ostacoli). Per una miglior panoramica sui permessi Linux e QEmu vedere 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 questo paragrafo.

  • Un bridge di rete configurato seguendo queste istruzioni non risulterà in virt-manager durante una sessione di gestione remota, vedere 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.».

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.

Creazione di un bridge di rete sull'host

Installare il pacchetto bridge-utils. Verranno effettuate modifiche alla configurazione di rete.

Ciò significa che non si può usare NetworkManager per controllare le schede di rete (eth0 per esempio). Se si utilizza 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

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:

  1. Modificare con un 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.

  2. Digitate all'interno di una finestra di terminale questo comando alla fine delle operazioni:

    sudo invoke-rc.d networking restart
  3. Riavviare i sistemi di connessione digitando in una finestra di terminale il seguente comando:

    sudo /etc/init.d/networking restart

Se viene commesso un errore non sarà possibile il ripristino.

Configurare ubuntu-vm-builder per creare ospiti bridged predefiniti

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 editor di testo il suddetto file e modificare le seguenti righe:

        <interface type='network'>
          <source network='default'/>
        </interface>

    in:

        <interface type='bridge'>
          <source bridge='br0'/>
        </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'/>
    </interface>

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

  1. Fermare la macchina virtuale;
  2. rileggere il file di configurazione;
  3. 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

    Il mirror MV ora sta usando sistemi di connessione bridged.

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

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

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.

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 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 o in /usr/share/qemu.

Utilizzo di virtio per ospiti Ubuntu Hardy e successive o Windows

Per ospiti Windows seguire 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:

    <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 momento ciò è possibile solo con ospiti Ubuntu 8.04 o successive, 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 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

Ulteriori risorse


CategoryVirtualizzazione