[Ovirt-devel] VM Installation problem (and proposed solution)
clalance at redhat.com
Wed Sep 3 09:44:32 UTC 2008
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?).
That being said, I'm not against having a new lifecycle action for <on_reboot>;
that would make life easier for virt-install too, I would imagine.
More information about the ovirt-devel