On Fri, Apr 07, 2017 at 09:31:45AM +0200, Michal Privoznik wrote:
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.
That doesn't make sense - the shared network driver should be operational
for Xen - it certainly worked in the past.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://entangle-photo.org -o-
http://search.cpan.org/~danberr/ :|