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

Re: [libvirt] [PATCH v5 2/2] Add de-association handling to macvlan code




On Feb 29, 2012, at 5:36 PM, Laine Stump wrote:

On 02/24/2012 09:29 AM, D. Herrendoerfer wrote:
The callback mechanism is not re-armed when libvirt is restarted now.
The reason is: lldpad remembers who sent the associate by pid - since
in theory there could be multiple agents performing associations.
So if the libvirt pid changes, there is little we can do now.

This seems very problematic to me - it is assumed that libvirt can be
restarted at any time with no ill effects, and restarting libvirt is
often suggested as a solution to clearing up problems (e.g. if some
other program stomps on libvirt's iptables rules).


Yes.  That's the way it should be.

What can be done to eliminate this problem? Perhaps there needs to be a "re-associate" message - it could be sent each time libvirt restarts for
each association it's currently tracking.


I love the idea. When libvirt starts up. It probes for running VM with vepa
associations, sends one associate and re-armes the callback.
This would even help situations when the switch infrastructure is out- of-sync
with the host system.

But how ? Put a special setup function in virnetdevmacvlan.c and call it from domain_conf once all info has been collected and the VM is in running state ?

Dirk H

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


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