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

[Daniel P. Berrange]

On Wed, Jan 07, 2009 at 05:53:22PM -0800, David Lutterkort wrote:
> 
> 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.

Fundamentally any 'VM state' information is always potentially out of 
date, no matter where you got it from, because there's always some
delay between the state being queried, and oVirt looking at the returned
state data. Obviously getting it from libvirt directly every time will
reduce the liklihood that its out of date, but you still have a non-negligle
chance of it being out of date by time you act on it. Therefore, taskomatic
needs to be aware of this potential inaccuracy and be able to take appropriate
cleanup/workarounds upon failure if appropriate

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

As well as the explicit 'current' states you get from libvirt by
querying th virDomainGetInfo method, you can also now get event
notifications upon state transitions. These let you also get info
on why the state transition has occurred.

eg, you'll get a event notifying that the VM transitioned to
the state 'stopped', and it'll tell you whether this was because

 - Graceful shutdown
 - Force VM destroy
 - Outgoing migration completed
 - Save to file operation completed
 - Device emulation (ie QEMU) failed unexpected

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|