Sorry to come back on this. How are the different threads of the libvirt daemon separated ? I understand that there are 2 separate threads running that are forked. There are also 4 more that appear to be threads. Is that correct ? Now, the virEvents main polling loop is running in a forked thread, it has no access to worker threads that where created through virsh for example Is that correct ? Last, if a VM needs something to watch over the state of its network devices, a separate thread needs to be created to do that because the VMs libvirt daemon thread can't make use of the virEvent functions without creating a new poll-loop thread ? Best regards, D.Herrendoerfer <herrend at de dot ibm dot com > <d.herrendoerfer at herrendoerfer dot name> On Dec 22, 2011, at 6:04 PM, Dirk Herrendoerfer wrote:
Hi all,
I'm trying to get libvirt to re-associate lost connections when a vepa connection is lost due to a switch error, or lldpad restart.
My take was to use the virtEvent infrastructure to poll for messages on a netlink socket and then restart the association if the message indicates that a link came back up.
I ran into a problem, that if I start the polling netlink event from the daemon thread I would get the file events an the netlink messages, but I cannot configure the event handler because the rpc client threads and the daemon do not share the same address space.
Is there a way to get file events in the VMs setup code so I can register a callback at VM initialization time to receive netlink messages and restart association if needed ?
Best regards,
D.Herrendoerfer <herrend at de dot ibm dot com > <d.herrendoerfer at herrendoerfer dot name>
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list