[Libvir] QEMU networking XML docs summary

[Daniel P. Berrange]

What follows is a summary of the ways in which you can setup QEMU networking

 1. Userspace SLIRP stack

    Provides a virtual LAN with NAT to the outside world. The virtual network
    has DHCP & DNS services and will give the guest VM addresses starting
    from 10.0.2.15. The default router will be 10.0.2.2 and the DNS server
    will be 10.0.2.3.  This networking is the only option for unprivileged
    users who need their VMS to have outgoing access. Example configs are:

       <interface type='user'/>

       <interface type='user'>
         <mac address="11:22:33:44:55:66:/>
       </interface>

 2. Virtual network

    Provides a virtual network using a bridge device in the host. Depending
    on the virtual network configuration, the network may be totally isolated,
    NAT'ing to aan explicit network device, or NAT'ing to the default route.
    DHCP and DNS are provided on the virtual network in all cases and the
    IP range can be determined by examining the virtual network config with
    'virsh net-dumpxml <network name>'. There is one virtual network called
    'default' setup out of the box which does NAT'ing to the default route
    and has an IP range of 192.168.22.0/255.255.255.0.  Each guest will
    have an associated tun device created with a name of vnetN, which can
    also be overriden with the <target> element. Example configs are

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

        <interface type='network'>
          <source network='default'/>
          <target dev='vnet7'/>
          <mac address="11:22:33:44:55:66:/>
        </interface>

  3. Bridge to to LAN

     Provides a bridge from the VM directly onto the LAN. This assumes there
     is a bridge device on the host which has one or more of the hosts
     physical NICs enslaved. The guest VM will have an associated tun device
     created with a name of vnetN, which can also be overriden with the
     <target> element. The tun device will be enslaved to the bridge. The
     IP range / network configuration is whatever is used on the LAN. This
     provides the guest VM full incoming & outgoing net access just like
     a physical machine. Examples include

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

       <interface type='bridge'>
         <source dev='br0'/>
         <target dev='vnet7'/>
         <mac address="11:22:33:44:55:66:/>
       </interface>

  4. Generic connection to LAN

     Provides a means for the administrator to execute an arbitrary script
     to connect the guest's network to the LAN. The guest will have a tun
     device created with a name of vnetN, which can also be overriden with the
     <target> element. After creating the tun device a shell script will be
     run which is expected to do whatever host network integration is 
     required. By default this script is called /etc/qemu-ifup but can be
     overriden.

        <interface type='ethernet'/>
        
        <interface type='ethernet'>
          <target dev='vnet7'/>
          <script path='/etc/qemu-ifup-mynet'/>
        </interface>

  5. Multicast tunnel

     A multicast group is setup to represent a virtual network. Any VMs whose
     network devices are in the same multicast group can talk to each other
     even across hosts. This mode is also available to unprivileged users.
     There is no default DNS or DHCP support and no outgoing network access.
     To provide outgoing network access, one of the VMs should have a 2nd
     NIC which is connected to one of the first 4 network types and do the
     appropriate routing. The multicast protocol is compatible with that
     used by user mode linux guests too. The source address used must be
     from the multicast address block

        <interface type='mcast'>
          <source address='230.0.0.1' port='5558'/>
        </interface>

  6. TCP tunnel

     A TCP client/server architecture provides a virtual network. One VM
     provides the server end of the netowrk, all other VMS are configured
     as clients. All network traffic is routed between the VMs via the
     server. This mode is also available to unprivileged users.
     There is no default DNS or DHCP support and no outgoing network access.
     To provide outgoing network access, one of the VMs should have a 2nd
     NIC which is connected to one of the first 4 network types and do the
     appropriate routing. 

     Example server config

        <interface type='server'>
          <source address='192.168.0.1' port='5558'/>
        </interface>

     Example client config

        <interface type='client'>
          <source address='192.168.0.1' port='5558'/>
        </interface>



NB, options 2 -> 4  are also supported by  Xen VMs, so it is possible to 
use these configs to have networking with both Xen & QEMU/KVMs connected
to each other.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|