On 18.06.2015 12:00, Daniel P. Berrange wrote: > 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. Ok, I'll take it. > > Regards, > Daniel > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list