[Ovirt-devel] VM Installation problem (and proposed solution)

Daniel P. Berrange berrange at redhat.com
Wed Sep 3 10:04:17 UTC 2008


On Wed, Sep 03, 2008 at 11:44:32AM +0200, Chris Lalancette wrote:
> Daniel P. Berrange wrote:
> >> Yes, true.  The difference is because of the asynchronous nature of taskomatic,
> >> we basically kick off the guest on the node, and then go on to do other things.
> >>  The next time we would hear anything about this guest is when host-status
> >> eventually polled it and noticed it "shutoff" (even though we think it is
> >> running).  So then we would need to perform the heuristic of "if this was
> >> install time, and the guest is now dead, restart it".  Just doing all of this
> >> out on the node will reduce our round-trips to the server, and do the whole
> >> thing in a more timely fashion.  That's why I think it is better to do this
> >> whole thing remotely on the node.
> > 
> > The trouble with this is that it does not map onto a libvirt API cleanly.
> > The idea behind the AMQP binding was to map 1-to-1 onto the libvirt API
> > and not invent oVirt specific constructs in the API. I think we need to
> > come up with some way to perform this automatic reboot with different XML
> > within the scope of the libvirt API. Not quite sure what that would mean
> > though. Perhaps a new lifecycle action for the <on_reboot> tag, to explicitly
> > represent a 'destroy+restart' semantic.
> 
> Hm, but I'm confused.  While I know we definitely wanted to implement all of the
> libvirt calls in the AMQP bindings (so it could be re-used), I was pretty sure
> we were going to have custom oVirt methods anyway (Ian, am I right here?).

Well there's several different aspects to this. I expect there to be 2 or
even 3 separate, independant schemas implemented by the agent. A libvirt
schema, a collectd / monitoring schema, and possibly an oVirt specific
schema. We should aim to put everything in the generic schemas and only
resort to using the oVirt specific schema if we really do not have any
other choice. We shouldn't do a oVirt specific schema just because it
is 'easy' in the short term - that leads to long term maintainence pain.

For this particular problem, I rather hope we could find a way todo it
within the scope of libvirt because its a quite a reasonable action to
want todo and has nothing specific to oVirt about it

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




More information about the ovirt-devel mailing list