]> xenbits.xensource.com Git - libvirt.git/commit
util: keep/use a bitmap of in-use macvtap devices
authorLaine Stump <laine@laine.org>
Tue, 19 Jan 2016 19:20:54 +0000 (14:20 -0500)
committerLaine Stump <laine@laine.org>
Tue, 26 Jan 2016 17:20:04 +0000 (12:20 -0500)
commit370608b4c76f7290cbebc4e4a05fca4eb0e9ffe8
treeff2dba9785c00738c11638f364b92b1011779acc
parent8c70d04bab7278c96390a913fa949a17cd3124f9
util: keep/use a bitmap of in-use macvtap devices

This patch creates two bitmaps, one for macvlan device names and one
for macvtap. The bitmap position is used to indicate that libvirt is
currently using a device with the name macvtap%d/macvlan%d, where %d
is the position in the bitmap. When requested to create a new
macvtap/macvlan device, libvirt will now look for the first clear bit
in the appropriate bitmap and derive the device name from that rather
than just starting at 0 and counting up until one works.

When libvirtd is restarted, the qemu driver code that reattaches to
active domains calls the appropriate function to "re-reserve" the
device names as it is scanning the status of running domains.

Note that it may seem strange that the retry counter now starts at
8191 instead of 5. This is because we now don't do a "pre-check" for
the existence of a device once we've reserved it in the bitmap - we
move straight to creating it; although very unlikely, it's possible
that someone has a running system where they have a large number of
network devices *created outside libvirt* named "macvtap%d" or
"macvlan%d" - such a setup would still allow creating more devices
with the old code, while a low retry max in the new code would cause a
failure. Since the objective of the retry max is just to prevent an
infinite loop, and it's highly unlikely to do more than 1 iteration
anyway, having a high max is a reasonable concession in order to
prevent lots of new failures.
src/libvirt_private.syms
src/qemu/qemu_process.c
src/util/virnetdevmacvlan.c
src/util/virnetdevmacvlan.h