Re: [Libvir] Virtual networking

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: 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.