[libvirt] [PATCH v3 0/7] Provide an standard asyncio event loop impl

Michal Privoznik mprivozn at redhat.com
Fri Apr 7 07:31:45 UTC 2017


On 04/06/2017 10:47 PM, Wojtek Porczyk wrote:
> On Tue, Apr 04, 2017 at 03:31:27PM +0100, Daniel P. Berrange wrote:
>> $ python3 ./examples/event-test.py --loop=asyncio --timeout=30 qemu:///session
>
> Thank you for this update. I tested it backported to 3.1.0 with xen:/// using
> event-test.py and also with our own code. Looks good to me.
>
>
> I encountered one small problem, which I believe is orthogonal to the patch series:
>
> On Tue, Apr 04, 2017 at 03:31:32PM +0100, Daniel P. Berrange wrote:
>> diff --git a/examples/event-test.py b/examples/event-test.py
>> index 751a140..ac9fbe1 100755
>> --- a/examples/event-test.py
>> +++ b/examples/event-test.py
>
>> +    netcallbacks = []
>> +    netcallbacks.append(vc.networkEventRegisterAny(None, libvirt.VIR_NETWORK_EVENT_ID_LIFECYCLE, myNetworkEventLifecycleCallback, None))
>
> With vc = libvirt.open('xen:///') and with libvirt{,-python}-3.1.0 this line causes an
> exception:
>
>   libvirt.libvirtError: this function is not supported by the connection driver: virConnectNetworkEventRegisterAny

That's because we don't have a network driver for XEN. Usually, for 
stateful drivers (those which require daemon to run, e.g. qemu, lxc, ..) 
they can use our own bridge driver for network (it creates a bridge to 
which domain NICs are plugged in). However, then we have bunch of 
stateless driver for which libvirt is just a wrapper over their APIs. 
For those we would need a separate network driver that does the API 
wrapping. And it looks like there's none for XEN. Not sure whether 
there's something to wrap though. I mean I've no idea what XEN 
networking capabilities are.

But what we can do here is to surround networkEvenRegisterAny() call 
with try {} except () block and ignore ENOSUPP error.

Michal




More information about the libvir-list mailing list