[Libvir] default hypervisor selection

[Daniel P. Berrange]

On Thu, Feb 21, 2008 at 09:26:38AM -0500, Daniel Veillard wrote:
>   While going though the ovirt installation steps I got annoyed with
> the need to add "-c qemu:///system" each time we are trying to start a
> virsh command if using KVM. The dfault setup is basically to assume
> a Xen hypervisor if the URI is not specified, this is glued in the
> do_open internal opening routine associated to the opening of connections:
> 
> --------------------------------------
> static virConnectPtr
> do_open (const char *name,
>          virConnectAuthPtr auth,
>          int flags)
> {
>     int i, res;
>     virConnectPtr ret = NULL;
>     xmlURIPtr uri;
> 
>     /* Convert NULL or "" to xen:/// for back compat */
>     if (!name || name[0] == '\0')
>         name = "xen:///";
> --------------------------------------
> 
>   In one hand this is the default behaviour of the library, but
> in my opinion it's not very smart. We should be able to be smarter than
> that, for example:
> 
>    - if /proc/xen doesn't exist (on linux, or /dev/xen on Solaris) well
>      we should not do that we are pretty sure we will get an error when
>      trying to connect
>    - if /proc/vz is present, well it's very likely that if the kernel
>      has been compiled with OpenVZ support, it's likely to be used as the
>      default virtualization
>    - if there is a kvm module loaded well we should probably use
>      qemu:///system if running as root or qemu:///session otherwise
> 
> I guess on Solaris an easy heuristic would allow to pick the right
> hypervisor by default too.
> At some point we may have multiple hypervisor support simultaneously
> on a linux system thanks to pv_ops, but right now it doesn't make too
> much sense to force a default Xen connection even when we know it won't
> work. 
> For a virsh specific solution there is the VIRSH_DEFAULT_CONNECT_URI
> environment variable, but it's not really user friendly and not very
> generic,

I've proposed that we make this generic :

http://www.redhat.com/archives/libvir-list/2008-January/msg00234.html

I never got around to fixing the patch to also address the virsh issue
Soren raised, but I think we should do this env var.

>  What do people think ? I would be tempted to provide a patch to change
> do_open() behaviour on linux in the case name is NULL or "", and 
> then check what hypervisor might be present and running,

I think it is worthwhile - the 'default to Xen' behavious is a major cause 
of pain for people initially using libvirt, particularly since KVM is
becoming the defacto standard for Linux platforms. I'd see the following
levels of customization:

  - If a non-NULL  URI is passed in virConnectOpen, use that
  - Else if LIBVIRT_DEFAULT_URI is set use that URI
  - Else probe each registered driver in order until one succeeds

For the latter I think we could add a 'probe' method to the internal driver
API table. Then we can just call 'probe' on each driver in turn until we 
find one which is  available on the system. 

At the same time it could be worth having a public API to 'detect drivers'
which will call probe for each driver and return a list of all drivers
which are available. This allows an app to easily ask libvirt what it
supports - because long term we'll definitely get hosts supporting many
drivers at once.  We can also advertise this list of supported drivers
using the Avahi mDNS broadcasts we do from the remote daemon.

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