Re: [libvirt] [RFC v2][remote]
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
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|