[Libvir] default hypervisor selection

[Daniel P. Berrange]

On Thu, Feb 21, 2008 at 03:26:08PM +0000, Mark McLoughlin wrote:
> On Thu, 2008-02-21 at 14:57 +0000, Daniel P. Berrange wrote:
> > On Thu, Feb 21, 2008 at 02:51:20PM +0000, Richard W.M. Jones wrote:
> > > 
> > > I'm mostly with Dan Berrange here.  Surely an environment variable is
> > > the right thing to do, and then later we can add some advanced probing
> > > if the environment variable alone doesn't satisfy users.
> > > 
> > > The only problem I see is making the NULL case unpredictable or
> > > introducing unreproducible bugs.  But I guess that's not very likely.
> > 
> > I agree - possible, but not likely too bad - I think we'll easily have a
> > net win thanks to a more pleasant default end user experiance.
> 
> 	(Re-suggesting something that was shot down before just in case it
> makes more sense to people this time around :-)
> 
> 	I've never liked the fact that the individual drivers are exposed in
> the API and to the user. IMHO, the default behaviour for open(NULL),
> virsh, virt-manager etc. should be to talk to *all* drivers and
> aggregate the results.
> 
> 	When you define a VM, that's the only time you should care about Xen
> vs. KVM etc. After that, it should just be a question of referring to a
> VM by name.
> 
> 	The only time you should really need to specify a URI is when
> connecting to a remote host, IMHO.
> 
> 	Adding a heuristic to select sensible driver by default won't help
> someone running e.g. KVM VMs and linux containers on the same host,
> which I don't think is such a crazy notion.

Applications can explicitly connect to multiple drivers as desired.

> 	Yes, you'd be trying to merge overlapping namespaces, but some ideas on
> that front:
> 
>   - If you simply prevent someone defining a VM using the same name as 
>     an existing VM defined via another driver, that gets you 90% there

Which we're unable to prevent. We are fundamentally dealing with different
namespaces with both 'name' and 'id' values - any attempt to merge them
is doomed to failure. The only globally unique identifier we have is UUID.

>   - Never aggregate a user's private namespace with the system namespace
>     - e.g. for a normal user, an open(NULL) connection would only show 
>     the user's own VMs and we'd have another URI (or e.g. a virsh 
>     --system switch) for dealing with system-level VMs

> 
>   - If someone connects directly to a driver, or goes behind libvirt's 
>     back, and creates a VM with conflicting names, then just return an 
>     error if someone tries to perform an operation using the 
>     conflicting name ... and force the user to again connect to the 
>     specific driver or go behind libvirt's back

The name namespace is not under libvirt's control, and is fundamentally
going to clash between virtualization backends. We merely have illusion
of control wrt to QEMU because currently all QEMU guests are directly
managed by libvirt - even this won't neccessarily be true long term
if we implement the ability to manage externally started QEMU instances.

>   - Also, figure out some way to deprecate the VM "id" attribute which 
>     is the most obvious point of conflict ... name and uuid should be 
>     enough identifiers, surely

The ID number is very convenient because it is short & simple and unique
over the lifetime of a VM. The name is also unique, but name can change
during the lifetime of a VM.

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