[Ovirt-devel] [PATCH server] Rake task to generate a dot drawing of the possible VM states

[David Lutterkort]

On Wed, 2009-01-07 at 15:53 -0800, Ian Main wrote:
> On Tue, 06 Jan 2009 17:07:20 -0800
> David Lutterkort <lutter at redhat.com> wrote:
> 
> > I was curious what all the VM state transitions taken together look like
> > - below is a rake task that generates a dot drawing of the FSM of VM
> > states.
> > 
> > Attached is a picture of all that for everybody's amusement.
> > 
> > David
> 
> Wow, that's pretty neat!  Pretty graph.
> 
> I must say however that these states don't really reflect the states provided
> by libvirt.  Libvirt has no sense of intermediate states like 'starting', 'migrating'
> etc.

Yes, with moving to qpid, tracking the VM state will become even more
difficult, even if it becomes more accurate, since VM state (in the UI
sense) is composed of both the VM state reported from libvirt and some
information in the DB.

I've already seen at least one bug caused by this: if you start a VM ona
node, then pull the power on that node, you can't start that VM again,
since the DB still associates that VM with the dead node, and
task-o-matic decides that that means that the VM is already running.

Maybe we should simplify the VM model and get rid of the intermediate
states ('stating', 'migrating', etc.) and just change the VM state to
the success state for the action as soon as we send the message to
start, migrate, etc. After all, the 'starting' -> 'running' transition
is not very meaningful for the user - to them the VM is only running way
after libvirt started the VM (e.g., when httpd or sshd starts in the
boot sequence)

> There's also no distinction regarding 'saved' state vs stopped.  'saved' is
> merely a stopped vm that has had an image taken of it.

That's one case where I don't see a good way to get away from
determining state based on libvirt + other info .. maybe if we got rid
of 'saved' in favor of 'stopped' and offered separate 'start VM from
scratch' and 'start VM from saved image' actions ?

> I know the 'starting' etc. is mostly for user feedback and also to prevent race
> conditions where you can try to start a vm multiple times. However while testing
> the taskomatic changes I was able to queue 5 or so 'start_vm' tasks just because
> the UI was slow to update (I kept pressing the button and it lagged but queued
> them all).

It should be possible to provide user feedback with an additional flag,
something like 'task_in_progress', though it makes task-o-matic's job a
little harder, since it needs to maintain that.

> So anyway, I'm not sure about these intermediate states, and the 'saved' state is
> actually broken..  something we'll have to remember to fix.  The intermediate states
> present a problem in that you can get out of sync with what db-omatic and even
> taskomatic know the real libvirt state to be if you are not careful.

I agree. I think a model where VM states map directly to libvirt states
together with additional flags to support the UI would simplify matters.

David