[Ovirt-devel] Ovirt-qpid API

[Daniel P. Berrange]

On Thu, Oct 09, 2008 at 03:49:29PM -0700, Itamar Heim wrote:
> Some thoughts:
> 1. Assuming oVirt is booting with a KVM module, would be valuable to
> know if KVM is actually enabled (not sure what is the generalization of
> this for Xen/others).
> Usually it means VT/SVM was not enabled by bios, or that another bios
> flag is preventing it from booting (TX for example).

libvirt provides you this information via its host capabilities API:

# virsh capabilities
<capabilities>

  <host>
    <cpu>
      <arch>i686</arch>
    </cpu>
  </host>

  <guest>
    <os_type>hvm</os_type>
    <arch name='i686'>
      <wordsize>32</wordsize>
      <emulator>/usr/bin/qemu</emulator>
      <machine>pc</machine>
      <machine>isapc</machine>
      <domain type='qemu'>
      </domain>
      <domain type='kvm'>
        <emulator>/usr/bin/qemu-kvm</emulator>
      </domain>
    </arch>
    <features>
      <pae/>
      <nonpae/>
      <acpi default='on' toggle='yes'/>
      <apic default='on' toggle='no'/>
    </features>
  </guest>

  [cut restof XML]


If you don't get a 'kvm' domain type, then the module is not active
and/or the userspace is missing.


> 2. memory - need to know more than just physical memory size, also free
> and cached I guess.

libvirt also exposes this - and NUMA topology and free memory per NUMA
cell.

> 3. node version - reflects potential capabilities, backward
> compatibility considerations by management, etc.
> (not sure if we don't need one for KVM/other hypervisor version, and one
> for the libvirt version)

Although we expose the libvirt version, applications should really
try to drive themselves off capabilities, rather than the version
number. If we backport new features into older libvirt during the
lifetime of a product, then version number checks fail, but capability
based checks will work correctly.

libvirt exposes alot of capability info for guest domains types, but
we need to increase its info for things like storage, network and the
like.

ovirt qpid will likely want to expose some form of capability based
information wrt the host OS features. eg info on allowed networking
configs (eg whether bonding, vlans, etc are allowed), and level of
clustering support. We should define somewhere this info can be exposed
and then use it when adding new features, betweeen releases.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|