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

Perry N. Myers pmyers at redhat.com
Wed Sep 3 09:59:25 UTC 2008


Daniel P. Berrange wrote:
> On Fri, Aug 29, 2008 at 08:08:04AM +0200, Chris Lalancette wrote:
>> Daniel P. Berrange wrote:
>>> On Thu, Aug 28, 2008 at 05:20:06PM +0200, Chris Lalancette wrote:
>>>> Hello all (Ian especially),
>>>>      apevec pointed out a problem with installation of guests under oVirt.  What
>>>> currently happens is that after you finish the installation of (say) Fedora in a
>>>> VM, the VM reboots, but then immediately PXE boots again.  This is because we
>>>> haven't killed the guest and re-defined the XML to have the boot device be the
>>>> hard drive, like it should.
>>> You don't have to wait for installation to finish before re-defining the 
>>> XML with hard drive as the boot device
>>>
>>> You can define the post-install XML config the moment the guest has booted.
>>> When it shuts down, libvirt will automatically switch over to the newly
>>> defined config.  This is how virt-install handles it.
>> 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.

I agree with you that solving this in a libvirt way would be better (I 
like the destroy+restart semantic idea that seems very clean).

However, I do think that not every ovirt action will be able to be a 1-1 
map with libvirt and we might need ovirt specific AMQP calls.  For 
example, libvirt doesn't know anything about a call like "set the collectd 
performance gathering interval to 5 minutes" or "reboot the physical node" 
I'm sure there will be other things that also will not fit into libvirt.

So what I'm thinking is that we need libvirt-qpid and ovirt-qpid.  Does 
this make sense?

But as for adding the new lifecycle action for on-reboot, if you think 
that is the best way to solve this problem then this is what we should do. 
Let me know how that proceeds.

Thanks,

Perry




More information about the ovirt-devel mailing list