Closed infernix closed 3 years ago
I believe this was not intentional. Perhaps we can fix this together with #27?
I encountered the same issue, using debian 8.6 host with libvirt 1.2.9, vagrant 1.8.6 and vagrant-libvirt-0.0.36 . As a temporal workaround I edited the source code, but I don't sure if this appropriate:
def dhcp_leases(uuid, mac, flags = 0)
client.lookup_network_by_uuid(uuid).dhcp_leases(mac, flags)
rescue => e
if e.message =~ /no lease with matching MAC address/
return []
end
raise e.class, e.message
end
Same issue on Debian 8.8 with vagrant-libvirt (0.0.40) installed from vagrant-libvirt repository due to this workaround https://github.com/vagrant-libvirt/vagrant-libvirt/issues/770 has been fixed with workaround provided by mrvovanness
Supposed to be fixed in new Debian versions due to this reports: https://www.redhat.com/archives/libvir-list/2015-January/msg00055.html And this commit: https://github.com/libvirt/libvirt/commit/18ec863d19bdaf517e26642f794b7ee4d1d2c53f
This issue has been marked inactive and will be closed if no further activity occurs.
When calling
dhcp_leases
with a mac that does not exist, libvirt throws an error.vagrant-libvirt calls
def addresses
in a while loop, waiting for a VM to boot and retrying until an IP is returned (with an eventual timeout). Since PR #11 this fails due to a functional change.I believe this case should be handled correctly and return
nil
fordef addresses(service_arg=service, options={})
as it was before so that this doesn't break existing functionality. Or is the failure here intentional?