[Ovirt-devel] Managed Node qpid Modeling
Daniel P. Berrange
berrange at redhat.com
Tue Jul 15 09:33:01 UTC 2008
On Mon, Jul 14, 2008 at 01:40:28PM -0700, Ian Main wrote:
> OK, similar idea. I spent a bunch of time looking at the
> libvirt API and decided that I would keep the properties
> and object relations in place rather than going to all
> libvirt style calls. I like the idea of modeling the
> system and having any state changes pushed up rather
> than having to poll.
You're not getting rid of polling, you're just pushing it
elsewhere. To fill in the property fields & keep them updated
you're going to have to poll on the managed node fetching the
XML document all the time. This is absolutely something you
do not want todo. Fetching the XML is a heavyweight operation
on some hypervisor. eg if you have Xen and fetch the XML doc
for 20 VMs, once a second you'll have 100% cpu usage on the
managed node just from polling. The only methods that can be
efficiently polled are those for getting the live domain
resource info - ie virDomainGetInfo(), and those for listing
active/inactive domains.
> I did change the main creation functions to mirror the
> libvirt calls using XML descriptions. Very good call
> there. I also switched the create/destroy etc. to use
> libvirt equivalents.
I maintain that this modelling should match the libvirt API
and object model 100%, so that it can be a general purpose
libvirt API-over-QPid rather than a oVirt specific modelling
as it is now. Having a general libvirt moel provides for
interoperability with other applications needing to access
libvirt over QPid, and will allow us to implement QPid
support directly into the libvirt client for those who do
not need to talk directly to QPid for asynchronous comms.
Reducing the amount of oVirt specific code is also important
for long term code maintainence overhead.
> <class name="Node">
> <property name="uuid" index="y" type="sstr" access="RC"/>
> <property name="hypervisor_type" type="sstr" desc="Hypervisor type"/>
> <property name="hostname" type="sstr" access="RC" desc="Host name"/>
> <property name="OS version" type="sstr" access="RC" desc="Operating system information and version"/>
> <property name="arch" type="sstr" access="RC" desc="Architecture"/>
> <property name="num_cpus" type="sstr" access="RC" desc="Number of CPUs on system"/>
> <property name="cpu_speed" type="sstr" access="RC" desc="Speed of CPUs"/>
> <property name="memory" type="sstr" access="RC" desc="Amount of memory in KB"/>
> <property name="libvirt_version" type="sstr" access="RC" desc="Version of libvirt on the managed node"/>
>
> <!-- Set up an association of nodes with the master Ovirt class. This will give you a list of all nodes
> given an Ovirt object instance. -->
> <property name="nodes" type="objId" reference="Ovirt" desc="Node within the ovirt system"/>
>
>
> <!-- Statistics are pushed to the broker every 10s by default from the agent. -->
> <statistic name="load_average" type="count64" unit="message" desc="Load average of host"/>
> <statistic name="free_memory" type="count64" unit="message" desc="Amount memory available in KB"/>
>
> <!-- We may get this for free in the broker. We'll have to see. -->
> <statistic name="heartbeat" type="count64" unit="message" desc="Incremented in 5 second intervals to measure host availability"/>
>
> <method name="define_domain" desc="Define a new domain">
> <arg name="xml_desc" dir="I" type="sstr" desc="XML domain description"/>
>
> <arg name="domain" dir="O" type="sstr" desc="Newly created domain object"/>
> <arg name="result" dir="O" type="ObjID" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="storage_pool_create" desc="Create a new storage pool">
> <arg name="xml_desc" type="sstr" desc="XML Description of the storage pool"/>
>
> <arg name="pool" dir="O" type="sstr" desc="Newly created storage pool"/>
> <arg name="result" dir="O" type="ObjID" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
> </class>
>
> <class name="Domain">
> <property name="uuid" type="sstr" desc="Domain UUID"/>
> <property name="num_vcpus" type="uint32" desc="Number of virtualized CPUs for domain"/>
> <property name="num_vcpus_used" type="uint32" desc="Number of virtualized CPUs used"/>
> <property name="memory_allocated" type="uint32" desc="Amount of memory allocated for domain in KB"/>
> <property name="memory_used" type="uint32" desc="Amount of memory used by domain in KB"/>
> <property name="vnic_mac_addr" type="sstr" desc="Virtualized NIC MAC address"/>
> <property name="state" type="sstr" desc="VM State: 'running', 'stopped', 'suspended'"/>
> <property name="vnc_port" type="uint32" access="RW" index="y" desc="VNC viewer port"/>
The only properties that should be on the wire should be uuid,
name and ID. Nothing else can be implemented efficiently. General
configuration information should be returned via a invocation of
the virDomainGetXMLDesc() method mapping.
Live memory usage can be obtained via the XML doc, or via a mapping
to the virDomainGetInfo() method.
> <method name="create" desc="Start stopped VM"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="destroy" desc="Stop this VM"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="undefine" desc="Undefine the domain"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="suspend" desc="Suspend this VM"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="resume" desc="Resume suspended VM"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="save" desc="Save this VM"/>
> <arg name="filename" type="sstr" desc="Name of file to save VM image in"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="restore" desc="Restore saved VM"/>
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
>
> <method name="migrate" desc="Migrate this VM to another host"/>
> <arg name="host" dir="I" type="ObjID" desc="Object representing a host to migrate to"/>
This is missing alot of arguments compared to the libvirt API parameters.
> <arg name="result" dir="O" type="sstr" desc="Description of result. 'success' or 'failure: error msg'"/>
> <arg name="domain" dir="O" type="sstr" desc="New VM object on new host"/>
> </method>
> </class>
>
> <class name="Pool">
> <property name="uuid" type="sstr" desc="Pool UUID"/>
> <property name="hostname" type="sstr" desc="Pool host"/>
> <property name="device_info" type="sstr" desc="Target device name or nfs path"/>
> <property name="type" type="sstr" desc="Storage type"/>
Again the only properties should be the UUID and Name. Everything
else should be in the XML document.
> <!-- Set up an association of hosts to storage pools. This will setup a list of pools in the node object
> and give us a reference here to the node. -->
> <property name="node" type="objId" reference="Node" desc="Node of this storage pool"/>
>
> <method name="delete" desc="Destroy the pool and delete its definition">
> <arg name="result" dir="O" type="ObjID" desc="Description of result. 'success' or 'failure: error msg'"/>
> </method>
> </class>
>
> <class name="Volume">
> <property name="uuid" type="sstr" access="RC" index="y" desc="Storage Volume UUID"/>
> <property name="path" type="sstr" desc="Storage volume path"/>
> <property name="size" type="sstr" desc="Volume size in KB"/>
> <property name="type" type="sstr" desc="Storage type"/>
> <property name="lun" type="sstr" desc="Target lun if iscsi"/>
A storage volume has 3 identifying properties, a Key and Path and a
Name. There is no UUID - the 'key' property provides an equivalent
role, but not in the strict 16 hex digit format.
Everything else should be in the XML dump. There is no concept of
a LUN for anything other than iSCSI/SCSI. There are two different
sizes that are needed - 'allocation' and 'capacity'. This is all
dealt with in the XML format correctly.
> <!-- A storage volume is linked to a domain. -->
> <property name="domain" type="objId" reference="Domain" desc="Domains using this storage volume"/>
Not in the libvirt storage model, it isn't.
> <!-- And also linked to its storage pool. I think we can make this populate as soon as the storage
> pool is created on the host, so a list of volumes would show up in the pool as a property. -->
> <property name="storage_pool" type="objId" reference="Pool" desc="Pool where this storage volume exists"/>
> </class>
>
> </schema>
>
> _______________________________________________
> Ovirt-devel mailing list
> Ovirt-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/ovirt-devel
--
|: 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 :|
More information about the ovirt-devel
mailing list