Ovirt devel - Oct 2008 - 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ovirt-node-2008-10-08.xml
Type: application/xml
Size: 1879 bytes
Desc: not available
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20081008/9546a83d/attachment.wsdl>

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

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

OK, here's another go around at this.  This has all the bells and whistles
for network config.  Please take a moment to go through it and make sure
I've done this properly.

BTW, the UUID from hal is in there so that we can map this host to the host in
libvirt.  Hopefully they will always be the same.  Xen doesn't mess with
this does it in dom0?

Thanks!

	Ian


<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"/>

    <property name="defaultGateway" type="sstr"
desc="Default gateway."/>
    <property name="default6Gateway" type="sstr"
desc="Default IPv6 gateway."/>

    <property name="beeping" type="bool"
desc="true/false to invoke beeping of machine (for identifying
system)"/>

    <method name="hardwareShutdown" desc="Bring down host and
halt machine."/>
    <method name="hardwareRestart" desc="Bring down host and
restart."/>

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

    <method name="createBridgingInterface"/>
      <arg name="interfaceName" dir="I"
type="sstr" desc="Name of new interface."/>
      <arg name="interface" dir="O"
type="objId" desc="New bridging interface."/>
    </method>
    
    <method name="createVLANInterface"/>
      <arg name="interfaceName" dir="I"
type="sstr" desc="Name of raw device interface."/>
      <arg name="vlanId" dir="I" type="uint64"
desc="VLAN ID."/>
      <arg name="interface" dir="O"
type="objId" desc="New VLAN interface"/>
    </method>

    <method name="reloadNetwork" desc="Reload network config
to let changes take effect."/>

  </class>

  <class name="IpAddress">
    <property name="ip" type="sstr" desc="IP
address."/>
    <property name="prefix" type="uint32"
desc="Prefix/netmask."/>
    <property name="broadcast" type="sstr"
desc="Broadcast."/>
    <property name="interface" type="objId"
desc="Interface to which this address belongs"/>
  </class>

  <class name="Ip6Address">
    <property name="ip" type="sstr" desc="IPv6
address."/>
    <property name="prefix" type="uint32"
desc="Prefix."/>
    <property name="interface" type="objId"
desc="Interface to which this address belongs"/>
  </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="enableIPv6" type="bool"
desc="true/false - enable IPv6 on interface."/>
    <property name="dhcp6" type="bool"
desc="true/false - use DHCP for IPv6 on interface."/>
    <property name="speed" type="uint32" desc="link
speed."/>
    <property name="mac" type="uint64" desc="MAC
address."/>
    <property name="master" type="objId"
desc="Master device interface for bonding or bridging."/>
    <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>
  
  <class name="BondInterface">
    <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="bondingMode" type="uint32"
desc="Bonding mode"/>
    <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="enableIPv6" type="bool"
desc="true/false - enable IPv6 on interface."/>
    <property name="dhcp6" type="bool"
desc="true/false - use DHCP for IPv6 on interface."/>
    <property name="mac" type="uint64" desc="MAC
address."/>
    <property name="master" type="objId"
desc="Master device interface name."/>
    <method name="restart" desc="Restart the interface to
allow changes to properties to take effect."/>
  </class>

  <class name="BridgeInterface">
    <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="enableIPv6" type="bool"
desc="true/false - enable IPv6 on interface."/>
    <property name="dhcp6" type="bool"
desc="true/false - use DHCP for IPv6 on interface."/>
    <property name="mac" type="uint64" desc="MAC
address."/>
    <property name="master" type="objId"
desc="Master device interface name."/>
    <method name="restart" desc="Restart the interface to
allow changes to properties to take effect."/>
  </class>
  
  <class name="VLANInterface">
    <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="vlanId" type="uint64"
access="RC" desc="VLAN ID"/>
    <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="enableIPv6" type="bool"
desc="true/false - enable IPv6 on interface."/>
    <property name="dhcp6" type="bool"
desc="true/false - use DHCP for IPv6 on interface."/>
    <property name="mac" type="uint64" desc="MAC
address."/>
    <property name="master" type="objId"
desc="Master device interface name."/>
    <method name="restart" desc="Restart the interface to
allow changes to properties to take effect."/>
  </class>
</schema>