Re: [Libvir] default hypervisor selection
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 -=|