- 1 Virtual Networking
- 1.1 Virtual network switches
- 1.2 DNS & DHCP
- 1.3 Other virtual network switch routing types
- 1.4 Routed mode
- 1.5 Isolated mode
- 1.6 The default configuration
- 1.7 Restricting virtual network traffic to a specific interface
- 1.8 Examples of common scenarios
- 1.9 The Virtual Machine Manager (virt-manager)
- 1.10 Basic command line usage for virtual networks
- 2 Advanced
How the virtual networks used by guests work
Networking using libvirt is generally fairly simple, and in this section you'll learn the concepts you need to be effective with it.
Also please bear in mind that advanced users can change important parts of how the network layer operates, far past the concepts outlined here. This section will be enough to get you up and running though. :)
Virtual network switches
Firstly, libvirt uses the concept of a virtual network switch.
This is a simple software construction on a host server, that your virtual machines "plug in" to, and direct their traffic through.
On a Linux host server, the virtual network switch shows up as a network interface.
The default one, created when the libvirt daemon is first installed and started, shows up as virbr0.
If you're familiar with the ifconfig command, you can use that to show it:
$ ifconfig virbr0 virbr0 Link encap:Ethernet HWaddr 1A:D4:92:CF:FD:17 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:3097 (3.0 KiB)
If you're more familiar with the ip command instead, this is how it looks:
$ ip addr show virbr0 3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 1a:d4:92:cf:fd:17 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
Showing it in context, with the other network interfaces on the host:
$ ifconfig -a lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:892 (892.0 b) TX bytes:892 (892.0 b) eth0 Link encap:Ethernet HWaddr 00:1B:21:43:33:30 inet addr:10.10.10.190 Bcast:10.10.255.255 Mask:255.255.0.0 inet6 addr: fe80::21b:21ff:fe43:3330/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1942 errors:0 dropped:0 overruns:0 frame:0 TX packets:829 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:985906 (962.7 KiB) TX bytes:142753 (139.4 KiB) Memory:fbea0000-fbec0000 virbr0 Link encap:Ethernet HWaddr 1A:D4:92:CF:FD:17 inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:3097 (3.0 KiB)
$ ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:1b:21:43:33:30 brd ff:ff:ff:ff:ff:ff inet 10.10.10.190/16 brd 10.10.255.255 scope global eth0 inet6 fe80::21b:21ff:fe43:3330/64 scope link valid_lft forever preferred_lft forever 3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 1a:d4:92:cf:fd:17 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
Network Address Translation (NAT)
This means any guests connected through it, use the host IP address for communication to the outside world. Computers external to the host can't initiate communications to the guests inside, when the virtual network switch is operating in NAT mode.
WARNING - The NAT is set up using iptables rules. Be careful if you change these while the virtual switch is running. If something goes wrong with the iptables rules, your virtual machines may stop communicating properly.
DNS & DHCP
Each virtual network switch can be given a range of IP addresses, to be provided to guests through DHCP.
Libvirt uses a program, dnsmasq, for this. An instance of dnsmasq is automatically configured and started by libvirt for each virtual network switch needing it.
Other virtual network switch routing types
Virtual network switches can operate in two other modes, instead of NAT:
With routed mode, the virtual switch is connected to the physical host LAN, passing guest network traffic back and forth without using NAT.
The virtual switch sees the MAC addresses in each packet, using that information when deciding what to do.
In this mode, computers external to the host server directly address and communicate with guest virtual machines. This also allows guests to receive DHCP addresses from an external DHCP server.
If you are familiar with the ISO 7 layer network model, this mode operates on layer 3, the Network layer.
In this mode, guests connected to the virtual switch can communicate with each other, and with the host. However, their traffic will not pass outside of the host, nor can they receive traffic from outside the host.
NOTE - Need to find out if dnsmasq is possible to use in Isolated mode (sounds like it is), and whether to mention it here.
The default configuration
When the libvirt daemon is first installed on a server, it comes with an initial virtual network switch configuration. This virtual switch is in NAT mode, and is used by installed guests for communication. (ie to the outside network)
The libvirt daemon puts this configuration into effect when it starts up, so if you have the libvirt daemon set to start automatically on each boot it should always be present.
If the libvirt daemon is only started manually instead, this is when the default virtual network switch will become available on the host.
Restricting virtual network traffic to a specific interface
- NOTE - Need to find out if it can be restricted to more than one interface.
- i.e on a system with eth0/1/2, can we use the dev="" attribute in the network XML to restrict to (say) eth1&2 rather than only 1 interface?
- NOTE - Not sure if virt-manager lets us configure this aspect of things.
- If not, this will probably need to go under the "Advanced" category as it'll need to be configured through XML instead, or maybe in an overall "Filtering" topic like Dan Berrange wrote up.
Examples of common scenarios
NEED TO THINK OF A FEW
PIC - THIS ONE MIGHT BE TOO COMPLEX: Show several virtual network switches, each with their own dnsmasq, with several guests each (it'll probably have to use icons or something due to size)
The Virtual Machine Manager (virt-manager)
- The virtual network information available (through virt-manager)
- Need to include which versions of virt-manager have this (ie from 0.x.y onwards)
- Also need to list which drivers support this. ie qemu+ssh:// might, whereas qemu:// might not (that's an example only, but recent quick testing showed up some unexpected things here)
Creating a virtual network
Creating virtual networks is easy when using the Virtual Machine Manager GUIT.
The following pages take you through the steps for each of the main network types:
- Creating a NAT Virtual Network
- Creating a Routed Virtual Network
- Creating an Isolated Virtual Network
Starting a virtual network
Stopping a virtual network
Removing a virtual network
Changing a virtual network
- Stats collection in virt-manager
- Need to include which versions of virt-manager have this (ie from 0.x.y onwards)
- Implications of stats collection (performance impact?)
- How to enable/disable collection of stats in virt-manager
- Display of stats
Basic command line usage for virtual networks
Introduces the basic virsh net-* commands for virtual network management.
NO XML apart from dumping to check values
- When covering this, point out that the corresponding dnsmasq instance will be stopped automatically by libvirt at the same time.
- net-dumpxml included here rather than in "Advanced", as people don't need to understand the specifics in order to get value from this. i.e. people can see the MAC address without needing to deeply understand the other pieces
Further dnsmasq info
- NOTE - dnsmasq apparently does more than just plain DNS forwarding, also including entries in the /etc/hosts (on the dnsmasq host) in what's returned to DNS queries.
- Need to double check that's accurate, and if so document it. It sounds like a useful way of potentially overriding upstream DNS entries given to virtual guests
Persistent vs non-persistent virtual networks
(ie net-create vs net-define)
Location of XML files on the host
virsh XML commands
The bridge control commands (brctl) should definitely be covered, as they're used to understand how the network topology is put together.
Also, some people will want to know how to set up their own bridges manually, rather than have libvirt do it.
This should probably go into it's own sub-section, as there's a decent amount of topic in it to cover properly.
NOTE - When covering the brctl addbr command, specifically point out that a random MAC address will be displayed for it if ifconfig is used, even though the bridge interface doesn't actually have a MAC address. It is important, as it's misleading and can confuse a person that is wondering "how/why ARP is propagating through this, when it has a MAC address? ARP isn't supposed to propagate..." (this caught me out). When the bridge has its first network interface assigned to it, it will then use that interface's MAC address from then on. (It only uses the MAC of the first interface, not of any further interfaces plugged in).