[Ovirt-devel] Ovirt-qpid API

[Daniel P. Berrange]

On Wed, Oct 08, 2008 at 09:19:33PM -0700, Ian Main wrote:
> 
> 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

Available in libvirt

> - CPU info:
>     - number of cores
>     - processor
>     - core id
>     - cpu cores
>     - vendor id
>     - model
>     - cpu family
>     - cpuid level
>     - cpu MHz
>     - cache size
>     - cpu flags

All this needs to come from libvirt if you want it to work
with Xen ever, because Dom0 doesn't see true details

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

This needs to take account of IPv6 addressing - US gov mandates
use of IPv6 in all applications now. So need to separate the
physical device info, from the addressing info - there can be
multiple IPv4 and multiple IPv6 addresses ultimately, even if
oVirt will only use a single address for now.

> - Memory size

Available in libvirt & against must use libvirt if its to work
with Xen because Dom0 doesn't see true memory info.

> Otherwise we have:
> 
> - Kerberos key download.  This will remain a separate step.

Agreed, this is part of the security credentials bootstrap stage.

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

I had thought we were going to push all collectd info over AMQP 
so we only had two network protocols in/out of the node - AMQP and
a per-guest VNC connection ?

> - Network configuration.
> - Shutdown/reboot.

VirtualIron guys have requested this as part of libvirt a few weeks back
and we had a bit of discussion but never came to any conclusion. I'm 
inclined to think they're probably right :-)

> - Beeps and flashes to identify machine and nics.

Interesting, not heard of this requirement before. Guess until we
have NIC mgmt in the libvirt API, this can go in the oVirt NIC
mgmt schema you mention above.

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

Depends how flexible / advanced you want to get. Long term bonding isn't
the only thing people will want to setup. There's bridging, and vlans
too.

 - A bond device can contain n * physical NICs
 - Multiple VLAN devices can be created against each bond device,
   or physical NIC
 - Each VLAN, bond or physical device can be added to a bridge

So you can have a stacking of device, from lowest to highest level:

 - Physical device
 - Bond devices
 - VLAN devices
 - Bridges

The bond, vlan, bridge layers can each be omitted depending on needs.

> <schema package="com.redhat.ovirtNode">
> 
>   <class name="ovirtNode">
> 
>     <property name="uuid" type="sstr" access="RC" desc="hostname UUID as gathered from HAL."/>
>     <property name="hostname" type="sstr" access="RC" desc="host name"/>
> 
>     <method name="hardwareShutdown" desc="Bring down host and halt machine."/>
>     <method name="hardwareRestart" desc="Bring down host and restart."/>
>     
>     <property name="beeping" type="bool" desc="true/false to invoke beeping of machine (for identifying system)"/>
> 
>     <method name="createBondingInterface"/>
>       <arg name="interfaceName" dir="I" type="sstr" desc="Name of new interface"/>
>       <arg name="interface" dir="O" type="objId" desc="New bonding interface"/>
>     </method>
>   </class>
> 
>   <class name="networkInterface">
>     <property name="ovirtNode" type="objId" references="ovirtNode" access="RC" index="y" parentRef="y" desc="Keep track of hardware node these interfaces belong to."/>
>     <property name="interfaceName" type="sstr" access="RC" desc="Network interface name."/>
>     <property name="dhcp" type="bool" desc="true/false - use DHCP for interface.  If false properties will be saved and restored for static IP."/>
>     <property name="speed" type="uint32" desc="link speed."/>
>     <property name="mac" type="uint64" desc="MAC address."/>
>     <property name="ip" type="sstr" desc="IP address."/>
>     <property name="netmask" type="sstr" desc="Netmask."/>
>     <property name="broadcast" type="sstr" desc="Broadcast."/>
>     <property name="master" type="sstr" desc="Master device interface name for bonding.  If set this interface becomes a slave."/>
>     <property name="blink" type="bool" desc="True/false to invoke blinking of ethernet light (for identifying interface)"/>
>     
>     <method name="restart" desc="Restart the interface to allow changes to properties to take effect."/>
>   </class>

You need to model address information separately from the device info.
Each network Interface can have n * IPv4 addresses & m * IPv6 addrs.

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 :|