On Tue, Jan 16, 2007 at 05:21:15PM +0000, Mark McLoughlin wrote: > 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. This reminds me of something I've not explicitly said elsewhere. While libvirt API may support multiple difference hypervisors, I'm rather expecting that the common case usage will be that any single host will only ever use one particular hypervisor. ie, a host will be providing Xen, or QEMU+KVM or VMWare or XXX - I think its reasonable to expect that people won't run both Xen and QEMU+KVM on the same host. So, one does not neccessarily have to expose the type of guest to the end user - one could say 'give me the hypervisor connection for this host' and it would auto-detect what hypervisor is available for that host. Of course some people might be perverse enough to run many HV on a host but I suspect that's rather the niche case. Probably main case I'd see is that a host is primarily running Xen as its primary HV. For some one off task, the user may fire up an unprivileged QEMU session, for a few hours. > - 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. I think we'd probably end up grouping the guests based on the host they are running on. In the common case of only one HV per host, there would be no need for the user to worry about the different types of HV, unless they opted-in to accessing a non-default HV from the host. > - 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? Well a combination of all ? We have a hierarchy of namespaces currently, from narrowest scope to broadest: - ID: unique to an active guest on a single HV - Name: unique to a guest for its lifetime on a single host+HV - UUID: unique to a guest for its lifetime, across a datacenter > - 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 :-) Indeed - but not particularly different to the case of managing two remote hosts with virsh $ virsh --connect xen://web1/ destroy Foo vs $ virsh --connect xen://db1/ destroy Foo And I don't think its viable to enforce unique naming of guests across the entire data center. There's always a big risk when using command line tools like this - for graphical tools we can do better, because UI cues can help distinguish guests better - eg grouping by host. > - 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? In the ideal world I'd ignore anything not managed by libvirt, but in reality I don't think that's practical. We need to be able to interoperate as cleanly as possible with other tools, either provided by the HV itself (eg xm) or by other 3rd party vendors. While my prototype QEMU backend ignores VMs not created by libvirt, work going on upstream will make it practical to manage them too. > - 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:"? It has to be an integer because of existing ABI constraints. I'm not sure we really want to maintain an internal mapping of libvirt IDs to the actual HV's view of IDs. We already provide a globally unique ID - eg the UUID, so having a second one doesn't seem like much use. > - 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. Well, assuming we use a sane generation technique, statistically these are supposed to be globally unique. Of course users make mistakes, for example, when cloning VMs, so XenD will do reasonable effort to check uniqueness. I'm of opinion though that libvirt should avoid trying to implement policy itself, and rather deligate that policy to the underlying HV. eg If libvirt had a polucy for VM names saying a-Z, 0-9, but XenD instead requires a-Z, 0-9, _, - then we can get into crazy situation where user is trying to manage an existing VM, but libvirt incorrectly rejects it. > - 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. Possibly :-) I think I'll draw another diagram... 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 -=|
