On Thu, Jun 18, 2015 at 11:05:13AM +0300, Nikolay Shirokovskiy wrote: > Hello. > > I'll reword the previous letter. > > In libvirt we have connection close callback for drivers that have persistent > internal connection to notify client that this connection is closed. Vz driver > has internal persistent connection so I wanted to add support of this callback > to vz driver. Now clients with connections urls like 'vz:///system' are > notified of connection close event. But if connection url is like > 'vz+<transport>://system we have a remote driver between client and vz driver > and client is not notified as remote driver doesn't handle this event. > > The problem is that remote driver can't just relay this event as domain one > as there is no means to do it in driver interface. The quick fix is to close > the connection between daemon and remote driver from daemon side is case of > close event. This will trigger connection close event in remote driver and > client finally will be notified. I doubt this is a good approach as it looks > like we forced to take specific action of closing connection to daemon only due > to lack of appropriate driver interface. > > So the proposition is to move connection close event > registration/deregistration/notifying to driver level so remote driver could > relay them just like say domain events. Ok, I think I understand the problem you're getting at. The parallels driver is stateless, so it usually executes in the context of the app linking to libvirt.so As such you would normally just emit the connection close event directly in your driver code. Even though it is stateless, you have the option of connecting via libvirtd, which allows for remote access. Normally the remote_driver.c client deals with emitting the connection close event when the connection to libvirtd goes down, but you want to be able to emit events from the parallels driver, even when libvirtd conncetion is still operational. This is indeed a new scenario we've not had to deal with before, but it sounds entirely reasonable to want todo this. If we moved the registration/deregistration to the driver level, then we could also add RPC calls for reg/dereg, that could be forwarded onto the remotely running driver. We'd also need an RPC event added to do the notification. The remote driver client would receive the events and emit them. I think this is all doable, so if you want to propose patches, go ahead.

Regards, Daniel