(In reply to Daniel Berrange from comment #0)
> We must change to open netcf once per libvirtd.

Just adding a simple state driver that saves the fd for the netcf socket, then makes sure that all access to that socket is protected by a mutex should be enough, right? Let me know if I'm missing something obvious...

> The slight
> complication here is that we'll need a way to refresh the NIC configs
> periodically, so we can cope with changes behind libvirt's back.

The virInterface calls don't cache any information from netcf and if I recall correctly, the cache that netcf keeps is sent back to augeas each time something is requested from netcf (see the function get_augeas() in the netcf source) and augeas checks the modification dates of each file and only rereads those files that have been touched since the data was last gathered. So I don't think this will be (or is) a problem.

You'll notice this updating in action if you run virt-manager and look at the list of interfaces while adding/removing interfaces - they show up almost immediately.

(In reply to Laine Stump from comment #2)
> (In reply to Daniel Berrange from comment #0)
> > We must change to open netcf once per libvirtd.
> 
> Just adding a simple state driver that saves the fd for the netcf socket,
> then makes sure that all access to that socket is protected by a mutex
> should be enough, right? Let me know if I'm missing something obvious...

Well if by 'fd', you mean the 'struct netcf' instance, then yes. The APIs already have locking present, since even a single virConnectPtr needs thread protection.

> > The slight
> > complication here is that we'll need a way to refresh the NIC configs
> > periodically, so we can cope with changes behind libvirt's back.
> 
> The virInterface calls don't cache any information from netcf and if I
> recall correctly, the cache that netcf keeps is sent back to augeas each
> time something is requested from netcf (see the function get_augeas() in the
> netcf source) and augeas checks the modification dates of each file and only
> rereads those files that have been touched since the data was last gathered.
> So I don't think this will be (or is) a problem.
> 
> You'll notice this updating in action if you run virt-manager and look at
> the list of interfaces while adding/removing interfaces - they show up
> almost immediately.

Ah, I thought that it only parsed the ifcfg-XXX files when you did 'netcf_init', but if that's wrong, then this bug is easy.

(In reply to Daniel Berrange from comment #3)
> (In reply to Laine Stump from comment #2)
> > (In reply to Daniel Berrange from comment #0)
> > > We must change to open netcf once per libvirtd.
> > 
> > Just adding a simple state driver that saves the fd for the netcf socket,
> > then makes sure that all access to that socket is protected by a mutex
> > should be enough, right? Let me know if I'm missing something obvious...
> 
> Well if by 'fd', you mean the 'struct netcf' instance, then yes. The APIs
> already have locking present, since even a single virConnectPtr needs thread
> protection.

Yeah, that's what I meant. Not enough sleep lately :-)

Good, I thought that was all it would take but wanted to make sure before promising anything. I agree that this will be easy to fix, so I'll get to it as soon as possible (not until next week, though).

The following two patches have been pushed upstream to resolve this bug:

commit 4c5fa430972246b82d60c875654fc57e48adfcce
Author: Laine Stump <laine>
Date:   Tue Aug 27 12:26:48 2013 -0400

    rename "struct interface_driver" to virNetcfDriverState

commit 822fe1367dd55e3de7c3c044ee02fd733ab3415a
Author: Laine Stump <laine>
Date:   Wed Aug 28 12:56:21 2013 -0400

    netcf driver: use a single netcf handle for all connections

The latest libvirt will only open one netlink for netcf, other than previous libvirt will open multiple netlinks, just like:

1. prepare a test script
# cat test.py 
import time
import libvirt
con=[]
for i in range(1,20):
	con.append(libvirt.open(None))
time.sleep(1000)

2. for previous libvirt
# rpm -q libvirt
libvirt-1.1.1-4.el7.x86_64

# lsof -p `pidof libvirtd` | grep netlink
libvirtd 5136 root   13u  netlink                          0t0      45202 KOBJECT_UEVENT
libvirtd 5136 root   14u  netlink                          0t0      45201 ROUTE
libvirtd 5136 root   17u  netlink                          0t0      38689 KOBJECT_UEVENT

# python test.py &

# lsof -p `pidof libvirtd` | grep netlink
libvirtd 5136 root   13u  netlink                          0t0      45202 KOBJECT_UEVENT
libvirtd 5136 root   14u  netlink                          0t0      45201 ROUTE
libvirtd 5136 root   17u  netlink                          0t0      38689 KOBJECT_UEVENT
libvirtd 5136 root   21u  netlink                          0t0      39627 ROUTE
libvirtd 5136 root   24u  netlink                          0t0      39632 ROUTE
libvirtd 5136 root   27u  netlink                          0t0      43714 ROUTE
libvirtd 5136 root   30u  netlink                          0t0      38702 ROUTE
libvirtd 5136 root   33u  netlink                          0t0      44446 ROUTE
libvirtd 5136 root   36u  netlink                          0t0      39656 ROUTE
libvirtd 5136 root   39u  netlink                          0t0      43724 ROUTE
libvirtd 5136 root   42u  netlink                          0t0      38717 ROUTE
libvirtd 5136 root   45u  netlink                          0t0      38721 ROUTE
...

3. for latest libvirt
# rpm -q libvirt
libvirt-1.1.1-5.el7.x86_64

# lsof -p `pidof libvirtd` | grep netlink
libvirtd 5402 root   13u  netlink                          0t0      44751 ROUTE
libvirtd 5402 root   14u  netlink                          0t0      44752 KOBJECT_UEVENT
libvirtd 5402 root   17u  netlink                          0t0      46348 KOBJECT_UEVENT
libvirtd 5402 root   20u  netlink                          0t0      38790 ROUTE

# python test.py &

# lsof -p `pidof libvirtd` | grep netlink
libvirtd 5402 root   13u  netlink                          0t0      44751 ROUTE
libvirtd 5402 root   14u  netlink                          0t0      44752 KOBJECT_UEVENT
libvirtd 5402 root   17u  netlink                          0t0      46348 KOBJECT_UEVENT
libvirtd 5402 root   20u  netlink                          0t0      38790 ROUTE


This fix can handle netlink multi-opened problem, so I change the status to VERIFIED.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.