notes from "rethinking the architecture" breakout

[dann frazier]

These are some notes I took from the Thursday afternoon breakout
session initiated by Alexander Graf. I've also posted them here:
  http://ovirt.org/wiki/Rethinking_the_Architecture_breakout_-_oVirt_workshop_November_2011


libvirt is designed to be a hypervisor agnostic layer. For lots of hypervisors
this is pretty straightforward as they offer APIs for vm ops (create/destroy/
etc). No such layer exists for kvm, so libvirt has a lot of kvm-specific
code to supplement. VDSM sits on top of libvirt to make use of functionality
which would normally be in this mid-layer. This is a layering design defect.

Perhaps we could create a "kvmd" layer which manipulates qemu directly. libvirt
would then be free to rebase upon this new midlayer, if desired. Alternatively,
maybe the "extra" code in libvirt can be extracted to create this midlayer.
People like the virtualbox UI - that too could be ported on top of "kvmd".

VDSM maybe well suited to become the "kvmd" components.

What interface would "kvmd" present? What about using the ESXi API vs.
reinventing the wheel? RHEV-M team looked at it in the past - the API is very
big, they didn't understand all of it, lots of ESX-specific stuff.

Karl suggests that we should concentrate on the API to the host - we can switch
out/relayer components internally - but we want an API that people can start
using now and maintain. Internals can change organically.

We still want to have a data definition file that is generic; don't want to
always require usage of oVirt engine to have a self-contained VM description.
An OVF for KVM. Why not use the existing ovirt OVF as a standard?

SuSE studio would like to use such a format; they have comparable formats
for other hypervisor types.

If kvm VM creation builds an OVF file (vs. just exporting it) it might help
increase the adoption of this as a standard.

Let's not forget there are advantages that libvirt brings to oVirt;
hooks rely heavily on libvirt modules for example.

how does ovirt-engine relate to nova?
similar; but different goals.

what about subservices of nova? e.g. placement service?

per-user kvmd, don't run as root, a lot of benefits - security, selinux,
quotas, SLAs-per-user