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,
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,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list