[Libvir] Virtual networking

[Mark McLoughlin]

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.