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



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