On 03/23/2015 03:43 PM, Laine Stump wrote: > Just as it is possible to delete a bridge device with the netlink > RTM_DELLINK message, one can be created with the RTM_NEWLINK > message. Because of differences in the format of the message, it's not > as straightforward as with virNetlinkDelLink() to create a single > utility function that can be used to create any type of interface, so > the new netlink version of virNetDevBridgeCreate() does its own > construction of the netlink message and calls virNetlinkCommand() > itself. > > This doesn't provide any extra functionality, just provides symmetry > with the previous commit. > > NB: We *could* alter the API of virNetDevBridgeCreate() to take a MAC > address, and directly program that mac address into the bridge (by > adding an IFLA_ADDRESS attribute, as is done in > virNetDevMacVLanCreate()) rather than separately creating the "dummy > tap" (e.g. virbr0-nic) to maintain a fixed mac address on the bridge, > but the commit history of virnetdevbridge.c shows that the presence of > this dummy tap is essential in some older versions of the kernel > (between 2.6.39 and 3.1 or 3.2, possibly?) to proper operation of IPv6 > DAD, and I don't want to take the chance of breaking something that I > don't have the time/setup to test (my RHEL6 box is at kernel > 2.6.32-544, and the next lowest kernel I have is 3.17) > --- > src/util/virnetdevbridge.c | 78 +++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 77 insertions(+), 1 deletion(-) > What's here seems reasonable - I don't have "history" on my side to answer the older versions of the kernel query... One other difference between this and virNetDevMacVLanCreate is the error path that handles *retry if the name is already in use... Whether that's a worthy addition here or not is your call... ACK - John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list