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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list