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