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