On Mon, Apr 07, 2014 at 10:24:21AM -0600, Eric Blake wrote:
> On 04/07/2014 09:59 AM, Daniel P. Berrange wrote:
>
> >>
> >> The more I think about it the more it makes me wonder if we should
> >> learn libvirt return list of all supported/enabled drivers.
> >> Something like:
> >>
> >> char **virGetDrivers(virConnectPtr conn);
> >>
> >> if conn == NULL, the client side drivers are returned, e.g.
> >> {"remote", "vbox", NULL}, if conn is not NULL, the daemon side
> >> drivers are returned, e.g. {"qemu", "bhyve", "lxc", NULL}. But maybe
> >> I'm over thinking it too much.
> >
> > You have a chicken+egg problem there in that you need to open a connection
> > in order to invoke the API to get the list of connections you can open.
>
> Although we have been talking about a meta-connection, for doing things
> such as changing log settings, querying how many normal connections are
> open, and so forth. The management connection could provide this
> information. On the other hand, the idea of a management connection is
> that is requires different privileges for connecting, so it might not be
> the idea solution.
Yeah I don't think the mgmt connection fits here because of the privilege
level mismatch.
For local nodes we have "NULL" to mean auto-detect.
For remote nodes we do actually support 'remote+tcp://somehost' as a way
to auto-detect the hypervisor, but we don't correctly resolve this into
the real URI once connected (ie virConnectGetURI should return a real
URI, not remote URI)
That all said, I'm not sure I neccessarily agree with Cole's original
proposition that virt-manager shouldn't display "BHyve" as a choice
by default. It feels somewhat discriminatory against FreeBSD to say
that only popular Linux drivers can be visible in the UI by default.
I tend to feel that virt-manager as provided by "upstream" should be
willing to display any libvirt URI by default, providing it is functional
enough for virt-manager to actually work.
If distros wish to cut this back to a subset (eg only KVM + LXC on
Fedora) then that could be done as part of the distro vendor's
packaging.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
