Post details: Networking with kvm and libvirt

04/27/07

Permalink 09:48:53 am, Categories: Virtualization, 494 words  

Networking with kvm and libvirt

When you're using kvm to run virtual machines, you more than likely also want them to have some sort of network access. There's two very basic setups that seem useful:

  1. Create a private network on the host that gets NAT'd to the 'outside', similar to how your home network is set up behind your DSL router. This setup is useful for laptops, or more generally, when you don't have infrastructure such as a DHCP or DNS server on your network yet.
  2. Bridge all the guests to the network the host is running on, and forward all traffic, including DHCP, DNS, etc. to the outside network. This is the setup you want if you already have DHCP and DNS servers somewhere, and have a stable, wired connection on the host. It's also what Xen does by default, and therefore pretty familiar to a lot of people

1. Private network for the guests

This configuration is, thanks to some recent additions to libvirt, available by default. Recent versions of libvirt, e.g. the 0.2.2 in rawhide, set everything up by default, and all you need to do is to make sure the virt-install command you use to create the guest looks something like

  virt-install --accelerate --hvm --connect qemu:///system \
    --network network:default \
    ... usual options for memory/disk files/boot CD ...

(Of course, if you're using virt-manager, this is a simple matter of pointing and clicking the right thing ;) )

If you have dnsmasq installed, and you should, libvirt will start dnsmasq to provide DHCP and DNS for the guests on the default network, and you'll have your very own, completely enclosed network for the guests, that is NAT'd and forwarded over the host's physical network connections.

If you're curious, the default network is described in the file /etc/libvirt/qemu/networks/default.xml If you make changes to it, you need to let libvirt know by using the virsh net-* commands.

2. Xen-like bridging

Assuming you have one physical NIC on your host, and you want to bridge all the guests onto the physical network, you need to setup a bridge for that and enslave the physical NIC to it. We'll call the bridge eth0 and the physical device peth0. Note that the bridge device eth0 is the one that receives an IP address. With that, you need to put two files into /etc/sysconfig/network-scripts: the file ifcfg-peth0 should be

DEVICE=peth0
ONBOOT=yes
BRIDGE=eth0
HWADDR=XX:XX:XX:XX:XX:XX

and the file ifcfg-eth0 should be

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes
TYPE=Bridge

You also want to add an iptables rule that allows forwarding of packets on the bridged physical NIC (otherwise DHCP from your guests won't work):

 # service iptables start
 # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
 # service iptables save

You can now create your guests and add them to the bridge by running virt-install like so:

  virt-install --accelerate --hvm --connect qemu:///system \
    --bridge eth0 \
    ... usual options for memory/disk files/boot CD ...

Comments:

Comment from: Steve [Visitor]
I think the default for VMWare is also bridged.

The reason this is handy is for things like Windows file sharing. If your virtual machine is behind a virtual NAT then it can't be seen by the rest of the network, although with the default VMWare setup the host can see shares etc.

But what if you have a laptop? What would be ideal is if the host could forward avahi/smb/cups traffic onto the virtual LAN as needed. Is this possible?

It's a real pain to have pick either one of two not-quite-right network setups.

Thanks!
Permalink 04/27/07 @ 13:23
Comment from: Steve [Visitor]
p.s. Your blog's busted.

The link from the feed is 404, and after posting a comment the Save As dialog pops up, offering to open the result in Totem... :-)
Permalink 04/27/07 @ 13:27
Comment from: lutter [Member]
Strange .. the link worked from my RSS reader. I'll see what happens when I go to save this comment ;)
Permalink 04/27/07 @ 16:30
Comment from: Eric-Olivier Lamey [Visitor] · http://perns.com
Thank you for your post. Is it me, or you bridge example is somewhat backwards? Xen creates a xenbr* bridge which enslaves eth0, and you seem to be doing the opposite, creating an eth0 bridge, with the physical interface being renamed to br0. I find it a little bit disturbing :)
Permalink 04/30/07 @ 01:52
Comment from: lutter [Member]
It does look backwards; the problem I had doing it the other way around (at least in rawhide) is that the initscripts run dhclient on the bridge interface before the phyiscal interface is enslaved, and that doesn't work.

The only way I could get it to work was by enslaving the physical interface before bringing up the bridge. Calling the physical interface peth0 (or eth0) and the bridge virbr0 might also work.
Permalink 04/30/07 @ 09:57
Comment from: lutter [Member]
For whatever reasons, calling the physical device peth0 and the bridge eth0 didn't work for me last week. Dan Berrange pointed out that that does work for him. I just tried it on a freshly installed rawhide box, and things seem to be working fine.

I just updated the post to reflect that and use a less confusing naming scheme.
Permalink 05/02/07 @ 17:19

Comments are closed for this post.

Search

Syndicate this blog XML

What is RSS?

Misc

powered by
b2evolution