After the patches that added tracking of in-use macvtap names (commit 370608, first appearing in libvirt-1.3.2), if the function to allocate a new macvtap device came to a device name created outside libvirt, it would retry the same device name MACVLAN_MAX_I (8191) times before finally giving up in failure. The problem was that virBitmapNextClearBit was always being called with "0" rather than the value most recently checked (which would increment each time through the loop). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1321546 --- I'm not sure how this bug snuck in, because this is one of the scenarios I tested. The only thing I can think of is that I screwed up somehow during a rebase after testing and before posting/pushing (or possibly I had tested these cases in an earlier iteration, but forgot to do so with the final version) :-/ Sigh. src/util/virnetdevmacvlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c index 2409113..d755b93 100644 --- a/src/util/virnetdevmacvlan.c +++ b/src/util/virnetdevmacvlan.c @@ -131,7 +131,7 @@ virNetDevMacVLanReserveID(int id, unsigned int flags, } if ((id < 0 || nextFree) && - (id = virBitmapNextClearBit(bitmap, 0)) < 0) { + (id = virBitmapNextClearBit(bitmap, id)) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("no unused %s names available"), (flags & VIR_NETDEV_MACVLAN_CREATE_WITH_TAP) ? -- 2.5.5 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list