Ubuntu
libvirt package

[hardy] libvirt loses ip for vnet0, which breaks dnsmasq

Bug #198541 reported by Jamie Strandboge
2
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
Low
Unassigned
Ubuntu later

Bug Description

dnsmasq no longer works as dhcp server when launched from libvirt on up to date hardy.

daemon.log has (repeatedly):
dnsmasq[7999]: no address range available for DHCP request via vnet0

dnsmasq is running with:
$ ps auxww | grep [d]nsmasq
nobody 7999 0.0 0.0 14696 1020 ? S 15:47 0:00 dnsmasq --keep-in-foreground --strict-order --bind-interfaces --pid-file --conf-file --listen-address 192.168.122.1 --except-interface lo --dhcp-leasefile=/var/lib/libvirt/dhcp-default.leases --dhcp-range 192.168.122.2,192.168.122.254

This used to work until a recent update (but I haven't narrowed down the package that broke dnsmasq).

See original description
Revision history for this message
Jamie Strandboge (jdstrand) wrote : Re: [hardy] dnsmasq: dhcp no longer working with libvirt

I think I found it-- vnet0 does not have an ip address on the host, so dnsmasq won't work. If I do:

$ sudo ifconfig vnet0 192.168.122.1

on the host, then dnsmasq starts working again for libvirt guests

Revision history for this message
Jamie Strandboge (jdstrand) wrote : Re: [hardy] libvirt no longer assigns ip to vnet0, which breaks dnsmasq

Checking daemon.log, seems avahi may be causing problems:

$ egrep '(vnet|dnsmasq|virt)' /var/log/daemon.log
Mar 4 18:05:34 foo avahi-daemon[7400]: Joining mDNS multicast group on interface vnet0.IPv4 with address 192.168.122.1.
Mar 4 18:05:34 foo avahi-daemon[7400]: New relevant interface vnet0.IPv4 for mDNS.
Mar 4 18:05:34 foo avahi-daemon[7400]: Registering new address record for 192.168.122.1 on vnet0.IPv4.
Mar 4 18:05:34 foo dnsmasq[7513]: started, version 2.40 cachesize 150
Mar 4 18:05:34 foo dnsmasq[7513]: compile time options: IPv6 GNU-getopt no-ISC-leasefile DBus I18N TFTP
Mar 4 18:05:34 foo dnsmasq[7513]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
Mar 4 18:05:34 foo dnsmasq[7513]: reading /etc/resolv.conf
Mar 4 18:05:34 foo dnsmasq[7513]: using nameserver 170.215.255.114#53
Mar 4 18:05:34 foo dnsmasq[7513]: using nameserver 66.133.170.2#53
Mar 4 18:05:34 foo dnsmasq[7513]: read /etc/hosts - 8 addresses
Mar 4 18:05:35 foo avahi-daemon[7400]: Joining mDNS multicast group on interface vnet0.IPv6 with address fe80::40de:6cff:fe18:56d6.
Mar 4 18:05:35 foo avahi-daemon[7400]: New relevant interface vnet0.IPv6 for mDNS.
Mar 4 18:05:35 foo avahi-daemon[7400]: Registering new address record for fe80::40de:6cff:fe18:56d6 on vnet0.*.
Mar 4 18:05:36 foo NetworkManager: <info> vnet0: Device is fully-supported using driver '(null)'.
Mar 4 18:05:36 foo NetworkManager: <info> Now managing wired Ethernet (802.3) device 'vnet0'.
Mar 4 18:05:36 foo NetworkManager: <info> Deactivating device vnet0.
Mar 4 18:05:36 foo avahi-daemon[7400]: Withdrawing address record for 192.168.122.1 on vnet0.
Mar 4 18:05:36 foo avahi-daemon[7400]: Leaving mDNS multicast group on interface vnet0.IPv4 with address 192.168.122.1.
Mar 4 18:05:36 foo avahi-daemon[7400]: Interface vnet0.IPv4 no longer relevant for mDNS.
Mar 4 18:05:36 foo avahi-daemon[7400]: Withdrawing address record for fe80::40de:6cff:fe18:56d6 on vnet0.
Mar 4 18:05:36 foo avahi-daemon[7400]: Leaving mDNS multicast group on interface vnet0.IPv6 with address fe80::40de:6cff:fe18:56d6.
Mar 4 18:05:36 foo avahi-daemon[7400]: Interface vnet0.IPv6 no longer relevant for mDNS.

This line in particular:
Mar 4 18:05:36 foo avahi-daemon[7400]: Withdrawing address record for fe80::40de:6cff:fe18:56d6 on vnet0.

This makes me wonder if this bug is related to bug #193432

description: updated
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Well, I meant this line seems to be the problem:

Mar 4 18:05:36 foo avahi-daemon[7400]: Withdrawing address record for 192.168.122.1 on vnet0.

Revision history for this message
Martin Pitt (pitti) wrote :

FYI, I uploaded a new hal into hardy which reverts the recent patch to detect virtual network interfaces. So this is at least not a blocker for hardy any more, but one day it will come back, so it eventually needs to get fixed.

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Latest hal fixed this issue. Adjusted milestone for post-hardy as this will come up when the hal patched is reintroduced.

Changed in libvirt:
milestone: none → later
Daniel T Chen (crimsun)
Changed in libvirt:
importance: Undecided → Low
Revision history for this message
Martin Pitt (pitti) wrote :

Please note that the hal patch to show virtual network devices is in Jaunty (coming from upstream).

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I'm going to mark this as Fix Released because I've been running Jaunty throughout the cycle and have not hit this bug.

Changed in libvirt:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.