What I'd like to do is to set the guests' network configuration (IP address, subnet, gateway, broadcast address) from the host system. The used network setup is in bridge mode. How can I configure the network from the host rather than configuring the client itself to a static network configuration?

If I execute:

virsh edit vm1

there is a <network> block as well and I tried to configure the network interface from there, but unfortunately the guest VM doesn't seem to use it and as such is offline to the network (since it uses automatic network configuration only)... Guest VMs are both, Linux and Windows based. Any help would be highly appreciated.

  • 2
    Is handing IP addresses out via reserved DHCP leases not an option? – MadHatter Sep 9 '14 at 11:24
  • Hm I guess it is, but I'd like to assign VM #1 to IP #1, VM #2 to IP #2 etc (rather than giving them a random IP out of my lease). Do you think it would be possible to configuring it like this with DHCP? If it is, I'd be glad to try this approach. – beta Sep 9 '14 at 11:27
  • 2
    I suggest to rename the question to something like "KVM/libvirt: How to configure static guest IP addresses on the virtualisation host" – Nils Toedtmann Sep 9 '14 at 12:09
  • 1
    Agree with @NilsToedtmann, any additional details about the hypervisor being used like base OS, etc would be beneficial. There may be additional OS based management tools to help with configuration of networking for virtualized systems. There are great guides on KVM and LXC for use with SUSE based operating systems that can make use of YaST. – Matt Jul 14 '15 at 15:14

If you don't want to do any configuration inside the guest, then the only option is a DHCP server that hands out static IP addresses. If you use bridge mode, that will probably be some external DHCP server. Consult its manual to find out how to serve static leases.

But at least in forward modes nat or route, you could use libvirt's built-in dnsmasqd (More recent versions of libvirtd support the dnsmasq's "dhcp-hostsfile" option). Here is how:

First, find out the MAC addresses of the VMs you want to assign static IP addresses:

virsh  dumpxml  $VM_NAME | grep 'mac address'

Then edit the network

virsh  net-list
virsh  net-edit  $NETWORK_NAME    # Probably "default"

Find the <dhcp> section, restrict the dynamic range and add host entries for your VMs

  <range start='' end=''/>
  <host mac='52:54:00:6c:3c:01' name='vm1' ip=''/>
  <host mac='52:54:00:6c:3c:02' name='vm2' ip=''/>
  <host mac='52:54:00:6c:3c:03' name='vm3' ip=''/>

Then, reboot your VM (or restart its DHCP client, e.g. ifdown eth0; ifup eth0)

Update: I see there are reports that the change might not get into effect after "virsh net-edit". In that case, try this after the edit:

virsh  net-destroy  $NETWORK_NAME  
virsh  net-start    $NETWORK_NAME  

... and restart the VM's DHCP client.

If that still doesn't work, you might have to

  • stop the libvirtd service
  • kill any dnsmasq processes that are still alive
  • start the libvirtd service

Note: There is no way the KVM host could force a VM with unknown OS and unknown config to use a certain network configuration. But if know know that the VM uses a certain network config protocol - say DHCP - you can can use that. This is what this post assumes.

Some OS (e.g. some Linux distros) also allow to pass network config options into the guest e.g. via the kernel command line. But that is very specific to the OS, and i see no advantage over the DHCP method.

  • Thanks I'll try it and report back if I got it working that way. – beta Sep 9 '14 at 12:36
  • Cool. But you'll have to change the network mode. – Nils Toedtmann Sep 9 '14 at 13:03
  • 1
    I came here because I have a similar need, and I think I can explain the advantage over using DHCP, at least for my use case. The situation is admittedly unusual. I have a server that moves back and forth between two networks every couple weeks. It has about 10 guests. One of the networks has a DHCP server (which is hard to control for me), the other doesn't. That pretty much rules out using DHCP. I am looking for a way to change the host's IP and automatically update guest IP addresses etc. based on that (I'm using chef for automation, so once the IP addresses are set up, I'm good to go). – Kevin Keane Jul 29 '15 at 16:50
  • 2
    I can confirm that changes don't take effect without destroying and restarting the network. I also found, strangely, that I had to shutdown, and then start the VM. Simply rebooting left the interface in a broken state. – orodbhen May 21 '16 at 17:13
  • Restarting the network doesn't renew the DHCP leases. For this, you have to delete the network's status file in /var/lib/libvirtd/dnsmasq – orodbhen May 21 '16 at 19:44

virsh net-update is a good command for you (you don't need to restart/destroy your network etc)
see: https://www.redhat.com/archives/libvir-list/2012-September/msg01380.html

  • This did not work for me. I had to destroy/start the network. – Alex Willison Jun 8 '17 at 15:06
  • It did work for me, no network restart or VM restart needed. – mevdschee Jan 2 '20 at 0:45

I have been able to make dnsmasq 'see' the newly added IP-MAC mapping by simply sending a -HUP signal to the dnsmasq process. After that, rebooting the new guest was enough to have the correct IP assigned to it, without the need to restart libvirtd nor the network itself.

The official libvirt documentation (http://wiki.libvirt.org/page/Networking#Applying_modifications_to_the_network) mentions this unofficial Perl script that automates the whole process: https://gist.github.com/bendiken/032ea1bddb9ffafe98b4

I haven't tried this script myself, because I figured out that the hostsfile was already updated and just sending the -HUP signal was enough.

The host is running Debian 7.8 and packages versions are:

  • kvm 1:1.1.2+dfsg-6+deb7u8
  • qemu-kvm 1.1.2+dfsg-6+deb7u8
  • libvirt-bin

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.