Re: [libvirt] PATCH: Misc fixes to events code
Daniel P. Berrange wrote on 11/04/2008 05:05 PM: Well lets just start with STARTED/STOPPED from xenstore, and possibly try ADDED/REMOVED using inotify on /etc/xen or /var/lib/xend/domains. These are what virt-manager cares about the most. The others are just a nice-to-have. Perhaps I just can't see it, but is there already mechanism where I can look up a domain (virDomainPtr) given a config filename? I'd rather not re-invent the wheel if this is already written... I think that there should be code to do this somewhere in the xm_internal file when listing defined (but not running) domains...but I'm just not seeing it Ben -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Misc fixes to events code
Daniel P. Berrange wrote on 11/04/2008 02:56 PM: A couple more things I've not fixed but are on the todo list - THe QEMU driver doesn't emit the ADDED or REMOVED events for VMs which virt-manager requires in order to fully avoid polling. Not to derail this topic from your patch...but this comment somewhat relates to the xen driver changes I've been looking at. Currently, I can detect domains being externally created, and destroyed via a xenstore watch. That said - there is no mechanism like @introduceDomain/@releaseDomain for the rest of domain lifecycle events. As far as I can tell, these control events such as pause/resume, etc are controlled via the xen control(xc) library. I saw nothing in this library, or the xend python code that would indicate that anything is written in xenstore. So - I can look into plumbing up the rest of the events in the driver without this. This would mean that it could emit events when issued by libvirt, but would only issue STARTED, and STOPPED events from external influences like 'xm' Thoughts? Ben -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Misc fixes to events code
On Tue, Nov 04, 2008 at 03:31:56PM -0500, Ben Guthro wrote: Daniel P. Berrange wrote on 11/04/2008 02:56 PM: A couple more things I've not fixed but are on the todo list - THe QEMU driver doesn't emit the ADDED or REMOVED events for VMs which virt-manager requires in order to fully avoid polling. Not to derail this topic from your patch...but this comment somewhat relates to the xen driver changes I've been looking at. Currently, I can detect domains being externally created, and destroyed via a xenstore watch. That said - there is no mechanism like @introduceDomain/@releaseDomain for the rest of domain lifecycle events. As far as I can tell, these control events such as pause/resume, etc are controlled via the xen control(xc) library. I saw nothing in this library, or the xend python code that would indicate that anything is written in xenstore. So - I can look into plumbing up the rest of the events in the driver without this. This would mean that it could emit events when issued by libvirt, but would only issue STARTED, and STOPPED events from external influences like 'xm' Hmm, nothing is ever as simple as it first seems in the Xen world :-) So, first off all there are two possible backends for libvirt Xen - Old Xen 3.0.4. The 'xm_internal.c' file manages /etc/xen config files for inactive VMs directly - New Xen = 3.0.4. The 'xend_internal.c' file use Xen SEXPR API for managing inactive VMs. XenD indirectly stuffs them into the directory /var/lib/xend/domains/ In both cases we can only figure out STARTED/STOPPED from hypervisor xenstored events. In the first case, we could use inotify to get notication of files in /etc/xen being added/removed and thus do the ADDED/REMOVED events. We could actually also use inotify on /var/lib/xend/domains/ though that feels a little more evil since that's a private directory to XenD. This still doesn't give us any pause/resume/save/restore events. The latter two would just in fact show up as STARTED/STOPPED events. Then there is XenAPI in Xen = 3.1.0. We don't currently use XenAPI at all, and I'm not up2date on its level of functionality, but in the original scope it was intended to provide full event notification capabilities for VMs. If the XenAPI event stuff was ever implemented, then perhaps we should make use of that, and say older non-XenAPI versions only get a limited sub-set of our events ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Misc fixes to events code
Daniel P. Berrange wrote on 11/04/2008 04:42 PM: Then there is XenAPI in Xen = 3.1.0. We don't currently use XenAPI at all, and I'm not up2date on its level of functionality, but in the original scope it was intended to provide full event notification capabilities for VMs. If the XenAPI event stuff was ever implemented, then perhaps we should make use of that, and say older non-XenAPI versions only get a limited sub-set of our events ? ugh. I tried using xenapi about 8 months ago... Back then - it was messy, and underdocumented, IMO - and a large reason why started to look at libvirt in the first place. It seemed...shoe-horned into an existing scheme, with a new API. There was some effort a little while back to shore this up...but I don't know where, or if that really went anywhere. I think it would be a mistake to integrate that project into this one. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Misc fixes to events code
On Tue, Nov 04, 2008 at 04:51:27PM -0500, Ben Guthro wrote: Daniel P. Berrange wrote on 11/04/2008 04:42 PM: Then there is XenAPI in Xen = 3.1.0. We don't currently use XenAPI at all, and I'm not up2date on its level of functionality, but in the original scope it was intended to provide full event notification capabilities for VMs. If the XenAPI event stuff was ever implemented, then perhaps we should make use of that, and say older non-XenAPI versions only get a limited sub-set of our events ? ugh. I tried using xenapi about 8 months ago... Back then - it was messy, and underdocumented, IMO - and a large reason why started to look at libvirt in the first place. It seemed...shoe-horned into an existing scheme, with a new API. Yes, I was never a fan of it either, hence why we've tried to make do with the SEXPR api whereever possible. There was some effort a little while back to shore this up...but I don't know where, or if that really went anywhere. I think it would be a mistake to integrate that project into this one. Well lets just start with STARTED/STOPPED from xenstore, and possibly try ADDED/REMOVED using inotify on /etc/xen or /var/lib/xend/domains. These are what virt-manager cares about the most. The others are just a nice-to-have. If someone really badly wants the other events in the future, we can consider a proof of concept of other ideas like XenAPI at that time... Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Misc fixes to events code
These look good to me
+1
Daniel P. Berrange wrote on 11/04/2008 02:56 PM:
I'm trying out the new events code with virt-manager and stumbled on some
minor bugs
- The python binding forgot to call LIBVIRT_BEGIN_ALLOW_THREADS,
LIBVIRT_END_ALLOW_THREADS, LIBVIRT_ENSURE_THREAD_STATE or
LIBVIRT_RELEASE_THREAD_STATE which meant virt-manager crashed
and burned in a heap of python interpretor state corruption [1]
- The API docs extracted assumes that enums without explicit value
assignements started from 1 instead of 0. This caused an off-by-1
error for all the VIR_DOMAIN_EVENT_* constants in the generated python
code.
I briefly toyed with fixing docs/apibuild.py enum handling but then instead
decided to just change libvirt.h to give explicit values.
With these two fixes and some hacks to virt-manager, I've got the
events triggering display state refreshes.
A couple more things I've not fixed but are on the todo list
- THe QEMU driver doesn't emit the ADDED or REMOVED events for VMs
which virt-manager requires in order to fully avoid polling.
- The VIR_EVENT_* constants aren't included in python, because the
API docs can't cope with enum value asignments looking like
(1 0) (ie fails to parse the left-shifts)
Regards,
Daniel
[1] FYI, i'm using the libvirt-glib python binding in virt-manager
http://libvirt.org/hg/libvirt-glib/ which is slightly bad too
by not doing glib thread locking calls, but we're lucky because
libvirt.so doesn't invoke any glib calls itself from the event
callback context.
Index: python/libvir.c
===
RCS file: /data/cvs/libvirt/python/libvir.c,v
retrieving revision 1.43
diff -u -p -r1.43 libvir.c
--- python/libvir.c 31 Oct 2008 10:13:45 - 1.43
+++ python/libvir.c 4 Nov 2008 19:45:42 -
@@ -1537,29 +1537,33 @@ libvirt_virConnectDomainEventCallback(vi
PyObject *pyobj_ret;
PyObject *pyobj_conn_inst = (PyObject*)opaque;
-PyObject *pyobj_dom = libvirt_virDomainPtrWrap(dom);
+PyObject *pyobj_dom;
PyObject *pyobj_dom_args;
PyObject *pyobj_dom_inst;
PyObject *dom_class;
+int ret = -1;
+
+LIBVIRT_ENSURE_THREAD_STATE;
/* Create a python instance of this virDomainPtr */
+pyobj_dom = libvirt_virDomainPtrWrap(dom);
pyobj_dom_args = PyTuple_New(2);
if(PyTuple_SetItem(pyobj_dom_args, 0, pyobj_conn_inst)!=0) {
printf(%s error creating tuple,__FUNCTION__);
-return -1;
+goto cleanup;
}
if(PyTuple_SetItem(pyobj_dom_args, 1, pyobj_dom)!=0) {
printf(%s error creating tuple,__FUNCTION__);
-return -1;
+goto cleanup;
}
Py_INCREF(pyobj_conn_inst);
dom_class = getLibvirtDomainClassObject();
if(!PyClass_Check(dom_class)) {
printf(%s dom_class is not a class!\n, __FUNCTION__);
-return -1;
+goto cleanup;
}
pyobj_dom_inst = PyInstance_New(dom_class,
@@ -1571,7 +1575,7 @@ libvirt_virConnectDomainEventCallback(vi
if(!pyobj_dom_inst) {
printf(%s Error creating a python instance of virDomain\n,
__FUNCTION__);
PyErr_Print();
-return -1;
+goto cleanup;
}
/* Call the Callback Dispatcher */
@@ -1586,12 +1590,15 @@ libvirt_virConnectDomainEventCallback(vi
if(!pyobj_ret) {
printf(%s - ret:%p\n, __FUNCTION__, pyobj_ret);
PyErr_Print();
-return -1;
} else {
Py_DECREF(pyobj_ret);
-return 0;
+ret = 0;
}
+
+cleanup:
+LIBVIRT_RELEASE_THREAD_STATE;
+return -1;
}
static PyObject *
@@ -1620,10 +1627,14 @@ libvirt_virConnectDomainEventRegister(AT
Py_INCREF(pyobj_conn_inst);
+LIBVIRT_BEGIN_ALLOW_THREADS;
+
ret = virConnectDomainEventRegister(conn,
libvirt_virConnectDomainEventCallback,
(void *)pyobj_conn_inst);
+LIBVIRT_END_ALLOW_THREADS;
+
py_retval = libvirt_intWrap(ret);
return (py_retval);
}
@@ -1650,8 +1661,12 @@ libvirt_virConnectDomainEventDeregister(
conn = (virConnectPtr) PyvirConnect_Get(pyobj_conn);
+LIBVIRT_BEGIN_ALLOW_THREADS;
+
ret = virConnectDomainEventDeregister(conn,
libvirt_virConnectDomainEventCallback);
+LIBVIRT_END_ALLOW_THREADS;
+
Py_DECREF(pyobj_conn_inst);
py_retval = libvirt_intWrap(ret);
return (py_retval);
@@ -1679,13 +1694,15 @@ libvirt_virEventAddHandleFunc (int fd A
PyObject *cb_args;
PyObject *pyobj_args;
+LIBVIRT_ENSURE_THREAD_STATE;
+
/* Lookup the python callback */
python_cb = PyDict_GetItemString(getLibvirtDictObject(),
eventInvokeHandleCallback);
if(!python_cb) {
printf(%s
