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