When trying to start / stop a domain with macvtap device (direct type of
interface) having a device description like this one here
then I see netlink related errors when a 'virsh edit' session is
happening at the same time.
So, to reproduce this error you should try the following (on a ke
On Mon, Feb 14, 2011 at 02:34:28PM -0500, Stefan Berger wrote:
> When trying to start / stop a domain with macvtap device (direct
> type of interface) having a device description like this one here
>
>
>
>
>
> then I see netlink related errors when a 'virsh edit' session is
> happening at the
On 02/14/2011 02:51 PM, Daniel P. Berrange wrote:
This approach feels like a nasty hack to me and potentially still leaves
us with a problem in netcf which is also using netlink sockets. I think
we need to get a clearer picture of what the root cause is before going
for this kind of patch
Correc
On 02/14/2011 03:30 PM, Stefan Berger wrote:
On 02/14/2011 02:51 PM, Daniel P. Berrange wrote:
This approach feels like a nasty hack to me and potentially still leaves
us with a problem in netcf which is also using netlink sockets. I think
we need to get a clearer picture of what the root cause
On 02/14/2011 05:22 PM, Stefan Berger wrote:
On 02/14/2011 03:30 PM, Stefan Berger wrote:
On 02/14/2011 02:51 PM, Daniel P. Berrange wrote:
This approach feels like a nasty hack to me and potentially still
leaves
us with a problem in netcf which is also using netlink sockets. I think
we need
On 02/14/2011 11:43 PM, Stefan Berger wrote:
One definte problem in libnl is that the 'port allocation'
(generate_local_port()) is not thread-safe, even though I think it's
the library's responsibility to lock, not libvirt introducing a lock
that we need to grab before calling into netcf and gr
