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

[Ian Main]

On Wed, 03 Sep 2008 05:59:25 -0400
"Perry N. Myers" <pmyers at redhat.com> wrote:

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

Yes, that's likely what will end up happening.  It would be nice to have it all in one binary, but I suspect that won't happen because of the packaging; having libvirt-qpid be a standalone thing.

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

I like that best as well.

	Ian