Hi Dan, So, what you describe is similar to what I was suggesting, but the difference from what I was suggesting means that it does nothing for the actual problem :-) On Tue, 2007-01-16 at 15:57 +0000, Daniel P. Berrange wrote: > On Mon, Jan 15, 2007 at 08:53:43PM +0000, Mark McLoughlin wrote: > > On Mon, 2007-01-15 at 20:06 +0000, Mark McLoughlin wrote: > > > > > * Since virConnect is supposed to be a connection to a specific > > > hypervisor, does it make sense to create networks (which should > > > be hypervisor agnostic) through virConnect? > > > > Personally, I think virConnect should be little more than a library > > context through which you access all hypervisors at once. In practical > > terms, the XML describing a domain is what chooses which hypervisor to > > connect to - e.g. all apps should pass NULL to virConnectOpen() and all > > drivers should handle NULL. > > > > The one exception to that is for remote connections. In that case apps > > should pass a URI for a remote libvirt daemon which, in turn, would be > > equivalent to calling virConnectOpen(NULL) on the remote host. > > > > So, remotely connecting directly to a hypervisor should be deprecated. > > Having been kept away last night thinking about the implications of this > I think you're description above could actually work, with a fairly small > modification. But first, some pretty pictures: > > 1. The simple (current) usage of using libvirt to connect to a local > hypervisor. Showing two examples - first how the current Xen backends > works, and second how my prototype QEMU backend works: > > http://people.redhat.com/berrange/libvirt/libvirt-arch-local.png This is actually what I'd like to see change. Here's my train of thought: - As a user running multiple types of guests, you want to just decide at creation time whether the guest should be e.g. Xen or QEMU. Apart from that, you don't really want to have to think about what type a guest is. - That implies that users don't want to have different apps for each type of virt, nor different windows, nor different tabs, nor different lists of guests ... if the app doesn't aggregate the guests, then the user will mentally have to aggregate them. - So, should each app do all the heavy lifting to aggregate virt types or should libvirt? I'd argue that while having a consistent API to access different virt types is useful, it's less useful if the app developer needs to access each hypervisor individually. - You're rightly concerned about the namespace clash. It's a problem. I really do sympathise. However, should we just punt the problem to the app developers, or worse ... to the users? - As an example, do you want a situation where someone creates a Xen guest named "Foo", a QEMU guest named "Foo" and when wanting to shutdown the QEMU guest does: $> virsh destroy Foo rather than: $> virsh --connect qemud:///system destroy Foo Oops :-) - Namespace clash #1 is the guest name. I don't think libvirt should allow users to create multiple guests of the same name. It may be technically possible to do that, but if users aggregate the namespace anyway, then it will just cause them confusion if they do. - Probably the only serious problem with that is that libvirt currently will manage Xen guests not created using libvirt. Does it make sense to do that? Will we allow the same with non-Xen? - Namespace clash #2 is the ID. These IDs are assigned by libvirt (except for Xen) and should be opaque to the user, so we could split this namespace now. Start QEMU IDs at 1000? Or prefix the integer with "qemu:"? - Namespace clash #3 is the UUID. This one's kind of funny - one would think we wouldn't need to worry about namespace clashes with "universally unique" IDs :-) We should definitely be trying to prevent from re-using UUIDs. - So ... virConnect(NULL) should be the way of obtaining a context for managing all local guests. The argument to virConnect() would only ever be used to specify a remote context. - The choice between hypervisors is made once and only once, via the domain type in the XML format. - Your "arch-local" diagram would have a single arrow going into libvirt and multiplexing out to all drivers. - Or perhaps, libvirt would *always* talk to a daemon ... whether local or remote. That way you don't have the race condition where multiple apps can create a guest of the same name or uuid at once. Cheers, Mark.
