[Ovirt-devel] Managed Node qpid Modeling

[Ian Main]

On Tue, 15 Jul 2008 10:33:01 +0100
"Daniel P. Berrange" <berrange at redhat.com> wrote:

> 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'm very well aware that we're not getting rid of polling.  My concern was the network traffic that would be generated in polling, I didn't realize it was such a heavy operation to call the XML based calls.  We need to have as up to date info of what the state of the domains as possible.

As per our IRC discussion we can move the domain info to a set of properties, probably within a DomainInfo class or such.  The rest we'll have to use the XML classes and call them infrequently because polling is unrealistic.  This should work fine.. the only other thing we need on a semi-regular basis is the vnc port, but we can just grab that on state changes.

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

OK, well, after our chat and some thought I think we can move in this direction.  My only other concern would be some stray statistics and perhaps properties that would be outside of libvirt.  Perhaps these could be in a separate class though.

	Ian