On Tue, Jan 09, 2007 at 02:57:24PM +0000, Daniel P. Berrange wrote:
On Tue, Jan 09, 2007 at 09:44:44AM -0500, Daniel Veillard wrote:
On Fri, Jan 05, 2007 at 09:18:53PM +0000, Daniel P. Berrange wrote:
The attached patch provides a new driver backend for libvirt which allows management of QEMU instances by talking to the libvirt QEMU daemon. It basically just marshalls libvirt API calls onto the wire & de-marshalls the reply. All the interesting functionality stuff is in the daemon.
Okay, but I'm getting a bit lost about the potential daemons running, there one can be autostarted, in the previous patch we also potentially fork(fork(daemon)) so I'm wondering how many process are actually running in the end, maybe I will need a couple of pictures, like in the current architecture page http://libvirt.org/architecture.html (which will have to be updated too :-)
There's two ways its launched:
- The session bus is auto-launched by libvirt. In this scenaro, libvirt does the double fork() magic to dis-inherit the libvirt_qemud process - The system bus is started manually. In this case, it runs in foreground unless you use the --daemon command line argument to make it do the double-fork() into background.
okay, and the former auto exits while the latter sticks until stopped I there any way we can avoid /etc/init.d/libvirt <grin/> ?
Shouldn't qemud_internal.c gets its own error reporting function like the other _internal.c which does the right stuff, I only spotted returns of error values, and this is linked to the client binary so this seems to be missing, right ?
The only errors that should be occurring in qemud_internal.c are two classes:
- Data transport errors (eg, failure to connect, TLS failures, etc) - Errors forwarded back from the daemon over the wire.
I already deal with the latter. The former probably needs a little more work.
okay
RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.41 diff -u -p -r1.41 virsh.c --- src/virsh.c 22 Nov 2006 17:48:29 -0000 1.41 +++ src/virsh.c 5 Jan 2007 21:09:08 -0000 @@ -292,7 +292,7 @@ cmdConnect(vshControl * ctl, vshCmd * cm
if (ctl->name) free(ctl->name); - ctl->name = vshCommandOptString(cmd, "name", NULL); + ctl->name = vshStrdup(ctl, vshCommandOptString(cmd, "name", NULL));
I'm a bit lost on that one, was that a separate bug ? We switch from a static string to dynamically allocated one, right ?
Opps, this is compeltely unrelated to QEMU - its a general bug. The string from vshCommandOptString is just a pointer to its internal buffer. This is free'd next time user enters a command in virsh. So by storing it in ctl->name we keep a pointer to a free'd string, with predictable SEGV a short while later. Simply dup'ing the string is enough.
okay, logical. maybe fix it as a separate commit :-)
@@ -268,6 +268,9 @@ virDefaultErrorFunc(virErrorPtr err) case VIR_FROM_RPC: dom = "XML-RPC "; break; + case VIR_FROM_QEMUD: + dom = "QEMUD "; + break; } if ((err->dom != NULL) && (err->code != VIR_ERR_INVALID_DOMAIN)) { domain = err->dom->name;
I guess some new error code will need to be added too once quemud_internal.c is being updated ... Hum, how do we process errors provided by the server ?
The libvirt_qemud daemon includes <libvirt/virterror.h> and sends back the appropriate error codes over the wire, along with a message. This is used to call __virRaiseError - see the qemudPacketError() function at the top of the qemud_internal.c file - this function is called whenver the wire protocol gives back an unexpected result
So QEmu/KVM runtime generates no new errors ? Sounds surprizing to me ... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/