Re: [libvirt] [PATCH] virNetDevVethCreate: assign names based on mac address by default
On Thu, Aug 29, 2013 at 10:10:36AM +0200, Michal Privoznik wrote:
On 28.08.2013 23:05, Oskari Saarenmaa wrote:
> Interface names do not have to be numerical (or veth + number) and trying to
> assign them to that format is susceptible to race conditions. Instead,
> assign the parent interface name according to the mac address (the last
> three bytes) if no name was given by the caller and use the parent interface
> name plus 'p' for the container name.
I don't think it is a good idea. What it user defines MAC addresses in a
way that the last three bytes are the same? E.g.
00:11:22:33:44:55
00:22:11:33:44:55
(there are plenty of possibilities). With your code we would create
veth334455 for the first domain and there's nothing left for the other
one but eyes to cry.
Sure, it's possible for the user to assign addresses like this, but I
believe most mac addresses are assigned randomly, that's what libvirt does
by default, no? Also, it's possible for the user to override the interface
name if they want to. Currently it's only possible to set the first
interface name, but there's no way to set the name of the second interface
which causes failures because of races. In any case it makes sense to set
the second interface's name based on the first interface's name so we don't
have to try to come up with two different unique names.
Moreover, there's no race now, as we use global lock to mutually
exclude
call to virNetDevVethCreate. Although, I must admit it's only within a
single driver, I think. So if there are two domains starting (one in
qemu driver the other one in lxc, for instance) there can be race. But
this should be solved in a different way then. The virNetDevVethCreate
should be turned into virObjectLockable and a veth should be allocated
by calling a method.
I ran into this issue repeatedly when I tried to start multiple LXC domains
simultaneously from my application (https://github.com/melor/poni) which
runs libvirt operations in their own threads.
/ Oskari