[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