[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[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


Attachment: ovirt-node-2008-10-08.xml
Description: application/xml


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]