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

[Daniel P. Berrange]

On Tue, Jan 09, 2007 at 10:19:17AM -0500, Daniel Veillard wrote:
> 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/> ?

I'm not sure we can really - if the admin wants to allow remote connections
when we need to start the daemon ahead of time to make it listen on TCP port.
It means we also avoid a setuid() binary - I think its preferrable that for
QEMU users's have to stick with the personal qemud://session instance unless
the admin explicitly turns on the qemu:///system instance.

> > > >              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 ...

Mostly I've just encoded everything as a generic 'internal error'. There is
definitely scope for adding some new specific error codes - particular for
dealing with inactive domains  - that would help the same code in Xen
backend too.

Dan. 
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|