[one-users] Sync State / Sanlock

[Carlos Martín Sánchez]

Hi,

Instead of executing 'virsh create' manually in another host, you can use
the 'onevm resubmit' action [1].
This can be done automatically using the fault tolerance hooks [2]

Regards

[1]
http://opennebula.org/documentation:rel3.8:vm_guide_2#life-cycle_operations
[2] http://opennebula.org/documentation:rel3.8:ftguide
--
Carlos Martín, MSc
Project Engineer
OpenNebula - The Open-source Solution for Data Center Virtualization
www.OpenNebula.org | cmartin at opennebula.org |
@OpenNebula<http://twitter.com/opennebula><cmartin at opennebula.org>



On Fri, Nov 16, 2012 at 10:58 PM, Ricardo Duarte <rjtd21 at hotmail.com> wrote:

> Hi there,
>
> Something I find missing in OpenNebula is a "sync state" functionality.
> OpenNebula could monitor hosts and update the relationships between
> instances and hosts dynamically.
> So, for example, when a host fails we could manually fix the problem by
> "virsh create" the deployments on a new server, and OpenNebula would pick
> the new host for the instances.
> Currently, the machines stay as "UNKNOWN".
>
> Also related is the potential danger "UNKNOWN" states present when the
> system datastore runs on shared storage.
> So, on my last example:
> - I would start the instances on a new host.
> - Users on Sunstone would still see the machines as "UNKNOWN" and can
> restart the machines
> - Both instances would start writing on the same file, leading to
> corruption
>
> To prevent that OpenNebula ccan/should make use of  sanlock. OpenNebula
> would be required to act as the lock manager.
> By syncing state we could limit conflicts, and by using sanlock we could
> make it fail proof.
>
> Regards,
> Ricardo
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20121119/81ff6bf2/attachment-0002.htm>