[Ovirt-devel] Ovirt-qpid API

[Itamar Heim]

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

2. memory - need to know more than just physical memory size, also free
and cached I guess.
(could be already collected by collectd - didn't get a chance to go over
it yet)

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)

Itamar

-----Original Message-----
From: ovirt-devel-bounces at redhat.com
[mailto:ovirt-devel-bounces at redhat.com] On Behalf Of Ian Main
Sent: Thursday, October 09, 2008 6:20 AM
To: ovirt-devel at redhat.com
Subject: [Ovirt-devel] Ovirt-qpid API


So I've been doing some work on this API.  It looks like libvirt
hardware enumeration is coming along reasonably, so I'm not going to
cover all that in this API.  Instead we'll get a version of libvirt
built in a few weeks with hardware enumeration and update libvirt-qpid
to support that.

As always, please take a look and see if I forgot anything or such.

Here's a rundown of the info we are gathering now:

- Hardware uuid using HAL
- architecture
- CPU info:
    - number of cores
    - processor
    - core id
    - cpu cores
    - vendor id
    - model
    - cpu family
    - cpuid level
    - cpu MHz
    - cache size
    - cpu flags

- Network interfaces:
    - interface name
    - MAC
    - ip address
    - netmask
    - broadcast
    - bandwidth (speed - 100baseT full/half etc.)

- Memory size

Things gathered by libvirt hardware enumeration:

The in-development Libvirt API is currently using HAL to enumerate
devices.  This gives us information on processor, storage, network
interfaces etc. but does not include the IP address configuration of a
network interface, nor the speed capabilities. 

Otherwise we have:

- Kerberos key download.  This will remain a separate step.
- Various statistics pushed via collectd.  This can remain in place, but
I
  think we should consider pushing the load avg (or maybe cpu usage?  I
know
  there are some graphing issues with load) which would eliminate the
need for
  host-collect.rb.
- Network configuration.
- Shutdown/reboot.
- Beeps and flashes to identify machine and nics.

So the attached API deals with all the network configuration, IP address
information etc. as well as the various other functions we want to see
supported beyond what libvirt provides for us.

On the network API, I wasn't entirely positive I should take this
approach or if I should create another Bonding class that bonds
networkInterfaces.  In the end I chose this model as it essentially
mirrors what the configuration is doing.  I can easily be convinced to
do the other though.. or even to just mock it up and see how it looks.

>From the python qpid client, you would setup the network something like
this:

s = Session()
b = s.addBroker()
onode = s.getObjects(name="ovirtNode", uuid=someuuid)

# So this call would return a networkInterface class but would be
configured # for bonding.  This is the part I'm 50/50 on.  I could
create a separate # Bonding class.
bond = onode.createBondingInterface("bond0")
# It should basically be setup to be right on creation..
bond.dhcp = true
bond.restart()

nics = s.getObjects(name="networkInterface", ovirtNode=onode) for nic in
nics:
  nic.master="bond0"
  nic.restart()

# For fun..
onode.beeping = true
nic[0].blinking = true

The objects will also be created from the configuration on the node if
it had persistent storage and came up configured.

    Ian