Re: [PATCH] virNetDevVethCreate: assign names based on mac address by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/29/2013 04:20 PM, Oskari Saarenmaa wrote:
> 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.
> 

It's easy to be resolved. give the parentVeth and containerVeth a name by default.

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]