[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] PATCH 2/2: Support QEMU (+KVM) in libvirt



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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]