1:09 p.m.
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 -=|