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



More information about the ovirt-devel mailing list