[libvirt] [RFC v2][remote]

[Nikolay Shirokovskiy]

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
>