[Ovirt-devel] VM Installation problem (and proposed solution)
Ian Main
imain at redhat.com
Thu Sep 4 20:34:03 UTC 2008
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
More information about the ovirt-devel
mailing list