[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

Chris Lalancette


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]