BR Indice(depth=2 align=right)

Configurazione della rete

Esistono pochi metodi per consentire ad una macchina virtuale l'accesso ad una rete esterna. La configurazione predefinita per la rete virtuale è "usermode networking", che utilizza il protocollo SLIRP ed il traffico viene NATtato alla rete esterna per mezzo dell'interfaccia del host. Nel caso non si desiderino accessi ai servizi di rete nella macchina virtuale, saltare il passo successivo.

Per consentire l'accesso diretto di host esterni ai servizi sulla macchina virtuale è necessario configurare un bridge. In questo modo si rende possibile la connessione di interfacce virtuali alla rete esterna attraverso l'interfaccia fisica, rendendola così simile agli host del resto della rete.

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

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

• QEMU non necessita di essere suid root. A partire dalla versione Intrepid è possibile assegnare ai binari qemu questo permesso usando lo strumento "setcap". Innanzitutto occorre installare gli strumenti per la gestione dei permessi di Linux (sudo apt-get install libcap2-bin) e scegliere:

  • Metodo più sicuro (possibile solo dalla versione Lucid in poi). Ciò assegna solamente a specifici utenti la possibilità di disturbare l'intera rete. Da usarsi con cautela.

    • Assegnare a qemu il permesso ereditabile CAP_NET_ADMIN:

      sudo setcap cap_net_admin=ei /usr/bin/qemu-system-*

    • Installare il modulo PAM del permesso ereditabile:

      sudo apt-get install libcap2-bin

    • Consentire ad utenti specifici di avere il permesso ereditabile CAP_NET_ADMIN editando il file /etc/security/capability.conf:

      cap_net_admin        NOME-UTENT-QUI

  • Metodo meno sicuro (per le versioni precedenti a Lucid). Questo assegna a tutti gli utenti la possibilità di disturbare tutta la rete sul sistema. Da usarsi con estrema cautela.

    • Assegnare a qemu forzatamente il permesso CAP_NET_ADMIN :

      sudo setcap cap_net_admin=ep /usr/bin/qemu-system-*

• Nota che i permessi di filesystem di cui sopra verranno persi ad ogni aggiornamento di qemu, dato che l'impostazione dei permessi di filesystem non è supportata dalla gestione pacchetti di Ubuntu (vedere [https://wiki.ubuntu.com/Security/FilesystemCapabilties FilesystemCapabilities] per dettagli sugli ostacoli). Per una miglior panoramica sui permessi Linux e QEmu vedere [http://www.friedhoff.org/posixfilecaps.html quanto scritto sopra].

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

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

Condivisione semplice di file

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

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

Creazione di un bridge di rete sul host

Installare il pacchetto bridge-utils:

sudo apt-get install bridge-utils

Verranno effettuate modifiche alla configurazione di reteFootNote(Ciò significa che non si può usare [http://wiki.ubuntu-it.org/Hardware/DispositiviSenzaFili/NetworkManager NetworkManager] per controllare le schede di rete (eth0 per esempio). Se si utilizza [http://wiki.ubuntu-it.org/Hardware/DispositiviSenzaFili/NetworkManager NetworkManager] disabilitarlo o prevenirne il controllo sulle schede di rete. Usare per la configurazione della scheda la medesima usata per la configurazione del bridge di rete (br0 nell'esempio).). Per fare ciò correttamente, bisogna innanzitutto fermare i sistemi di connessioneFootNote(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.):

sudo invoke-rc.d networking stop

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

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

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

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

oppure per usare DHCP:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

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

Questo creerà un interfaccia virtuale br0.

Riavviare i sistemi di connessione:

sudo /etc/init.d/networking restart

Configurare ubuntu-vm-builder per creare ospiti bridged predefiniti

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

Aprire questo file , e cambiare:

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

In:

    <interface type='bridge'>
      <source bridge='br0'/>
    </interface>

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

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

Conversione di un ospite esistente

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.

DNS e DHCP ospiti

libvirt usa dnsmasq per fornire indirizzi IP ad ospiti configurati per l'uso di DHCP. Se nella macchina host, viene aggiunto 192.168.122.1 (l'indirizzo IP prestabilito per l'host in libvirt) come primo nameserver in /etc/resolv.conf, quindi è possibile risolvere il nome degli ospiti. dnsmasq è abbastanza intelligente da usare altri 'nameserver' in /etc/resolv.conf per risolvere indirizzi non-libvirt. Per esempio, attualmente /etc/resolv.conf è:

search example.com
nameserver 10.0.0.1

Cambiandolo può diventare:

search example.com
nameserver 192.168.122.1
nameserver 10.0.0.1

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:

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

IMPORTANTE: A seconda della configurazione di rete, il file /etc/resolv.conf del host potrebbe essere periodicamente sovrascritto. é necessario quindi o impostare il server dhcp della rete per fornire il nome server aggiuntivo a libvirt per gli host di libvirt, oppure regolare di conseguenza ogni macchina.Siccome sono possibili molteplici configurazioni per macchine host, è reccomandabile vedere resolvconf e/o man interfaces.

Avvio da rete usando PXE

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

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

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

Anchor(virtio)

Utilizzo di virtio per ospiti Ubuntu Hardy/Intrepid o Windows

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

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

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

Oppure, se si sta usando KVM da linea di comando, aggiungere l'opzione:

-net nic,model=virtio -net user

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

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

Utilizzo di nics multipli con sottoreti multiple cioè vlans

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

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

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

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

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

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

# The loopback network interface
auto lo
iface lo inet loopback

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

auto eth1
iface eth1 inet manual

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

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

# add more ethN and brN as needed

Risorse

[https://help.ubuntu.com/community/KVM/Networking Documento originale]

CategoryHomepage CategoryInTraduzione