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