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

[D. Herrendoerfer]

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