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.
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
- 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
- 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
Cheers,
Mark.
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list